Skip to main content

Yet the Per-Pixel Translucency problem

33 replies [Last post]
ajmmm
Offline
Joined: 2008-07-04
Points: 0

Hello, all!

I'm still trying to have a cross platform application using per pixel translucency.

I'm creating a JFrame with a proper GraphicsConfiguration, calling AWTUtilities.setWindowOpaque(w,false),adding a JPanel and setting the panel's color to (0,0,0,1).
Then, I overload the paint() method in the panel to paint what is needed.

Currently, I'm founding this:

-In Windows, with jre6u18b03, I must call super.paintComponent() instead of super.paint() inside the overidden paint() method; otherwise, background is not repainted (in each repaint it gets more opaque).
-In Windows, with other than jre6u18b03, I must call panel.setDoubleBuffered(false) in same configuration to work (OK, this is expected).
-In Windows, if I call panel.setOpaque(false), the panel never gets mouse events, unless mouse cursor is over an opaque pixel.

-In Linux, I must call panel.setOpaque(false); otherwise, I get the same "pregressevly more opaque" background. However, (as expected), inside the overridden paint() method I must call super.paint(g); Performance is much better tha in windows.

-In Mac, I cannot use AWTUtilities, but changing frame's background color to something with "alpha", it gets translucent. But, ... repainting is always wrong. The result from previous painting operation is not cleared before perform next paint. As a result, a mouse pointer moving becomes a mouse track.

Enable or disabel opengl, all other tricks didn't help, until now.

The guidelines that state "remove decoration, set frame translucent, set double buffering false" seem to be variable,... or I'm completely confused.

Can someone please help me again?

Thank you!

Antonio

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
anthony_p
Offline
Joined: 2006-07-24
Points: 0

and btw, what platform are you running on currently?

jasper72
Offline
Joined: 2007-12-25
Points: 0

windows.
as i said earlier mac has always displayed this behavior
linux is broken too but i've not got around to understand it properly

anthony_p
Offline
Joined: 2006-07-24
Points: 0

Since that problem pops up in u18, then this must be a regression of 6794764.

Could you please perform one more experiment: make *all* components in the frame non-double-buffered recursively after switching to the non-opaque mode and see if that resolves anything.

In any case, could you provide us with a simplest code sample that clearly reproduces the problem?

jasper72
Offline
Joined: 2007-12-25
Points: 0

While I think there are several problems I think I can refine the worst:

When a component moves within a translucent parent panel (inside a across a transparent frame and), the parent is not repainting the space that the component previously occupied.

One needs to invoke repaint on the frame itself to clean up.

I'll speculate that the pixel darkening has the same cause.

And I'll emphasize again; this was introduced in u18

jasper72
Offline
Joined: 2007-12-25
Points: 0

i meant to say...

(inside a transparent frame)

anthony_p
Offline
Joined: 2006-07-24
Points: 0

I'm really sorry about your mental health, Antonio. :)

Yet I've managed to read the whole message that you posted. Please note that the tag "code" must be in lower case, then it will work OK.

Anyways,

[code]
frame.setBackground(new Color(0,0,0,1)); //???
[/code]

Exactly ??? ? Why are you doing that? 6u18 is not supposed to handle transparent windows correctly when their background color differs from (0, 0, 0, 0). Please remove that line.

[code]
canvas.setBackground(new Color(0,0,0,1));
[/code]

This, however, should work fine.

[code]
//canvas.setOpaque(false);
[/code]

Well, the opaqueness defines whether Swing paints the background of components. When you set it to false, the background color of the canvas you've just set won't matter at all. So, this call is commented out correctly. You don't need it for your purposes.

[code]
canvas.setBounds(frame.getBounds());
[/code]

Instead I suggest to set the BorderLayout to the frame, then the canvas will always occupy the whole frame w/o necessity to set its bounds.

By the way, since you have to [code]setUndecorated(true)[/code], you don't really need to set neither the title, nor the default close operation since the decorations are not available anyway. Also it looks strange why you want to [code]setName()[/code], but that should be harmless I guess.

I see what you're trying to achieve with that application, however be aware that while such window is shown on the screen, it catches all the events not letting them go thru, making other applications virtually disabled.

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Hello, Anthony and Ixmal,

