Michael Emmel wrote:
Well I figured it out. Swing was handing out the same native graphics context
twice.
It look like theres a race condition in Swing Graphics wich allows it
to hand out the same native graphics context twice in a threaded enviroment
The pain is it results in deadlocks when two threads are using the same
graphics context and
one calls dispose.
>From looking at SwingGraphics I'd say the bug is in there init method and
dispose.
One they should call creat and two they should lock acess between dispose and
init.
I think even more needs to be done but I personally dont like the whole shared
graphics design.
This whole method is not thread safe.
void init(Graphics g) {
if (g instanceof SwingGraphics) {
/* Clone an existing SwingGraphics object. The dispose method
* must be called to reset the shared sub-graphics object to
* the same state it was in when cloned. */
SwingGraphics sg = (SwingGraphics)g;
originalGraphics = sg.originalGraphics;
graphics = sg.graphics; // MIKE this should at least be
graphics=sg.graphics.create()
previous = sg;
If you some how let a two threads access a SwingGraphics object they share a
refrence to the
underlying native thread object. Which results in some intresting graphics or
in the case of dispose
deadlock..
The real bummer was if I turned on the debugger it never happens : (
Also something else I noticed I dont think clear rect works correctly for
lightweight components
Since it clears the rectangle and fills it with the background of the Native
component.
Thus if the lightweight component has a different background color from its
parent then trouble.
import java.awt.*;
import javax.swing.*;
public class JPanelTest extends JPanel
JPanelTest( String name ) {
super();
}
public static void main( String[] args ) {
try {
JFrame ff = new JFrame(" HELLO WORLD 2");
ff.setBounds(0,0,300,300);
ff.setResizable(true);
JPanelTest dis2 = new JPanelTest("Panel2");
// NOTE RED BACKGROUND
dis2.setBackground(Color.red);
ff.getContentPane().add(dis2);
ff.setVisible(true);
} catch ( Exception e) {
System.out.println(" ERROR:"+ e);
e.printStackTrace();
}
}
public void paint(Graphics g) {
super.paint(g);
// Should clear to red
g.clearRect(0,0,getWidth(),getHeight());
}
> Hi I'm dead locking in Graphics on a call to setFont
>
> It enters g.setFont and never ruturns theu funny thing is it succeeds
> many times and this is
> the only thread in the setFont call ?? I synchronized on the graphics
> but no luck.
>
> java version "1.1.7B"
>
> Good call
>
> 0 SET FONT CALLED
> java.awt.Font[family=Dialog,name=Dialog,style=bold,size=12]
> g=SwingGraphics(0x80ce783) [subGraphics sun.awt.motif.X11Graphics
> translate [x=0,y=0] clip [x=0,y=0,w=498,h=30]
> color [r=128,g=128,b=128] font
> [family=Dialog,name=Dialog,style=plain,size=12]]
> ENDk FONT CALLED
>
> bad CALL
> 0 SET FONT CALLED
> java.awt.Font[family=Dialog,name=Dialog,style=plain,size=12]
> g=SwingGraphics(0x80cd79e) [subGraphics sun.awt.motif.X11Graphics
> translate [x=0,y=0] clip [x=0,y=0,w=498,h=30]
> color [r=0,g=0,b=0] font
> [family=Dialog,name=Dialog,style=plain,size=12]]
>
> Nothing ???
>
> SwingGraphics just sets the Font and a instance var I looked.
>
> Mike
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
