kevglass,
could you confirm that J2DA is faster than Java2D Graphics.drawImage to blit images? After all, Java2D makes calls to DX. If yes, how does it compare in preformance?
J2DA isn’t really a renderer so it doesn’t really have a comparison, its more of an abstraction of how you’re going to render. J2DA allows you to swap and choose between renderers (at the moment Java2D and JOGL).
So if you use the Java2D renderer you’ll find it pretty much the same. If you use the JOGL renderer on a platform with a good graphics card you’ll find it way faster than Java2D simply because its utilises the hardware more directly.
To qualify this a little more the speed improvement is mainly aimed at non-windows operating systems since DX should be as quick. However, running tests we’ve found that when there are a large number of sprites on the screen using OpenGL (JOGL) to render is significantly faster than DX (Java2D).
J2DA is really trying to be a way for us games people to stop worrying about the rendering details and future proof against the next series of developments. A sprite is a sprite is a sprite 
Kev
OK!
Thanks for your explanations. 
[quote]If you use the JOGL renderer on a platform with a good graphics card you’ll find it way faster than Java2D simply because its utilises the hardware more directly.
[/quote]
Can you apply that comparason for DX too?
It certainly appears that you could, but the speed difference may be just down to the way Java 2D is implemented i.e. in the way it uses DX. Java 2D will try and be as generic as possible in its use of DX where as our use of JOGL is fairly specific.
Kev
:o
OK thank you for your so usefull answers!
My next question is addressed to a Java2D developer at Sun:
Will Java2D be optimized to use the full potential speed of DX in J2SE 1.5 or later? Maybe Java2D should be a layer above JOGL instead of DX for performance reasons?
I think you’re missing the point somewhat: current Java2D implementation uses DirectDraw only, not Direct3D. DirectDraw works on pretty much all hardware, not ones with dedicated 3d support meaning its always avalible. However the limitation is that you pretty much only get to do straight image blits, scaling, rotation & alpha blending have to be done in software.
As such, there’d be no point switching to ‘full’ DX since then you might as well use OpenGL via Jogl (or whatever). However this limits you to modern 3d cards for acceptable speed, since old machines will actually run slower when just doing regular image bliting.
Current Java2D implementation (as of 1.4.2) does use Direct3D for some rendering (namely, lines rendered to accelerated surfaces, and rendering of translucent managed images).
In 1.5 we’ll use D3D for rendering of traslucent VolatileImages (including compositing), managed images and lines. It doesn’t look like we’ll have time for much more than that, unfortunately.
/me shoots himself :
[quote]Current Java2D implementation (as of 1.4.2) does use Direct3D for some rendering (namely, lines rendered to accelerated surfaces, and rendering of translucent managed images).
In 1.5 we’ll use D3D for rendering of traslucent VolatileImages (including compositing), managed images and lines. It doesn’t look like we’ll have time for much more than that, unfortunately.
[/quote]
This is great adding alpha channel to images is for games great.
There is only one thing i miss --> hardware accelerated transformations. For Tile based isometric games its a must.
And we need a high performance timer for rendering / game physics. ( Please please )
And what about DirectInput ? Maybe we get a JInput ?
What about interfacing JOGL in Java2D instead of D3D? The Java2D code base would be unified in all supported OpenGL platform.
Regarding the risks of braking existing code, I don’t think it should impact that much since this design change is hidden to the developper. If there is one, it might be a performance difference for certain aspects but that should not be a big issue.
That’s my point of view.
The problem is that on some older systems using OpenGL on windows means software mode, which is hideously slow. Using DirectDraw you may well get accelerated graphics. So the default implementation on windows does really need to use DirectDraw.
There was some talk of having a flag to allow swapping over to OpenGL rendering pipeline, but I guess thats fallen by the way side by the sounds of it.
Kev
/me passes the gun to MGodehardt