Good way to load & cache images

Performance Tuning
#1

Hello, I know this has been discussed a lot but I haven’t a definitive answer. Is this a good way/format (in terms of eventual rendering performance) to store images ?


            URL url = classLoader.getResource(filename);
            BufferedImage tempImage = ImageIO.read(url);
            GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
            GraphicsConfiguration gc = ge.getDefaultScreenDevice().getDefaultConfiguration();

            BufferedImage compatibleImage = gc.createCompatibleImage(tempImage.getHeight(),tempImage.getWidth(),Transparency.TRANSLUCENT);
            Graphics g = compatibleImage.getGraphics();
            g.drawImage(tempImage,0,0,null);

            g.dispose();
            imageDictionary.put(imageId, compatibleImage);

Rendering the images from my imageDictionary doesn’t seem to be that quick. I am rendering to a BufferStrategy and flipping using J2D. I know an OGL binding will be faster but I’m a newb and would rather defer that decision till I know it’s necessary as I have enough to learn as it is!

thanks in advance,
Don.

#2

Rule #1 profile your code.

You seem to be assuming that your erpformance problem is with your image or its format but that might well not be it at all.

#3

Oh I have. My code spends about 30% of the time drawing the background using graphics.drawImage(). About 70% of time is spent overal in graphics.drawImage(). I’m not actually doing that much so I thought I may be doing something wrong. My resolution is current 800 x 600 and is made up of 32x32 tiles.
thanks, D.

#4

Make sure that tempImage that you get from ImageIO is actually the same format exactly as the “compatible” image… basically paint it to a compatible image and use that compatible image to paint from instead of the originally loaded image.

The idea behind this is that if any sort of pixel format conversion needs to take place you don’t end up doing it every time you paint the image. In Java 5 tempImage shoudl be a “managed image” and it will get accelerated by something akin to a VolatileImage automatically by the graphics pipeline… so maybe this advice doesn’t apply.

#5

Oh good. Knowing that I too ka closer look.

At a glance your problem is probably the TRANSLUCENT flag.

Amything other then 1 bit transparency is quite slow in Java2D on Win32 because it is not supported in hadrware in DirectDraw.

You might be able to get away with this on windows if you set the flag that makes it use the optional OGL pipeline.
I forget ehat it is but someone else around here Im sure can tell you.

#6

The problem is that you’re rendering translucent images. As Jeff mentioned, they’re not hardware
accelerated by default on Windows.

You can try the -Dsun.java2d.opengl=true to enable
the optional OpenGL pipeline, or, if you’re running on mustang (Java 6) build, you can also try
the Direct3D pipeline (-Dsun.java2d.d3d=true for windowed mode, it’s enabled by default in
full-screen mode).

Also, as of Java 5 you don’t really need to copy your images to compatible images.
If the image can be accelerated by the pipeline, it will be, copying it to a compatible
image won’t help unless your image is translucent and you’re converting it to
an opaque or bitmask image.

Thanks,
Dmitri

#7

OK guys now you got me thinking… I use pngs with translucent areas. So this is slow huh? Then I will try to cut down number of traslucent pics I use… :frowning: Question, if I still use pngs but without translucent areas, does java still checks and spends unnecissary time on translucency? Thanks.

#8

I don’t believe we’re checking if image has translucent pixels or not when deciding on
the format to use, we use whatever the image format specifies.

Another thing, if you know that your image doesn’t have translucent pixels, you can set
the alpha compositing mode to Src (graphics2d.setAlphaComposite(AlphaCompositing.Src))) when
rendering it, this will help a lot with performance (basically, it will be treated as opaque image).

You can still use 1-bit transparent images, or use one of the non-default pipelines mentioned above.

Thanks,
Dmitri