Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6687141
Votes 0
Synopsis perpixel translucent windows are not hw-accelerated, updates are slow on Windows
Category java:classes_2d
Reported Against
Release Fixed 6u10(b23)
State 10-Fix Delivered, Verified, bug
Priority: 3-Medium
Related Bugs
Submit Date 10-APR-2008
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.
Posted Date : 2008-04-10 23:26:45.0
Work Around
N/A
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.
Posted Date : 2008-04-10 23:26:45.0

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.
Posted Date : 2008-04-15 21:01:46.0
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang