EVALUATION
Fix in Tiger
###@###.### 2002-03-04
There seems to be some confusion between the Synopsis (asking for support for
transparent windows) and a lot of the input in the Description field (which
talks about desktop flickering artifacts). I cannot address the RFE part
of this report (asking for transp window support), but as far as the
dekstop flickering, I would encourage users to try jdk1.4.1 Beta (or later
releases). There was a bug fixed recently (4409306) that addressed the
flickering of cursors/menus/tooltips/etc. on win2k and XP; I think that
fix should apply to the problems mentioned in the Description of this bug report.
###@###.### 2002-06-17
Using the prototype from ###@###.###, we tested translucency on different platforms with different acceleration options. We were investigating only top-level translucency.
---------------- Windows (###@###.###)-------------------
Layered windows seem to be the only reasonable way of implementing this
(Win2K/XP only). Win32 API provides two ways of updating layered
windows, both may be used in the implementation:
a) SetLayeredWindowAttributes: this function makes it possible to
employ translucency with no changes to the way of updating the window.
The system provides the backbuffer for the window, uses the normal
WM_PAINT mechanism with output redirected to the backbuffer and updates
the window automatically.
Certain problems were found with this approach. First, it is
incompatible with DirectDraw acceleration (this is natural, as
DirectDraw circumvents any double-buffering provided by
the system for layered windows). Second, I could not find a way to
control the frequency of window updates. GDIFlush does not force an
update of the screen surface and no API seems to exist for it. SwingMark
shows a performance increase (10-15%, no DirectDraw) when its frame is made
layered, but as the real on-screen window updates are rare, the interface
looks very sluggish.
The problems might be because of our empty WM_PAINT, if we implemented WM_PAINT
that transfers back-buffer to the screen, they might be resolved.
b) UpdateLayeredWindow: this function updates the window manually, at
any desired moment. In this case WM_PAINT is not used for updating the
window contents at all. It is our responsibility to provide a
back-buffer for the window, render to it, then call UpdateLayeredWindow.
This approach may be the way of choice if we provide complete double
buffering for a toplevel window - and this is currently planned for
Swing anyway. We have not tried this approach yet, however, as I understand,
it can be implemented using the latests swing-db workspace.
###@###.### 2004-11-16 13:11:29 GMT
|
Java