Bug ID: JDK-4498974 VolatileImage not hardware-accelerated on Linux

Type: Enhancement
Component: client-libs
Sub-Component: 2d
Affected Version: 1.4.0

Priority: P4
Status: Resolved
Resolution: Fixed
OS: linux
CPU: x86

Submitted: 2001-08-31
Updated: 2003-08-12
Resolved: 2003-08-12

Other
5.0 tigerFixed


Name: yyT116575			Date: 08/31/2001


maturin 27% java -version
java version "1.4.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-beta-b65)
Java HotSpot(TM) Client VM (build 1.4.0-beta-b65, mixed mode)

It appears that there is no support for VolatileImages under linux (RH7.1).

Code using VolatileImages has a framerate about 3 times slower under linux than
under Win98, on the same hardware.

The CapabilitiesTest program from
http://java.sun.com/docs/books/tutorial/extra/fullscreen/example.html
shows that VolatileImages aren't enabled under linux (although they are on the
same machine under win98.)
(Review ID: 131134) 
======================================================================

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger

14-06-2004

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

12-08-2003

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

04-09-2001