Is VolatileImage worth the extra effort?

Java 2D
#1

Hi there!

I use a gui-toolkit which can use double-buffering for faster drawing, however it still uses Component.createImage which is my eyes lost performance on 1.4+.
So I maybe could help the author with an accerlated version of his backbuffer-support.

However it would be cool if anybody could answer me some of these questions. If you know just one it would be great to hear your answer!

  • Is VolatileImage really worth the extra effort? E.g. how often a typically images needs to be recreated?

  • Does a VolatileImage also speed up basic stuff like drawLine, drawString and draw/fillRect?

  • Is there a speed difference if I create the image using Component.createVolatileImage or GraphicsConfiguration.cre…?

  • Is a VolatileImage also accerlated when using the x11-pipeline.

Thanks a lot, lg Clemens

This is a bit off-topic:
Does anybody know how long the GraphicsConfiguration-Class is included in the jre? I bet something like 1.2 but nowhere I can read a “since x.y”.

#2

For information VI versus other image types, check out this Chet’s blog (and you might want to read his other blogs as well, they’re very informative):
http://weblogs.java.net/blog/chet/archive/2004/08/toolkitbuffered.html

VI needs to be recreated when some event causes a surace loss. On windows this could be when you alt+tab out of the application, or some other application goes into fullscreen mode.

Yes, many primitive operations are accelerated when rendered to a VI (which operations depends on platform and particular configuration).

There should be no difference between VIs created with createVI versus GC.createComatibleVI (one calls another under the hood, the methods were added to both places for consistency with createImage api).

With the default X11 pipeline VIs are implemented using X11 Pixmaps (X server or shared), so yes, they are accelerated (on driver discretion).

But, in short, for most cases you really would want to use BufferStrategy, which represents a double-buffering strategies.

GraphicsConfig/GraphicsDevice/GraphicsEnvironment first appeared in 1.2.

#3

Thanks a lot for your detailed help!

I need direkt access to the buffer because my app draws a big complex invinite grid that should be scrollable in steps from in all 4 direktions.

So what I do is to copy almost anything with copyArea ad draw only a small part.

I implemented a class that treats all imagestypes as VI, e.g. contentsLost() always returns false if no VI is used in reality.
This helps me to stay compatible with java-1.1 vms (the company where I work forces me to do so).

Thanks a lot for all your help, lg Clemens