I must present my apologies for my behaviour, but it was not intentional.
In fact, this development is articulated with many other tasks. Sometimes this gets the highest priority and I must push my limits on it. Then, some other thing arises and I must change again.
In this case, I thaught no one would have post messages after my last reply. I was working in a paper and, when trying to get again in this subject, I found your help.
I'm starting a new clean project to try to understand this, as current situation is still the previous: -It just works with older JREs (like u10b33) but not with the recent ones.
I'll post my results, whatever they are.

For now, and as Xmas is already elapsed too,
Thank you and a perfect 2010!!

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Hello, again!

I tried to follow all the guidelines and trim unuseful code. The result are two classes as follows below:

[code]

package transltest;

import com.sun.awt.AWTUtilities;
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Dimension;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.Toolkit;
import javax.swing.JDialog;

public class Main
{
private JDialog frame;
private GraphicsConfiguration gc;
private BorderLayout bl;
public Mc mainCanvas;

public Main()
{
GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
try
{
GraphicsDevice[] devices = env.getScreenDevices();
for (int i = 0; i < devices.length &&frame==null;i++)
{
GraphicsConfiguration[] configs = devices[i].getConfigurations();
for (int j = 0; j < configs.length ;j++)
{
System.out.println("Config "+j+": "+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSPARENT));
if (AWTUtilities.isTranslucencyCapable(configs[j]))
{
System.out.println("YES,"+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSPARENT));
gc=configs[j];
break;
}
}
}
}catch(Exception e)
{
gc=env.getDefaultScreenDevice().getDefaultConfiguration();
e.printStackTrace();
}

frame=new JDialog((JDialog)null,"",false,gc);
frame.setUndecorated(true);
try{AWTUtilities.setWindowOpaque(frame, false);}catch(Exception e){e.printStackTrace();}
System.out.println(frame.getGraphicsConfiguration());
Dimension d=Toolkit.getDefaultToolkit().getScreenSize();
frame.setBounds(0,0,d.width,d.height-20);
frame.setLayout(null);
mainCanvas =new Mc();
mainCanvas.setDoubleBuffered(false);
mainCanvas.setBackground(new Color(0,0,0,1));
mainCanvas.setBounds(frame.getBounds());
frame.add(mainCanvas);
frame.setVisible(true);
}

public static void main(String[] args)
{
Main main=new Main();
}

}

package transltest;

import java.awt.Color;
import java.awt.Graphics;
import java.awt.event.MouseEvent;
import java.awt.event.MouseMotionAdapter;
import javax.swing.JPanel;

public class Mc extends JPanel
{
int x=0;
int y=0;
int c=0;

public Mc()
{
addMouseMotionListener
(
new MouseMotionAdapter()
{
public void mouseDragged( MouseEvent e )
{
x=e.getX();
y=e.getY();
c++;
repaint();
}
}
);
}

@Override
public void paintComponent(Graphics g)
{
super.paintComponent(g);
g.setColor(Color.orange);
g.drawOval(x-4,y-4,8,8);
g.setColor(Color.red);
g.fillOval(x-3,y-3,6,6);
g.drawString("Count:"+c,20,20);
}

}

[/code]

However, the old behaviour persists. In jre 1.6.0_10-b33 it works correctly. In other, namely 1.6.0_18-b05, it seems like the new paiting is performed over the previous, without erasing it.

In linux, with this (at least as I hope...) correct code it doesn't never repaint correctly, as well as in windows and linux with jdk7.

I tried to use only AWT, too, (replacing JDialog per Dialog, JPanel per Panel, and overriding paint() instead of paintComponent(), but after setting AWTUtilities.setWindowOpaque(frame, false), paint() didn't perform any painting at all (even if being executed after each call to repaint(), as expected ).

I don't know really what to do... I'm not in panic because there are at least 2 jre's in which code behaves as expected (1.6.0_10-b33 and 1.6.0_18-b03). In linux I must force "incorrect code" (overloading paint() and calling paintComponent() inside ...) to have it running correctly. However, this seem to be quite strange. Am I the only one in world in this situation? Then, as you proposed, Anthony, I really must be worried about my mental health ;-)

Thank you!

Best regards,
antonio

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Hello!

Just a small update to last message.

Reading again Sun's documentation about Swing and AWT repainting, and found this sentence: "If for some reason the component extension does not want to allow the UI delegate to paint (if, for example, it is completely replacing the component's visuals), it may skip calling super.paintComponent(), but it must be responsible for filling in its own background [...]."

