java swing transparency issues under linux

Question

I'm having a heck of a time getting swing component transparency to work properly under Ubuntu 14.04. For example, if I employ the SwingJD library , the glossy buttons render properly under Windows and OSX but some (not all - I've inspected the source and can't figure out what the difference is between the ones that render correctly and the ones that fail to) don't render properly under Ubuntu 14.04. I've also tried making components like JToolBar translucent to no avail. I know there are issues with Swing and Linux where transparency is concerned, and I've already tried the solutions given here , and here , here , and here with no luck. Has anyone found a way around this problem? I'd hate to have to create a less-asthetically-interesting UI for only Linux users.

here's a direct link to the SwingJD source jar if you want to re-create the issue for yourself. it comes with a test class that has a main method that will render three buttons, two of which won't render correctly under Ubuntu.

EDIT>> constructors for SwingJD

"STANDARD_ORANGE_THEME" works while "STANDARD_LIGHT_ORANGE_THEME" doesn't

    case Theme.STANDARD_ORANGE_THEME:
        buttonColor = new GradientPaint(0, 0, new Color(251, 139, 62), 0,
                height, new Color(255, 102, 0));
        button.setForeground(Color.WHITE);
        break;
    case Theme.STANDARD_LIGHTORANGE_THEME:
        buttonColor = new GradientPaint(0, 0, new Color(247, 174, 24), 0,
                height, new Color(255, 133, 0));
        button.setForeground(Color.WHITE);
        break;

Answer 1

Not every platform supports transparency. I've been on Linux systems that simply did not support transparent windows or components. This is especially true for virtual desktops that don't have access to graphics hardware.

You might try the isWindowTranslucencySupported() function to see for yourself whether your system supports transparency.

From the tutorial on transparency :

import static java.awt.GraphicsDevice.WindowTranslucency.*;

// Determine what the default GraphicsDevice can support.
GraphicsEnvironment ge =
    GraphicsEnvironment.getLocalGraphicsEnvironment();
GraphicsDevice gd = ge.getDefaultScreenDevice();

boolean isUniformTranslucencySupported =
    gd.isWindowTranslucencySupported(TRANSLUCENT);
boolean isPerPixelTranslucencySupported =
    gd.isWindowTranslucencySupported(PERPIXEL_TRANSLUCENT);
boolean isShapedWindowSupported =
    gd.isWindowTranslucencySupported(PERPIXEL_TRANSPARENT);

Answer 2

so far as I can tell, the answer to my question "is there a workaround" is no. there are numerous bugs in the Java Bug Database pertaining to issues like this. this report in particular states the following:

The fix for 6794764 removed the calls to the setDoubleBiffered(false) method from the Window.setLayeresOpaque() private method. Ealier the double buffering was turned off for the glass pane, the root pane, and the content pane when a frame went non-opaque. When double buffering was enabled, the painting was performed incorrectly, thus requiring to turn off the functionality. This, however, had mainly been tested on MS Windows platform due to some issues with the XToolkit implementation of non-opaque windows.

Currently the toolkit-related issues are fixed. However, transparent windows on X11 work incorrectly. If one restores the calls to the setDoubleBuffered() method in the setLayeresOpaque() method, then the windows start displaying OK on X11.

It looks like the fix for 6683775 does not fix the double-buffering issue completely.

As to why this is only reproducible on X11: most probably because, contrary to WToolkit, the XToolkit.needUpdateWindow() returns false. This slightly changes the logic in the RepaintManager class (and, maybe, some other classes in Swing), thus making the painting a bit different.

Since AWT does not explicitly depends on the double-buffered property of components, the painting artifacts are most likely caused by the Swing painting code. The bug is reassigned to Swing for further evaluation.

and this one which states:

Note that until the bug 6848852 is fixed, that is unfeasible to test transparency on X11 because it simply does not work.