JDK-6361745 : Mustang: Improve the image caching mechanism used by GTK L&F
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,solaris_9
  • CPU: x86,sparc
  • Submitted: 2005-12-10
  • Updated: 2011-03-11
  • Resolved: 2006-06-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b88Fixed
Related Reports
Duplicate :  
JDK-6381475 - Major performance problem with GTKCachingPainter on Ultra 20/NVIDIA Quadro
Description
During the Solaris Desktop Summit we've determined that one of the
reasons for the new GTK L&F not performing as well as the default
Ocean L&F (up to 40% slower in our tests on SwingMark) is that the image
type for the images used for caching the widgets is always translucent.

We've found that some themes don't use translucent pixels when rendering
their components. ClearLooks theme is one example - most of the components
are either opaque or 1-bit transparent. Both of these types of images
can be accelerated by Java2D on X11.

Even in the Blueprint theme some of the widgets are rendered as 
opaque/1-bit transparent.

With a simple hack to GTKCachingPainter.java's createImage to always 
return INT_RGB instead of ARGB (so this is the "best we can get" estimate)
we got about 7% improvement in SwingMark score in the local display case, 
and about 4x (yes, that's 400%) improvement in remote case.
(The local case shows even better improvement if text AA is disabled)

See some suggestions about how to implement this fix in the comments section.
Comments
EVALUATION Currently we must create images before we paint to them. This is how CachedPainter works, and this is unfortunate. We could create just an int[] array beforehand. GTKNativeEngine could paint to it and determine transparency type of the resulting image. Using this type, we could then create a BufferedImage of the appropriate type. Part of the problem is, GTKDefaultEngine requires a Graphics to paint on. I.e. it cannot paint to an int array. The solution is to exempt GTKDefaultEngine from caching. It likely makes sense to move caching from GTKCachingPainter into GTKNativeEngine because the latter will be the only engine that does caching.
26-12-2005