So, I'm calling setOpaque(false) to this JPanel and changed paintComponent() method to:

[code]

public void paintComponent(Graphics g)
{
//super.paintComponent(g);
g.setColor(new Color(0,0,0,1));
g.fillRect(0,0,1024,768);
g.setColor(Color.orange);
g.drawOval(x-4,y-4,8,8);
g.setColor(Color.red);
g.fillOval(x-3,y-3,6,6);
g.drawString("Count:"+c,20,20);
}

[/code]

I have to simulate the non-completely-transparent background filling a rectangle with screen size, to allow mouse listener to get mouse events. However, it works in every windows jre, at least.

Is this too wrong? Is this an acceptable workaround? Even painting that big rectangle, performance doesn't seem to be worse. Interesting, too, with this approach, double buffering can be set true to the JPanel without wrong repainting...

Thank you, again, for your help.

Best regards,
Antonio

anthony_p
Offline
Joined: 2006-07-24
Points: 0

Hi Antonio,

Firstly, the panel indeed needs to be setOpaque(false)'d - this is how transparent components are supposed to be working. Avoiding calling the super.paintComponent() method seems reasonable also, because you really don't need it. However, I would still recommend to leave the panel setDoubleBuffer(false)'d - that makes it safer.

A minor suggestion: your code is violating the Swing threading policy [1]. You should invoke the new Main() on the EDT, like:
[code]
EventQueue.invokeAndWait(new Runnable() {
public void run() {
new Main();
}
});
[/code]
See the link below for more information.

Regarding your previous message: AWT components (Panels or Canvases) are not supported in transparent windows. So that try was hopeless anyway.

And now regarding your current code: it looks OK. For faster updates you could use XOR painting, so that when you paint your ovals and text the second time, it disappears. This way you could avoid clearing the whole screen on each repaint.

I'm glad you've finally got it working!

[1] http://java.sun.com/javase/6/docs/api/javax/swing/package-summary.html#t...

--
best regards,
Anthony

jasper72
Offline
Joined: 2007-12-25
Points: 0

OK, so i tried this code on both 17 and 18; on 18 you have to force the window to repaint; on 17 just the panel; toggle the uncommented repaint code

public static void main (String[] args) {

JFrame frame = new JFrame(); frame.setUndecorated(true); com.sun.awt.AWTUtilities.setWindowOpaque(frame, false);
final JPanel panel = new TransparentPanel();
panel.setBorder(new LineBorder(Color.black, 5));
panel.setLayout(null); final JLabel label = new JLabel("Hello");
panel.add(label); label.setBounds(20, 20, 30, 10);

TimerTask task = new TimerTask() {
public void run() {
Rectangle bounds = label.getBounds(); label.setBounds(bounds.x+10, bounds.y + 10, 30, 10);
panel.repaint();
//Window window = SwingUtilities.getWindowAncestor(panel);
//window.repaint();
}
};

new Timer().schedule(task, 500, 500);

frame.getContentPane().add(panel);
frame.setSize(new Dimension(200, 200)); frame.setVisible(true);
}

anthony_p
Offline
Joined: 2006-07-24
Points: 0

Hi Jasper,

If you do the following:

[code]
panel.setOpaque(false);
panel.setDoublebuffered(false);
[/code]

just after creating your panel, the test case works fine on 6u18. Could you please confirm that?

PS. Please use the [ code ] and [ / code ] tags (w/o spaces) next time you post some code. Also please try making your test-cases complete and compilable (with proper import statements, a class, etc.) That can really simplify testing. Thanks in advance!

--
best regards,
Anthony

jasper72
Offline
Joined: 2007-12-25
Points: 0

It did fix but I dont understand why.

I made a mistake in the code I gave you in so far as I accidentally used one of my own classes TransparentPanel which subclasses JPanel. All this subclass does is call setOpaque(false) and setDoubleBuffered(false) in the constructor.

So I'm curious why it only works once construction is complete. It's also tedious because it means I can't encapsulate the behavior (and therefore it is a bug).

Thankyou anyway.

anthony_p
Offline
Joined: 2006-07-24
Points: 0

There's one more serious problem with your code. You're creating and showing your GUI on the main thread, while Swing is a single-threaded GUI toolkit and requires all calls to be made on the EDT. Please wrap the code that way:

