CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
tiger

FIXED IN:
tiger

INTEGRATED IN:
tiger


                                     

EVALUATION

Reassigning to 2D.  

------------------

The ability to support VolatileImage objects via hardware acceleration is 
a function of 3 factors:
  - The graphics hardware available
  - The graphics capabilities of the OS
  - The underlying graphics drivers used in Java2D

In the case cited by this bug report, the first item is obviously taken
care of, since the graphics capabilities under win98 are the same as
those under Linux.

But it is the second and third factors that prevent VolatileImage objects
from being accelerated on Linux.

Spcifically, there is no standard way through X to get at the offscreen 
memory available on any given system.  Without being able to store
and manipulate images in that memory, it is impossible to create and
use VolatileImages using hardware acceleration.  Thus, given the
current architecture of Java2D (specifically, our use of X as the main
rendering platform on Unix), there is no way to hardware-accelerate 
VolatileImages on any Unix system.

It might be possible in a future release to use a different underlying
graphics engine to access this capability on platforms which support
it.  For example, OpenGL might be an avenue to access hardware acceleration
features which are otherwise unavailable through X.  The alternatives
are being investigated and we will hopefully be able to provide this
capability in the future (although the amount of work involved in this
substantial project obviously precludes it from making the jdk1.4 release).

Since this bug is more a factor of the limitations of Linux/Unix than 
problems in Java2D, I'm closing the bug as "Will not fix".

###@###.### 2001-09-04

-----------------------------

I wanted to clarify the evaulation above.  It _is_ possible for Linux (or
any platform) to implement the low-level graphics API's such that they
take advantage of hardware acceleration when available.  For example,
some Linux platforms/configurations may cache pixmap objects in hardware
and thus take advantage of hardware acceleration for those images which
use pixmaps (see the "Comments" field for how to ensure the use
of pixmaps for VolatileImage objects).

However, it is beyond the control of Java2D whether and how these API's 
(such as X) get implemented on any particular platform, so the acceleration
available to Java2D on any given platform is gated by constraints beyond
our control.

As stated above, future work (post-jdk1.4) will include investigating
low-level graphics API's (such as OpenGL) which may allow more explicit
use of and control over acceleration features.

###@###.### 2001-09-05

If possible, please attach the application mentioned in 
4502603 (which has been closed as a dup of this one) which shows
such a dramatic difference between Win32 and Linux.

###@###.### 2001-09-13

In response to JDC comments.

Please check out bug
  4492517: VolatileImage and Image performance slow on Linux

Fix for this bug has been recently put back and will appear in beta3.
Fix includes use of Shared Memory extension and shared memory pixmaps.
Use of pixmaps for storing offscreen images is now the default on the systems
for which we don't have DGA support (that'd be Linux, Solaris x86 and
Solaris Sparc with some framebuffers).

Use of DGA on Linux won't happen in 1.4 for sure.

Could you please clarify how exactly do you use image in the 
background? Is it rendered to the background every frame?
What java version you're using? beta or beta2?
There were some improvements in beta2 which allowed toolkit
images (ones loaded with Toolkit.getImage) to be cached in
the pixmaps. Try it out. You'd need to use
-Dsun.java2d.remote=true, however, to make it work.

###@###.### 2001-09-26

I got all the needed information from the JDC comments.

###@###.### 2001-12-10

Pixmaps are now used by default (as of merlin-rc2) for accelerating offscreen
images in case DGA is not available (which is the case on Linux).

I'm changing this bug to rfe as technically the doc doesn't
require VolatileImage to be hardware accelerated.

###@###.### 2002-05-08

Now that the OpenGL-based Java 2D pipeline is in place for Tiger, VolatileImages
are accelerated in hardware (if the configuration is OGL-enabled) on both
Solaris and Linux via pbuffers.  The various VolatileImage and MultiBuffer
testcases, such as FireStarter, show vast improvements in framerate over the
existing X11-based pipeline when the OGL pipeline is used.  Framerates for some
of these testcases are comparable on the same hardware configuration, whether
they are run under Windows or Linux (with OGL enabled).

Note that some OpenGL implementations (such as ATI's Linux drivers) do not yet
fully support pbuffers, so VolatileImage performance may be lower on such
configurations.  We are investigating ways to provide accelerated offscreen
surfaces without the use of pbuffers (such as OpenGL AUX buffers).

At this point, I think we've done everything in our superhuman strength to get
the best VolatileImage performance with both the X11 and OGL pipelines.
Therefore, I'm marking this RFE as "fixed and integrated" in Tiger.
###@###.### 2003-08-12
                                     

WORK AROUND

Run the java with -Dsun.java2d.pmoffscreen=true

###@###.### 2001-09-04

Another workaround which might help:
-Dsun.java2d.remote=true

###@###.### 2001-09-13