Okay, that’s a start. As Dmitri said above, -Dsun.java2d.trace=count is your friend. That will tell you what is being accelerated by the OGL pipeline, and what is not. So try again with both the opengl and trace flags, and post the output here.
Chris
here it is:
62 calls to OGLDrawGlyphs
468 calls to sun.java2d.opengl.OGLTextureToSurfaceTransform::TransformBlit(“OpenGL Texture”, AnyAlpha, “OpenGL Surface”)
41 calls to OGLDrawRect
36 calls to sun.java2d.opengl.OGLRTTSurfaceToSurfaceBlit::Blit(“OpenGL Surface (render-to-texture)”, AnyAlpha, “OpenGL Surface”)
6 calls to sun.java2d.opengl.OGLSwToTextureBlit::Blit(IntArgbPre, SrcNoEa, “OpenGL Texture”)
38 calls to OGLDrawPoly
82 calls to OGLDrawLine
57 calls to sun.java2d.loops.DrawPolygons::DrawPolygons(OpaqueColor, SrcNoEa, AnyInt)
38291 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntArgbBm, SrcOverNoEa, “OpenGL Surface”)
37 calls to sun.java2d.loops.Blit$GeneralMaskBlit::Blit(IntRgb, SrcNoEa, IntArgbBm)
37 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgb)
37 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(IntRgb, SrcNoEa, IntArgbBm)
2866 calls to OGLFillSpans
39351 calls to sun.java2d.loops.Blit::Blit(IntArgb, SrcNoEa, IntArgbPre)
39363 calls to sun.java2d.opengl.OGLMaskBlit::MaskBlit(IntArgb, SrcOver, “OpenGL Surface”)
2 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntRgb)
37 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntArgb, AnyAlpha, IntArgbBm)
449 calls to sun.java2d.loops.MaskBlit::MaskBlit(IntRgb, AnyAlpha, IntArgbPre)
39602 calls to sun.java2d.opengl.OGLDelegateBlit::Blit(IntArgb, AnyAlpha, “OpenGL Surface”)
40731 calls to sun.java2d.loops.Blit::Blit(IntRgb, SrcNoEa, IntArgbPre)
39614 calls to sun.java2d.loops.MaskBlit$General::MaskBlit(IntArgbBm, SrcOverNoEa, “OpenGL Surface”)
630 calls to sun.java2d.loops.MaskFill::MaskFill(AnyColor, Src, IntArgbPre)
39623 calls to sun.java2d.loops.Blit::Blit(IntArgbBm, SrcNoEa, IntArgb)
188 calls to OGLFillRect
6 calls to sun.java2d.opengl.OGLSwToSurfaceTransform::TransformBlit(IntArgbPre, AnyAlpha, “OpenGL Surface”)
282636 total calls to 25 different primitives
what’s the conclusion?
Well, it’s still a bit hard to tell since you only show us a snippet of your source code. But anyway, how many images are there in your “mountains” array? Are there any other BufferedImages being used in your app? And how large are they?
You can see from the trace output above that 6 images are being properly cached in texture memory. But there are many other software blit calls (all those OGLMaskBlits) which leads me to suspect that your other images are not being cached for some reason (maybe because you’re grabbing the Raster/DataBuffer using getRaster() and getData()?)… You can use -Dsun.java2d.trace=log to see where these software blit calls are coming from in your application and it will give you an idea of which images are problematic.
Chris
Finally, a breakthrough!
i don’t know how i haven’t noticed it before, but the drawing only takes long for only two pictures(though smaller ones are not cached either)- the extremely large ones, at the size of about 1066X266 (backgound) and the other at 65X1100. is this too big for caching. i’m also not drawing the image by using drawImage but instead i create a texturepaint object in order to wrap the image all over the screen. could this be a problem too?
yup
That is some extremely bad sizes for images. It’s possible that they have to be stored in pow2 textures in wich case you’ll really be using a 2048x512 and 128x2048 backgrounds. Max 512x512 would be safe in opengl and 256x256 would be the optimal for the default pipeline. I think :-\
are you refering to the first question (about image sizes), or to the second one (about using texturepaint)?
so what do i do? chop down every large image into 10 small images?
so what do i do? chop down every large image into 10 small images?
Well each image (this only applies to todays OpenGL implementations, there are already boards supporting “normal” sizes too) is cache in an OpenGL Texture which has to be x^2 size. so either 64, 128, 256, 512, 1024, 2048 … and boom since this is the texture-size limit of ATI cards 
So if you could resize your two background-images to 1024x256 and 64x1024 you would save for those two images 75% of texture memory.
Which card are you using? How much memory does it have?
Regarding to the texture-paint problem I don’t know - however it should’nt be too hard to try yourself
lg Clemens
i’m using nvidia geforce mx400, with 60 mb of memory.
i’ve reduced the images sizes to 1024x256 and 64x1024, but they are still not cached… maybe they’re just too big?
Yes, that’s good advice from the other guys to try to use power-of-two dimensions. We still handle non-pow2 dimensions internally, but in most cases we have to allocate a pow2-sized texture, so it can be a huge waste of VRAM if you have a 1066X266 BufferedImage, since that will require a 2048x512 texture (as the others have said). I think GF2 MX400 has a maximum texture size of 2048x2048, so even your old images have the potential to be cached.
BTW, this is a great resource for finding out the capabilities of all kinds of graphics hardware, like available extensions, texture size limits, etc:
http://www.delphi3d.net/hardware/index.php
Anyway, I think I may know why your image isn’t being cached when you use TexturePaint. In JDK 5, TexturePaint operations will be accelerated by the OGL pipeline, but only if antialiasing is disabled, and only if the image has pow2 dimensions. This is a reasonable restriction in cases like yours where you are using TexturePaint to tile a background image (AA will be of little use in this case). So check to see if you have AA enabled when you use TexturePaint, and if so, comment that line out.
This is covered in my article “Behind The Graphics2D: The OpenGL-based Pipeline”:
http://today.java.net/pub/a/today/2004/11/12/graphics2d.html
Note that you could get around either/both of these TexturePaint restrictions by tiling your image manually with drawImage(). But I think the advice given to you so far about using pow2-sized images is useful, and TexturePaint was created for situations like yours, so give it a try and let us know if it helps.
Chris
even if don’t use texture paint but instead use drawimage (which gives a static, non scrolling background), the images are still not cached, and the painting takes even longer… maybe there’s something else beside Antialiasing that can prevent caching?
After trying to add and remove all sort of things to my code, i finally realized what’s my mistake- during the loading of the images from bitmap files, i’ve used a pixel grabber to make some pixel transparent. when i marked this line out the images were being accelerated. so i’ve solved my problem. my final question is, why does using a pixelgrabber on an image prevent it from being accelerated?
thanks, noam
Hmm, would be quite easier to analyze whats going wrong if you would have told us the full story other than “I am just loading a few images and paint then”.
Hmm, thats a bit strange - are the images BufferedImages (guess not otherwise no need for PixelGrabber) or Toolkit-Images. The grabbing itself (at least for BufferedImages) should not slow down drawing at all but furthermore the way how you set the pixel-values of the image again.
Furthermore if java2d sees lot of pixel-changes in a BufferedImage it doesn’t it cache anymore too if it is not blitted very often - however I’ve just read that and did not find out the correct semantics but I guess they are not that clever.
If you’ve stolen its Raster things are pretty much clean ->the internal “rasterStolen” variable is set and no accerlation at all takes place (to ensure that the actual pixel data is equal to the data which gets painted).
lg Clemens