[code]
SwingUtilities.invokeLater(new Runnable() {
public void run() {
// your code goes here...
}
}
[/code]
And see if that changes anything.

jasper72
Offline
Joined: 2007-12-25
Points: 0

I normally would have my code on a swing thread but skipped it for simplicity. But I added to the example and it doesn't make a difference.

anthony_p
Offline
Joined: 2006-07-24
Points: 0

So, could you please provide a complete code sample then? We'll see if there's a problem with the setOpaque/setDoublebuffered invoked in the constructor of the panel. Thanks.

jasper72
Offline
Joined: 2007-12-25
Points: 0

The following code does not repaint correctly. Important note: the TransparentPanel MUST be its own class. If it is an inner class this example works! I've tested same code doubleBuffering(false) content/root/glass panes but it makes no difference.

import javax.swing.*;
import javax.swing.border.LineBorder;
import java.awt.*;
import java.util.*;

public class TransparencyTest {

public TransparencyTest () {
JFrame frame = new JFrame();
frame.setUndecorated(true);
com.sun.awt.AWTUtilities.setWindowOpaque(frame, false);

final JPanel panel = new TransparentPanel();
panel.setBorder(new LineBorder(Color.black, 5));
panel.setLayout(null);

final JLabel label = new JLabel("Hello");
panel.add(label);
label.setBounds(20, 20, 30, 10);

TimerTask task = new TimerTask() {
public void run() {
Rectangle bounds = label.getBounds();
label.setBounds(bounds.x+10, bounds.y + 10, 30, 10);
}
};
new java.util.Timer().schedule(task, 500, 500);

frame.getContentPane().add(panel);
frame.setSize(new Dimension(200, 200));
frame.setVisible(true);
}

public static void main (String[] args) {

SwingUtilities.invokeLater(new Runnable() {
public void run() {
new TransparencyTest();
}
});

}

}

import java.awt.Color;

import javax.swing.*;

public class TransparentPanel extends JPanel {

public TransparentPanel() {
setDoubleBuffered(false);
setOpaque(false);
}
}

anthony_p
Offline
Joined: 2006-07-24
Points: 0

Hi Jasper,

Just installed vanilla jdk 1.6.0u18 on my Window Vista system and your code works just perfectly. I suspect the problems you're experiencing might still be related to the threading issues: notice, the java.util.Timer has no idea of the EDT, but the handler still invokes some Swing code and expects to get correct results. Try wrapping the body of the new TimerTask() {run()} with the EventQueue.invokeLater() as you do in the main() method.

Another guess, please note that calling setBounds() (as well as any method that affects layout-related information) requires subsequent validation of the component hierarchy: please place a call to label.revalidate(); just after calling the setBounds() in the timer handler.

And the third guess is as follows: that might theoretically be an issue with your video card drivers. Try running the code passing the -Dsun.java2d.noddraw=true command line option and see if it helps.

If nothing of the above eliminates the problem, then that must be some kind of mystique, I guess. %)

PS. The [ code ] tags must be in lower-case to be correctly parsed by the forum software.

--
best regards,
Anthony

jasper72
Offline
Joined: 2007-12-25
Points: 0

Thanks for testing; I've tried all your suggestions but they made no difference.

Given that all this works fine on pre-18 JRE's it would be surprising if the graphics card was impacting.

I think the key is the initialization period. Given that it works ok if I make the code an inner class suggests there is a race condition under the covers.

anthony_p
Offline
Joined: 2006-07-24
Points: 0

But the code is single-threaded so I don't see many conditions for a thread race. The only additional thread is the Timer. What if you start the timer *after* showing the frame only?

jasper72
Offline
Joined: 2007-12-25
Points: 0

well, I'll speculate the problem is on the native side given that the behaviors in this area are different per OS (eg it always behaved like this on mac). But I can't comment on what looks like a single thread in java code translates into native code.

I found the same problem in different ways while I constructed the example. Initially, I had all the code in the main method, with the TransparentPanel in an inner class; if the latter was a static class it worked ok, else it didnt.

anthony_p
Offline
Joined: 2006-07-24
Points: 0

Since Sun does not provide a jre/jdk for Mac, I can't say anything about their implementation of the transparency effects.

When you constructed the initial example, was all the code still invoked on the EDT? Did the timer always re-dispatch the setBounds() action to the EDT? If everything is re-dispatched to the EDT, then there's truly only one thread in the sample application, and there couldn't be a thread race.

