I'm trying to write a HUD for a 2d project , I want it to basically be a translucent black rectangle w/ items on it. I can draw directly to the Graphics object and everything works but it is painfully slow. When I try to use a buffered image instead, it always comes out solid black. I'm using the hardware acceleration flags. Any Ideas? Here is the code:

Without hardware acceleration it would be. Software alpha blending would require a read-modify-write to the graphics memory and reading from VRAM is VERY slow.

Maybe it is not accelerated for some reason.. you said you were using the flags to enable translucent HW acceleration.. but perhaps it isn't kicking in? See if not setting those properties slows it down even more.

Thanks for the great reply, but I still can't draw a translucent background on th hud as soon as I do, it slows right down. However other hud items do show up translucent, ands don't seem to affect rendering speed. If i hack and use a black rectangle image, it is still slow, probably because it is too big for vram, so I make a 16x16 one and drawImage. This is translucent and doesn't slow rendering speed. How Do I draw it larger than It actually IS. i.e. scaled?

you can completely forget about the Java2D API, and start learning the JOGL, JOAL and JInput APIs.Put simply they are the future for Games on the Java platform.

Thanks for the advice, but the whole reason I started this project is because my laptop (the machine I develop on) doesn't support J3D/ gl4java/ lwjgl quite well enough SO I was so excited to see I could actually get a good framerate w/ Java2D. Anyways this project is a learning experience, It won't kill me to wait for 1.5.

Again - somebody spouting on about how the only thing that is important in gaming is getting fast flash graphics to the screen and only [insert your own API] is good enough. blah blah blah blah blah...

Quote

There is nothing wrong with tieing yourself to 1 API; just make sure its a capable API. Java2D is NOT. LWJGL is. JOGL will be.

> AlphaCompositing is only accelerated when being applied to an > image that is already in ARGB format.> VolatileImages are RGB, hence applying an AlphaComposite to the > image will NOT be accelerated.

This is not correct: assuming appropriate flag is set, AlphaCompositing operations will be acceleratedif source image was created with createCompatibleImage(w,h,Transparency.TRANSLUCENT), and the destination is eitherscreen or VolatileImage.VolatileImage, which is the destination in this case, is typically accelerated.

The problem is likely that the source image is being modifiedon each frame, so it never gets accelerated.

You can use tracing flags to check if accelelrated loops arebeing used:java -Dsun.java2d.trace=log YourApp

I was saying that applying an AlphaComposite operation to an image that has no Alpha Channel will NOT be accelerated.Even if the image being used is a ManagedImage.

e.g.drawn with an AlphaComposite :-

VolatileImages will NOT be accelerated.

ManagedImages with OPAQUE or BITMASK will NOT be accelerated

Only if the ManagedImage is TRANSLUCENT will the AlphaComposite be accelerated.

(if these assertions above are incorrect, pls pls pls correct me )(oh and im talking about the source image type. The destination image in all cases is a VolatileImage [or whatever the hell it is that is used for the backbuffers in BufferStrategy])

Now the problem the poster had; was that he wanted an image in VRAM that he could modify, and then blit to the screen using an AlphaComposite.Obviously, as i stated earlier, and u repeated in your post, if you write to a ManagedImage, the copy in VRAM becomes invalid.This leaves you the only other alternative of using a VolatileImage, but VolatileImages are not accelerated when drawn with an AlphaComposite.Hence my ultimate summary. He is screwed

Yeah, looks like I misunderstood your posting. We're basically on the same page.But I don't think he's screwed completely =)

One way he can fix this is have any text he wants to render to be stored in translucent images. Say, have image for all of the numbers, and letters, or just have one image with whole alphabet rendered to it. Then using a simple lookup (symbol -> coordinates of the corresponding image) he can blit from that image with compositing to the screen and have it accelerated. This is a well known technique.

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