United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6762511 Translucency is not working on Linux using Metacity
JDK-6762511 : Translucency is not working on Linux using Metacity

Details
Type:
Bug
Submit Date:
2008-10-22
Status:
Closed
Updated Date:
2013-05-01
Project Name:
JDK
Resolved Date:
2009-05-15
Component:
client-libs
OS:
linux
Sub-Component:
2d
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u14 (b04)

Related Reports
Backport:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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)
Yes

Operating System Configuration Information (be specific):
Linux Ubuntu 7.10
Window Manager: Metacity
xdpyinfo:
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
    BIG-REQUESTS
    Composite
    DAMAGE
    DPMS
    Extended-Visual-Information
    MIT-SCREEN-SAVER
    MIT-SHM
    MIT-SUNDRY-NONSTANDARD
    RANDR
    RECORD
    RENDER
    SECURITY
    SHAPE
    SYNC
    TOG-CUP
    X-Resource
    XAccessControlExtension
    XC-APPGROUP
    XC-MISC
    XFIXES
    XFree86-Bigfont
    XFree86-DGA
    XFree86-Misc
    XFree86-VidModeExtension
    XINERAMA
    XInputExtension
    XKEYBOARD
    XTEST
    XVideo
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
    ColormapChangeMask
  number of visuals:    2
  default visual id:  0x21
  visual:
    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:
    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:

Expected:
* 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

Actual:
* 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

                                    

Comments
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'.
                                     
2008-10-23
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.
                                     
2008-11-21
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).
                                     
2008-12-03
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.
                                     
2008-12-08
EVALUATION

Fixed by adding appropriate blits and new X11 surface types (ARGB, ABGR).
                                     
2009-03-20
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.
                                     
2009-05-12



Hardware and Software, Engineered to Work Together