->here<- HW accelerated images RFE 5002129

[javazoid]

The RFE posted by Chris is online.

http://developer.java.sun.com/developer/bugParade/bugs/5002129.html

Q to Chis: When you say "hardware accelerated rendering" do you also mean transforms and bilinear/bicubic interpolation ?

Cheers!

[campbell]

Q to Chis: When you say "hardware accelerated rendering" do you also mean transforms and bilinear/bicubic interpolation ?

It depends on which direction you are talking about...

If you render to a VolatileImage (implemented as a pbuffer, in hardware), all rendering operations are accelerated via OpenGL, just as if you had been rendering to the screen.  Refer to the long list of OGL-accelerated operations that I've posted to these forums from time to time (e.g. compositing, bilinear image transforms, etc, etc).

If you copy a VolatileImage to another accelerated surface (i.e. the screen or another VolatileImage), this copy operation will be handled by OpenGL.  In theory, it should be pretty fast, because it's a VRAM->VRAM operation.  But in reality, we've found that straight pbuffer->screen copies are not as performant as say, a texture->screen operation.  This is especially true when you start enabling per-fragment operations, such as blending, or if you specify a non-identity transform.  To answer your question more closely, yes, we will attempt to accelerate pbuffer->screen transforms, but we can only do bilinear in hardware (no bicubic in OGL).  These pbuffer->screen transforms will go through an intermediate texture codepath, so performance will not be as good as if you were transforming a managed image to the screen.  We're working on a solution for this performance issue.

The bottom line is... If all you want is a translucent sprite, and you want to blend it and transform it to your backbuffer, you should probably just use a managed image.  (I mentioned this in the workaround for 5002129.)  If you have a complex scene that changes, and you want to render it into an offscreen, then a (translucent) VolatileImage may be better suited for the task.

Now here's an opportunity to ask a question to the esteemed java-gaming.org community... I know many of you were clamoring for the ability to create translucent VolatileImages, and we added new methods in 1.5 for this purpose.  The question is: how exactly are you planning to use translucent VolatileImages in your game (e.g. motion parallax style backdrops?  simple sprites?  something else?)?

Chris

[princec]

he question is: how exactly are you planning to use translucent VolatileImages in your game (e.g. motion parallax style backdrops?  simple sprites?  something else?)?

Almost exclusively sprites. But that's a loaded question: I use sprites for backgrounds, tiles, glyphs, gidrahs, HUD, and particles. In other words - everything.

To do this, a pretty trivial sprite engine just has to sort a bunch of sprites by layer, and then blit alpha blended sprites onto the backbuffer as fast as its little processor can run, at 60fps

One common optimisation done by normal GL rendering things is to pack related images into a single texture. This is likely to be a sensible thing to do in Java2D as well. Detecting usage of subimages in this way would be very beneficial to performance; having to call glBindTexture for every single image change kills performance if the texture ID changes each time.

Cas

Games published by our own members! Check 'em out!

[swpalmer]

Like Cas says, mainly sprites.  but you can treat the front layers of a parallax background as sprites if you wish.  though if I wanted that I might go straight to a OGL binding.  Remember the days of "dual playfield" mode on the Amiga, combined with COPPER tricks & hardware sprites?  There's nothing quite like that anymore.   Going straight to the 3D processor to get the layering needed seems to be the way to do it these days.

[campbell]

One common optimisation done by normal GL rendering things is to pack related images into a single texture. This is likely to be a sensible thing to do in Java2D as well. Detecting usage of subimages in this way would be very beneficial to performance; having to call glBindTexture for every single image change kills performance if the texture ID changes each time.

Yes, I agree that stuffing multiple sprites into a single image is a valid optimization for Java 2D.  In most cases there is no performance hit for copying/transforming a subimage (using the drawImage() variant that takes src/dst regions).  This is especially beneficial for the OGL pipeline, because there's less chance of texture memory fragmentation.  If you had a bunch of 20x20 sprites, and you put each one into a separate managed image, each of those guys would be cached in a 32x32 texture, which is a waste of texture memory.  If you packed all your sprites efficiently into a 512x512
(or some other power-of-two dimension) image, then you could use the drawImage() variant mentioned above to extract the subregions of your sprite image.  And potentially, as you mention, performance could improve since you're bound to the same texture object for many different sprites.

So it sounds like most people want to use translucent VolatileImages as sprites.  Now here's a follow-on to my last question... Why do you want to use VolatileImages instead of managed images for sprites?

[I would argue that managed images are a better fit for the sprite-based situations you guys mentioned.  The only downside I can think of is the added footprint of the system memory copy, but managed images are certainly easier to deal with than VolatileImages (no worries about incompatible GCs, lost surfaces, etc, that's all taken care of under the hood).  But that's just me; I'd like to see what your reasons are for choosing one over the other.]

Thanks,
Chris

[Abuse]

The only downside I can think of is the added footprint of the system memory copy

But, when using a VolatileImage you have to keep a copy of the contents anyway for restoring it?

I think the answer is, managedImages are what should be used for sprites.

VolatileImages are only useful for backBuffers, and special effects (warp, blur, etc etc), oh, and when a sprites image is modified at runtime. (skid marks on a 2d background track, blast damage etc etc)
Also, when a sprite is a composite of *many* other images, but the images that form the composite change periodically.
(Rendering each of the images in the composite seperately would perhaps be too costly, and storing the composite in a managedImage, would result in a software blit each time the composite needed to be changed)

[swpalmer]

When you were talking about supporting translucency in VolatileImages I assumed that Managed Images were tied to that decision, i.e. if VolatileImages can't do translucency how could Managed Images?

VolatileImages are really just a pain in the *ss.  Most of the time you still need to have the main memory image copy so you can restore your VolatileImage if needed.  Basically VolatileImages ARE Managed Images that *I* have to manage.

The only time to use a Volatile Image is when I need to draw too that image, and I want those drawing operations to be accelerated.  So for sprites it doesn't really make sense.

[javazoid]

Thanks for your reply Chris,

Here's an example of what we're currently doing with Java2D.

http://www.classx.it/classx_gfx/castalia/castaliaintro.m1v

http://www.classx.it/classx_gfx/castalia/castaliaintro4.m1v

http://www.classx.it/classx_gfx/castalia/cst_video0.wmv

http://www.classx.it/classx_gfx/castalia/cst_video1.wmv


These animations, composed by antialiased vector glyphs and bilerped static or animated images are rendered in realtime in PAL (720x576 25Fps) into an offscreen ARGB BufferedImage. Interlace fields are also considered.
We are using an AMD Athlon 1.8 with a Radeon VE.

With the help of some JNI the animations are sent frame by frame to a Matrox Digisuite or CG2000 card and overlayed to incoming video. Castalia is currently one of the first programs around capable to create aftereffects-like animations in realtime for live video applications.

To gain some speed (and loose some accuracy) the Castalia engine can pre-render text Glyphs into character sprites (ARGB BufferedImage) before the playout, but when you have a huge number of them flying around the screen, it is quite impossible to stay in synch with the video beam. This is expecially true when the images must be transformed and bilerped..

What I'm asking is a bit more clear now. Offscreen rendering and offscreen hardware acceleration is vital for my applications.

That's the reason of my enthusiasm around the possibility of having OpeGL acceleration for Java2D.