JDK-6687141 : perpixel translucent windows are not hw-accelerated, updates are slow on Windows
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-04-10
  • Updated: 2011-03-30
  • Resolved: 2008-04-26
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
6u10 b23Fixed
Related Reports
Relates :  
JDK-6710012 - Per pixel translucency not working on X
Relates :  
JDK-6633275 - Need to support shaped/translucent windows
Relates :  
JDK-6726667 - D3D: sun.java2d.InvalidPipeException is thrown when resizing JInternalFrame in a non-opaque JFrame
Description
Currently the non-opaque windows are rendered with software
pipelines only, and are rather slow on windows. The 
window update mechanism also generats lots of garbage 
causing frequent full collections.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u10/6687141.3
18-04-2008
EVALUATION I have addressed the problem with Swing apps double-painting for translucent window with a simple reordering: we first go through the dirty components, and if they belong to perpixel-translucent top-levels, paint them through the UpdateWindow mechanism, and remove the list. Then process the list with the rest of the dirty components as usual. This cuts the rendering time even for non-accelerated case (when the hw pipeline is not enabled) in half. Another optimization is to always use INT_ARGB_PRE image format (since it's the native format for layered windows, and also happen to be the format in which translucent surfaces are for D3D and OGL) - this eliminates the need for conversion when uploading pixels into the layered window.
15-04-2008
EVALUATION There's little hope of fully accelerated path on Windows XP for perpixel translucent windows since they can only be implemented via layered windows, so at least the last step will be through sw. But on modern PCI Express video boards it is worth it to render the window contents into an accelerated offscreen surface, and then pull that surface from vram to sysmem and update the window using the layered window api. On older PCI and AGP boards the advantage is less pronounced and will be very dependent on the amount of time spent rendering vs uploading to the layered window, which is why this fix will not be enabled for AGP/PCI boards (note that since it is nearly impossible to tell whether or not a board pci express, we rely on board showing hw support for PS_30, which we hope is rough enough equivalent). On Vista there is a way to use fully hw accelerated perpixel translucent windows using DWM-specific APIs. This fix will not go that far but will leave room for integrating it in the future if it proves beneficial. There are still issues with how the updates of Swing windows is handled. Currently each repaint is done twice: once into the Swing's back-buffer, and then once again into the buffer which is then uploaded into the layered window. This will be handled by a separate swing-related bug. Anyway, with this fix, the performance had improved 2-3x, depending on the complexity of the window content; and it also eliminated the full GCs which were happening on each update.
10-04-2008