Michael Emmel wrote:
> > It seems to me that the Swing architects came to
> > a conclusion about how to write thread-safe programs: ...
> > they expect you to segment your program so that only
> > one thread manages the user interface, and communicates
> > with the rest of your program through a carefully
> > designed thread-safe interface (e.g. a queue or two). ...
> > A page that goes into more detail on this is
> > http://www.javaworld.com/javaworld/jw-10-1998/jw-10-assure.html
> Well that illustrates my point. A developer should not have to do that.
> The Swing team should provide the queue interface it should not have to be
> cobbled together by every developer that wants to write a complex graphics
> program.
> I never had any problems with Display Postscript under Nextstep. The
> interface was very easy to use and multi threaded drawing was much
> easier to implement.
> Just fill a message buffer and send it. The locking is at the message level.
I think Display Postscript is analogous to AWT's Graphics, not to Swing.
Even if Swing was based on Display Postscript rather than awt's
Graphics,
the comments about thread safety would still apply; you really want
just one thread manipulating the Swing widgets. I don't think there's
an easy way around it, unless you want all Swing calls to be queued and
nonblocking, and to return results to you via a queue, which wouldn't
be very intuitive for most programmers.
> Plus translation and current paint mode should be exposed
> and thus reversible. A simple reset to default for graphics
> contexts would be quit useful. ...
> The SwingGraphics state does not match the underlying native graphics state
> so I finally gave up and decided to spend my time doing something
> more useful like bitching about Java's drawing model. ...
> Also the decision to not make SwingGraphics public should be reviewed.
> Drawing should not be this hard IMHO. ...
> For me I dont trigger a bug until sevberal object try to share a Native
> context.
> public void paint( Graphics g ) {
> super.paint(g);
> g.setPaintMode(); // makes the context un reusable.
> g.dispose();
> }
> This code should have no effect at all except to cause the graphics to really
> dispose; Now maybe I don't know what I'm doing but it seems to blow the
> Swing up when it gets several objects sharing a Native graphics context.
This is interesting, but out of the scope of java-linux. I am reposting
this
to Usenet's comp.lang.java.gui. Please redirect all discussion on this
thread there.
- Dan
