JDK-4479178 : RFE: Support for Transparent windows required
  • Type: Enhancement
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    1.0,1.1,1.1.3,1.2.0,1.3.0,1.3.1,1.4.0,1.4.1,5.0 1.0,1.1,1.1.3,1.2.0,1.3.0,1.3.1,1.4.0,1.4.1,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS:
    generic,linux,solaris_2.4,windows_95,windows_2000,windows_xp generic,linux,solaris_2.4,windows_95,windows_2000,windows_xp
  • CPU: generic,x86,sparc
  • Submitted: 2001-07-12
  • Updated: 2009-03-10
  • Resolved: 2009-03-10
Related Reports
Duplicate :  
JDK-4638449 - Non-Rectangular Windows and Transparency
Duplicate :  
JDK-6633275 - Need to support shaped/translucent windows
Duplicate :  
JDK-4034109 - No transparency available for AWT Components and Containers
Relates :  
JDK-4475369 - Using heavyweight over lightweight components we see unacceptable flashing
Relates :  
JDK-6802853 - API: shaped & translucent windows
Relates :  
JDK-5001982 - Partial transparency of lightweight components
Relates :  
JDK-4874070 - invoking DragSource's startDrag with an Image renders no image on drag
Description
Name: bsC130419			Date: 07/12/2001


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)

The AWT should support transparent windows if supported by the native windowing
system such as windows 2000.
(Review ID: 127928) 
======================================================================

Name: gm110360			Date: 12/03/2001


Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

http://java.sun.com/getjava/installer.html

Using the above webpage to determine whether or not the Java Plug-In for
Windows XP is installed causes the entire desktop to flicker uncontrollably.

The problem is due to the extensive use of transparent windows by Windows XP in
conjunction with Java's inability to handle them.

The flicker problem was documented over a year ago (the bug ID has been removed
from the bug database and apparently closed) under Windows 2000.  In Windows
2000 you could correct the problem by bringing up the system desktop (CTRL-ALT-
DEL) and then returning back to the user desktop.  The Java window would
stabilize and the flickering would stop (in some cases).  This is not possible
in Windows XP because the (CTRL-ALT-DEL) sequence does not transition the user
to a system desktop anymore.

This pretty much makes Java extremely difficult (if not impossible) to use on
Windows XP (and still in some cases, Windows 2000).

If needed, I have a VisualBasic test application which allows any window in the
system to be made transparent... this could be used to reproduce the problem
but there is no facility to attach this in the Bug Report.

  Bug ID 4479178 requests this as an enhancement... recommend promoting to a bug
and it being fixed before stating that JDK 1.4 can support Windows XP.
(Review ID: 135845)
======================================================================

Name: gm110360			Date: 02/15/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION : Windows XP Pro (5.1.2600)


A DESCRIPTION OF THE PROBLEM :
Note:  The product version drop-down of this bug reporting
form only allowed me to select JDK 1.4 RC1, but I have the
just released JDK 1.4 (not release candidate).

When the Java Plug-in is the default JRE for IE the
tooltip flashes wildly.  The same goes for the edges of
the Windows XP Start menu.  Sometimes the tooltip or the
pop-up menu associated with a taskbar item will be
corrupted or only displayed briefly.  I have observed this
behaviour in other Java programs - e.g. LimeWire - to
greater or lesser degrees.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
  To recreate:  Make the Java Plug-in the default JRE for
IE.  Restart IE.  Go to Yahoo Games.  Log into one of the
chess game rooms.  Now move the mouse cursor down to the
Windows XP taskbar and hover over a running program.  Note
that the tooltip flashes wildly.  Sometimes the tooltip or
even the pop-up menu will be corrupted or only displayed
briefly.  I have observed this behaviour in other Java
programs - e.g. LimeWire - to greater or lesser degrees.

EXPECTED VERSUS ACTUAL BEHAVIOR :
I expect that tooltips and other screen items will not
flash or be corrupted.

This bug can be reproduced always.

CUSTOMER WORKAROUND :
Turn off the Java Plug-In as the default JRE for IE.
(Review ID: 139651)
======================================================================

Name: jk109818			Date: 07/24/2003


FULL PRODUCT VERSION :
java version "1.4.1-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b19)
Java HotSpot(TM) Client VM (build 1.4.1-rc-b19, mixed mode)


A DESCRIPTION OF THE PROBLEM :
Currently it appears there is no way to create a
non-rectangular toplevel window, such as Clock.exe on
windows, Audion on osx, and XMMS with certain skins under
X11. I'm not asking for full transparency, but mere boolean
per-pixel is-transparent-or-not functionality.

Perhaps a check to see if a JFrame's content pane is opaque,
and if so, set the window to transparent mode to the WM/OS?

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
One could possibly use
Robot.createScreenCapture(window.getBounds()) after
minimizing one's window, then using that as a background for
a frame's content panel.
(Review ID: 180685)
======================================================================
Comments
EVALUATION The CR 6633275 has been delivered to 6u10 and 7. The public API for this feature is covered by 6802853.
10-03-2009
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
16-11-2004
WORK AROUND Name: bsC130419 Date: 07/12/2001 none ======================================================================
02-10-2004