Only situation I can think of that could cause that (excluding driver peculiarities) would be :-

1) If you were using Java 1.52) and you didn't have the OGL pipeline enabled3) and you were using createCompatibleVolatileImage(w,h,transparency)4) and you were drawing the image onto an unaccelerated surface.

In that situation, the volatile Image with translucency would be created in main memory (because, by my understanding translucent volatile images arn't accelerated by default in 1.5)Where as the bitmask volatile image would be created in vram.

Obviously with the target image in main memory not vram,a main -> main blit would be quicker than a vram -> main blit. (due to vram readback being painfully slow )

1. I don't qualify for 3). it's a BufferedImage.2. i think you're wrong... the createCompatible... means it creates the image most suited for the enviroment. if the enviroment uses an accelerated buffer (in vram) the image would (try) to be in vram too. if the back buffer is not in vram i think the image wouldn't be in vram neither.

i think the images can't be cached as they are bigger than 256X256...anyway, i'm getting really frustrated with all this unexcpected behaviour...

createCompatibleImage(w,h,transparency) _attempts_ create an image most suitablefor rendering to the device. Buf if you're trying to create a translucent compatible image,there may be no way to have anything more suitable than just plain IntArgb BufferedImage.

As translucent images weren't accelerated in 5.0, rendering them to a volatileImage would cause the latter to be punted to system memory to avoid doing readbacks from vram.

Some data on your environment (video board, os) wouldn't hurt, btw.

Also, -Dsun.java2d.trace=count is your friend. Run with this option with your images being loaded as translucent and as bitmask images. From that it'd be easierto see what loops are being used.

//this transforms the coordinate system from( X left to right ,Y up to down) to( X left to right, Y down to up) G2.setTransform(StartAT); //theMountains is an array of Mountain objects for(int i=0;i<theMountains.length;i++) { theMountains.draw(g); } g.dispose(); strategy.show();}you see something that i'm doing wrong?

Therefor, both BITMASK and TRANSLUCENT images are being drawn through the software blit loops.

Now, because TRANSLUCENT blits require readback from the BufferStrategy's VolatileImage back buffer,the rendering pipeline is being sensible and shunting the backbuffer out of vram permanently.Giving you lots of main memory -> main memory blits, followed by just a single main memory ->vram blit at the end.This would be ok if you have fast system memory.

Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)?

No way, are you serious? Uppercase T for verbose mode?

Kev

Good isn't it

Just think of all the hidden options you could have!

Almost as good as a png chunk name

Yeah, yeah, okay, mea culpa. I can't believe how much flack we've caught for this one. I remember reading a blog where some developer was fuming over the whole 't'/'T' thing. I guess he really must've run out of things to complain about if something like this could keep him up at night

Did you use -Dsun.java2d.opengl=True (with an uppercase 'T' for verbose mode)? If so, what do you see printed to the console?

Chris

well, i've run it with -Dsun.java2d.opengl=True, and it outputed to the console: "OpenGL pipeline enabled for default config on screen 0". that's it...

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.

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.

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.

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.

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?

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?

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

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

are you refering to the first question (about image sizes), or to the second one (about using texturepaint)?

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

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

so what do i do? chop down every large image into 10 small images?

Quote

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 ;-)

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?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?

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.

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.

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org