Anyways, we can't reproduce the issue locally neither on Vista, nor on XP. Tested on 6u18 and 6u19. The label always moves w/o any traces or other visual artifacts on the transparent background - it stays clean.

Could you confirm if the problem exists on other PCs?

jasper72
Offline
Joined: 2007-12-25
Points: 0

i ran on win7;

i'll try and test on XP; the general class of problem i see on XP consistently but whether that specific code does it I don't know.

I tested on 19 last week and was same as 18

jasper72
Offline
Joined: 2007-12-25
Points: 0

I'm struggling with the same problem on windows. My code worked fine pre 6.18 but now my UIs get dirty and/or gradually darken. A few notes:

- I'm overriding paintComponent() not paint();
- My panels are opaque false and double buffered false
- Sometimes I end up with transparent rectangles (I can see my desktop) in translucent areas and partially across separate components within a borderlayout. image attached
- I always had this problem on mac (which is on 6.17 right now) and had to hardcode a brutal repaint solution in; but im reluctant to extend this any further.

I repeat - this problem is just 6.18: to my mind a bug has clearly been introduced in 18.

anthony_p
Offline
Joined: 2006-07-24
Points: 0

HI Jasper,

That might be related to the bug http://bugs.sun.com/view_bug.do?bug_id=6848852

Could you please try disabling double-buffering for the glass-pane, root-pane, and the content-pane manually just after switching your frame to the non-opaque mode?

--
best regards,
Anthony

jasper72
Offline
Joined: 2007-12-25
Points: 0

Anthony,

I gave your suggestion a go but it didn't have any observable effect.

Jasper

ixmal
Offline
Joined: 2004-08-08
Points: 0

> Performance is much better than in windows.

Try JDK 6u18 (when it's released) - it contains some fixes related to non-opaque windows performace on Windows platform.

Artem

anthony_p
Offline
Joined: 2006-07-24
Points: 0

Hi Antonio,

> Then, I overload the paint() method in the panel to
> paint what is needed.

Swing people say this is a bad practice. You'd better override the paintComponent() instead.

> -In Windows, with jre6u18b03, I must call
> super.paintComponent() instead of super.paint()
> inside the overidden paint() method; otherwise,
> background is not repainted (in each repaint it gets
> more opaque).

When you override the paintComponent(), and make sure the panel is non-opaque and non-double-buffered, that should work fine.

> -In Windows, with other than jre6u18b03, I must call
> panel.setDoubleBuffered(false) in same configuration
> to work (OK, this is expected).

Yes. You need to do that.

> -In Windows, if I call panel.setOpaque(false), the
> panel never gets mouse events, unless mouse cursor is
> over an opaque pixel.

That is expected. MS Windows does not notify us about clicks on transparent areas, hence we're unable to deliver them to the application.

> -In Linux, I must call panel.setOpaque(false);
> otherwise, I get the same "pregressevly more opaque"
> background. However, (as expected), inside the
> overridden paint() method I must call super.paint(g);

True. But still, please consider overridding the paintComponent instead.

> Performance is much better tha in windows.

True as well. Windows' support for translucent windows ain't fast at all.

> -In Mac, I cannot use AWTUtilities, but changing
> frame's background color to something with "alpha",
> it gets translucent. But, ... repainting is always
> wrong. The result from previous painting operation is
> not cleared before perform next paint. As a result, a
> mouse pointer moving becomes a mouse track.
> Enable or disabel opengl, all other tricks didn't
> help, until now.

I suggest to ask this on an Apple's Java forum since their implementation quite differs from Sun's one.

> The guidelines that state "remove decoration, set
> frame translucent, set double buffering false" seem
> to be variable,... or I'm completely confused.

If you follow all the recommendations at once (correct gc, non-opaque and non-double-buffered components, paintComponent overridden for painting), that should provide a consistent result in all supported configurations/platforms. If not, then that is probably a bug in Java.

--
best regards,
Anthony

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Hello!

This is still the best example of a forum.
Thank you, and congratulations!!

I tried initially to override paintComponent() instead of paint(), but I was getting worse repainting results. Override paint() seamt to be lead to more coherent results.
Should I, anyway, override update()? I tried to do that to clear the background but it did never work.
I Mac, I tried both Apple jre, openjdk and soylatte. With openjdk and soylatte I could even get the translucent frame.

Tyank you, again. I'll try again and post my results.

Best regards,
Antonio

anthony_p
Offline
Joined: 2006-07-24
Points: 0

I don't think you need to override paint(), nor update(). When you make your panel non-opaque, it does not repaint its background anymore. And all you need to do is to override the paintComponent() to paint exactly what you need to be painted. Also, remember to turn off double-buffering for the panel. Please try that again and tell us if something gets painted wrong.

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Hello, all

I was waiting for testing in all OS before reply, but I stalled in the beginning.

Changed the code in MCanvas (extends JPanel) to override paintComponent() again, and, inside it, I'm calling super.paintComponent();

In Windows, the code below works with jre1.6.0_18-ea-b03. However, with b04 or b05, I have the "progressively darker background in each repaint" problem.
If I change the background color in canvas to (0,0,0,0) instead of (0,0,0,1) or apply setOpaque(false), this does not occur, but I have the mouse events problem (as expected).

Can you please help me finding the error in code below? My mental health is vanishing...

Thank you.

Best regards,
Antonio

[CODE]
GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
try{
GraphicsDevice[] devices = env.getScreenDevices();
for (int i = 0; i < devices.length ;i++)
{
GraphicsConfiguration[] configs = devices[i].getConfigurations();
for (int j = 0; j < configs.length ;j++)
{
if (AWTUtilities.isTranslucencyCapable(configs[j]))
{
gc=configs[j];
break;
}
}
}
}catch(Exception e)
{e.printStackTrace();}

System.out.println("FOUND:"+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSPARENT));

