Dave Postill wrote:
> On 7 Oct 1998 16:40:34 GMT, [EMAIL PROTECTED] (Mohd) wrote:
> | I have a swing application which needs to start two threads. The threads use
> | Runnable classes. When I start the threads from inside my Swing application,
> | The application hangs completely. I know the problem is not with threads as
> | they work fine from an AWT based application. Anybody knows whats goin on?
> |
> | Can I have a multi-threaded application with Swing? If yes how do I go about
> | it?
>
> <http://java.sun.com/products/jfc/tsc/swingdoc-archive/threads.html>
> <http://java.sun.com/products/jfc/tsc/swingdoc-archive/swing_worker.html>
A similar question was asked on java-linux yesterday. I'm redirecting
that
discussion here:
Michael Emmel wrote:
> Dan Kegel 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 in general, not just for
Swing, 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.
I don't know enough about Java graphics to deal with this question, but
it sounds like you have discovered that Java only has one native
graphics
context that all AWT Graphics objects share, and that you are unhappy
with
this. Can anyone knowledgable comment on this?
- Dan
