JDK-6762511 : Translucency is not working on Linux using Metacity
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2008-10-22
  • Updated: 2017-02-11
  • Resolved: 2009-05-15
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.
6u14 b04Fixed 7Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
J2SE Version (please include all output from java -version flag):
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

Does this problem occur on J2SE 5.0.x or 6.0?  Yes / No (pick one)

Operating System Configuration Information (be specific):
Linux Ubuntu 7.10
Window Manager: Metacity
name of display:    :0.0
version number:    11.0
vendor string:    The X.Org Foundation
vendor release number:    10300000
X.Org version: 1.3.0
maximum request size:  16777212 bytes
motion buffer size:  256
bitmap unit, bit order, padding:    32, LSBFirst, 32
image byte order:    LSBFirst
number of supported pixmap formats:    7
supported pixmap formats:
    depth 1, bits_per_pixel 1, scanline_pad 32
    depth 4, bits_per_pixel 8, scanline_pad 32
    depth 8, bits_per_pixel 8, scanline_pad 32
    depth 15, bits_per_pixel 16, scanline_pad 32
    depth 16, bits_per_pixel 16, scanline_pad 32
    depth 24, bits_per_pixel 32, scanline_pad 32
    depth 32, bits_per_pixel 32, scanline_pad 32
keycode range:    minimum 8, maximum 255
focus:  window 0x2801083, revert to Parent
number of extensions:    29
default screen number:    0
number of screens:    1

screen #0:
  dimensions:    800x600 pixels (323x242 millimeters)
  resolution:    63x63 dots per inch
  depths (7):    16, 1, 4, 8, 15, 24, 32
  root window id:    0x3b
  depth of root window:    16 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    64
  preallocated pixels:    black 0, white 65535
  options:    backing-store NO, save-unders NO
  largest cursor:    800x600
  current input event mask:    0xfa0033
    KeyPressMask             KeyReleaseMask           EnterWindowMask
    LeaveWindowMask          StructureNotifyMask      SubstructureNotifyMask
    SubstructureRedirectMask FocusChangeMask          PropertyChangeMask
  number of visuals:    2
  default visual id:  0x21
    visual id:    0x21
    class:    TrueColor
    depth:    16 planes
    available colormap entries:    64 per subfield
    red, green, blue masks:    0xf800, 0x7e0, 0x1f
    significant bits in color specification:    6 bits
    visual id:    0x39
    class:    TrueColor
    depth:    32 planes
    available colormap entries:    256 per subfield
    red, green, blue masks:    0xff0000, 0xff00, 0xff
    significant bits in color specification:    8 bits

Bug Description:

Translucency is not working on Linux using Metacity
According to the documentation Translucency on Linux using Metacity should work: 'X11: if running a composite (or compositing window-) manager like Compiz'.

Run the code below:

* All 4 buttons to be enabled.
* The 'Output Graphics Configurations' button should output the Graphics Configurations
* The 'Test PERPIXEL_TRANSLUCENT' button should show a frame with the left third completely transparent (the cursor will control whatever is under it),
the middle third very transparent (the crosshair cursor should be shown when over this third),
the right third semi translucent (half way between red and the underlying color)
* The 'Test PERPIXEL_TRANSPARENT' button should show a circle shaped frame
* The 'Test TRANSLUCENT' button should show a a semi translucent frame

* The first 3 buttons are enabled and the 'Test TRANSLUCENT' button is not
* The 'Output Graphics Configurations' button outputs:
X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x21] is Translucency Capable: false
X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x39] is Translucency Capable: true
* The 'Test PERPIXEL_TRANSLUCENT' button shows a Frame with the left two thirds completely black (with the crosshair cursor),
the right third is half way between red and black [this is a very big problem - we can't have users seeing that]
* The 'Test PERPIXEL_TRANSPARENT' button should show a circle shaped frame (this works as expected)
* isTranslucencySupported(TRANSLUCENT) is returning false so we don't even know the results here

EVALUATION Note: the fix has been rolled back from JDK7/M3 with 6838046 due to a build failure. It's going to be pushed again under 6839999.

EVALUATION Fixed by adding appropriate blits and new X11 surface types (ARGB, ABGR).

EVALUATION Comments from the Java2D team regarding the incorrect colors on transparent frames: Basically, Java2D doesn't know that it renders to a translucent destination. If you ask for a translucent GC's ColorModel, it will return RGB, not ARGB ColorModel. In order to to that the surface needs to be properly identified so that correct loops were used. I'm surprised that it works at all, actually. Here's what needs to be done: - When creating a color model for this graphics configuration, it needs to create ARGB color model. This is done in X11Color.c:jobject awtJNI_GetColorModel(JNIEnv *env, AwtGraphicsConfigDataPtr aData) It needs to detect this visual and create proper ColorModel. - then there will need to be changes made to X11SurfaceData.java to recognize that window surface can be non-opaque. This is done in public static SurfaceType getSurfaceType(X11GraphicsConfig gc, boolean transparent) We'll need to create a special surface type (same class) so that proper loops are used.

EVALUATION Regarding the PERPIXEL_TRANSLUCENT kind of transparency support: Actually the system using the xcompmgr reports this as supported - and this in fact is true. The RENDER extension provides the necessary alpha-enabled visual that supports perpixel-transparent windows. It seems that the problem is with the Java2D graphics pipeline used on X11 platforms which works quite incorrectly with alpha-enabled visuals (i.e. it mixes up the bits of color representation which makes the windows look awkward). The bug with displaying the wrong colors can even be reproduced when running on a quite well-supported configuration (the modern Compiz window manager).

EVALUATION One of the problem arises with the TRANSLUCENT kind of transparency. It is reported as unsupported on Metacity, however the effect itself can be turned on by other means (say, using the JNA's implementation of window effects). In order to have the TRANSLUCENT option available, the window manager should report the _NET_WM_WINDOW_OPACITY hint as supported. Compiz does so, hence we enable this kind of transparency. Neither Metacity, nor xcompmgr report this hint as supported, therefore we do not enable this effect. This is a defect in the window manager rather than in Java.

EVALUATION It seems that the problem is caused by a misconfigured window manager. For the GNOME environment it is recommended to open the following dialog: System -> Preferences -> Appearance -> Visual effects and check if the settings there differ from 'None'. If setting the 'Normal' (or some higher) level of the effects fixes the problem, the change request should be closed as 'Not a Defect'.