frame=new JDialog((JDialog)null,"",false,gc);
frame.setUndecorated(true);
try{
AWTUtilities.setWindowOpaque(frame, false);
}catch(Exception e)
{e.printStackTrace();}
frame.setTitle("WINDOW");
frame.setName("WINDOW");
frame.setBackground(new Color(0,0,0,1)); //???
frame.setDefaultCloseOperation(Frame.DO_NOTHING_ON_CLOSE);
Dimension d=Toolkit.getDefaultToolkit().getScreenSize();
frame.setSize(d.width,d.height-20);
frame.setLayout(null);
frame.setVisible(true);

canvas =new MCanvas(); //extends JPanel and overrides paintComponent()
canvas.setDoubleBuffered(false);
canvas.setBackground(new Color(0,0,0,1));
//canvas.setOpaque(false);
frame.add(canvas);
canvas.setBounds(frame.getBounds());

[/CODE]

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Something was wrong with my tags...

[code]
GraphicsEnvironment env = GraphicsEnvironment.getLocalGraphicsEnvironment();
try{
GraphicsDevice[] devices = env.getScreenDevices();
for (int i = 0; i < devices.length ;i++)
{
GraphicsConfiguration[] configs = devices[i].getConfigurations();
for (int j = 0; j < configs.length ;j++)
{
if (AWTUtilities.isTranslucencyCapable(configs[j]))
{
gc=configs[j];
break;
}
}
}
}catch(Exception e)
{e.printStackTrace();}

System.out.println("FOUND:"+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSLUCENT)+","+AWTUtilities.isTranslucencySupported(AWTUtilities.Translucency.PERPIXEL_TRANSPARENT));

frame=new JDialog((JDialog)null,"",false,gc);
frame.setUndecorated(true);
try{
AWTUtilities.setWindowOpaque(frame, false);
}catch(Exception e)
{e.printStackTrace();}
frame.setTitle("WINDOW");
frame.setName("WINDOW");
frame.setBackground(new Color(0,0,0,1)); //???
frame.setDefaultCloseOperation(Frame.DO_NOTHING_ON_CLOSE);
Dimension d=Toolkit.getDefaultToolkit().getScreenSize();
frame.setSize(d.width,d.height-20);
frame.setLayout(null);
frame.setVisible(true);

canvas =new MCanvas(); //extends JPanel and overrides paintComponent()
canvas.setDoubleBuffered(false);
canvas.setBackground(new Color(0,0,0,1));
//canvas.setOpaque(false);
frame.add(canvas);
canvas.setBounds(frame.getBounds());
[code]

ajmmm
Offline
Joined: 2008-07-04
Points: 0

Well...

I think I'll give up today.