FPS increases when scaling transform applied

Java 2D
#1

Hi,

I just noticed something really weird. Without any scaling, ie no AffineTransform scale transforms, performance for my J2D game is about 33 FPS. I recently made a zoom in & out feature that works by applying a scale to the Graphics object’s AffineTransform. After zooming, the FPS suddenly increases from 33 to 42, whether its zooming in or out. It doesn’t always happen straight away, but after zooming out or in a fair way it happens, even when I go back to the original scale factor.

If anybody knows why I’d really like to find out. Speculation is welcome too :wink:

Here’s some other info:
With a normal map that paints images, before scaling 33 FPS & 42 after.
A map that has no images, just Shapes that are filled with solid colours, before scaling 37 FPS & 37 after.
OGL pipeline (-Dsun.java2d.opengl=True): no difference
No directdraw option (-Dsun.java2d.noddraw=true): no difference
And with the following options:
-Dsun.java2d.ddscale=true
-Dsun.java2d.translaccel=true
-Dsun.java2d.ddforcevram=true
before scaling 33 FPS, after 3.

Cheers,
Keith

By the way, on my 2.8GHz dual core computer the no direct draw option surpisingly gives an FPS of 52 compared with only 33 FPS for the default no-options VM.

#2

Im thinking when you zoom in, you have more “texels” to pixels ratio…therefore, the J2d loops do less calculations and whatnot…

A random guess :slight_smile:

DP

#3

That wouldn’t explain zooming out though :wink:

In my experience the performance of the java2d pipeline is far too unpredictable for it to be useful in any speed critical application.

#4

Zooming in might be as DP says.

Zooming out might simply be the number of pixels being touched?

Kev

#5

Interesting theory, but if its got something to do with pixels then why wouldn’t the OGL or no-ddraw pipelines have the same problem?

I was just reading this: http://java.sun.com/products/java-media/2D/perf_graphics.html and I think that the scaling must cause the images to be shifted out of VRAM and into system memory where software scaling is done. It makes sense that this would be faster since when the noddraw option is enabled (which means no images are VRAM-ed), the FPS is way faster on my computer. Also, when the ddforcevram option is enabled (which means images must not be switched out of VRAM), the FPS falls to 3. Here’s an excerpt from that Sun Graphics White Paper:

The performance of scaling to and from an accelerated image improved significantly between the (1.4) Beta 2 and Beta 3 releases because of a new heuristic that, based on the frequency of read operations performed on an image, can store the image to the type of memory that will allow the best performance. See the next section for more information on the new heuristic.

Its funny the way my graphics card VRAM & GPU is rendering slower than my dual-core CPU & its RAM. We and the J2D team have always operated under the assumption that ‘acceleration’ is good, but here the graphics card is causing deceleration. To be correct, I think the deceleration is coming from the bottleneck between getting the CPU’s data onto VRAM (which is slower than getting it onto system RAM), not the Graphics card being slow. But this is really just a semi-educated guess :wink:

#6

yeah, such decelerations have existed ever since 1.4 was released.

Depending on hardware setup, available video memory, source image size and type, destination type, and the drawing operations being performed - there will always certain combinations that result in atrocious performance.
I think retrofitting the java2d api with hardware acceleration was a mistake; the existing api simply doesn’t expose enough information to usercode for performance to be reliable,.
A fact born out by the number of releases java2d has gone through to reach its current (still very brittle) state.

#7

I cant’ comment on the no-ddraw pipeline, but as for the OGL pipeline, its HW accelerated, its probably running at a gigillion FPS anyway and its being throttled to vsync, thats why your not seeing it on the ogl pipeline.

DP