Dan Kegel wrote:
> Michael Emmel wrote:
> > Hello I've been working for a while on and all java Windowing system.
> > My current version is written on top of the Swing toolkit. Which is
> > practically all Java.
> > Well it turns out even Swing is flawed.
> >
> > The problem with Swing is the attempt to reuse Graphics context and not
> > being thread safe. ...
>
> Could we pause for a moment here, and have you explain
> the problem in greater detail? In particular, what is
> the problem with not being thread-safe?
>
> It seems to me that the Swing architects came to
> a conclusion about how to write thread-safe programs:
> thread safety is difficult. The best way to achieve
> it is to carefully segment programs such that the
> interfaces between threads are particularly well understood.
> For instance, rather than allowing lots of threads to call the
> many methods of a Graphics or other complex object,
> and attempt to have all these methods lock all
> the resources they reference in a way that avoids deadlock,
> only allow simple objects like queues to be used by
> multiple threads. That's why Swing is not thread-safe:
> 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).
>
> I happen to have helped fix a bunch of deadlocks in
> a complicated Java user interface by doing just that,
> so I trust their judgement.
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.
Pretty trivial.
Real time drawing can be done by allowing direct access for a screen portion
and requiring
that a window painting in this mode is alway it the highest layer so it
cannot be coverd up.
The Windowing system simply enforces clipping. You could also "lock" its
position or throw away the feed while moving.
Javasofts callback model is non-intutive and easy to screw up. Your right
that a drawing queue
should be used but it should be provided by Javasoft. Plus translation and
current paint mode should be exposed and thus reversible. A simple reset to
default for graphics contexts would be quit useful.
As far as the graphics reuse I found a bug with Swing when it has a lot of
graphics context's it seems
it does not correct for translation correctly but since they play games with
clip rects and translations.
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.
Although I think trigger a bug there stuff is so screwed up I can't decide
who has the bug.
Also the decision to not make SwingGraphics public should be reviewed.
Drawing should not be this hard IMHO.
give this a try in a Swing subclass with a few widgets on it.
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. Like I said I looked and gave up
trying to figure it out.
The games they play becuase of underlying design problems are difficult to
trace.
What really irritated me not the bug but even with the code in front of me
It's so
hacked I can't trace it.
>
>
> You go on to write:
> > The NT thread model is flawed it allows race conditions.
>
> I thought NT implemented threads fairly well-
> and that's why Java code that runs on other Java ports
> sometimes has race conditions on NT Java, because
> those other platforms don't do preemptive multithreading,
> and therefore hide race conditions.
>
> This is an interesting discussion, but it probably
> deserves to be split up into a few pieces- the
> Swing discussion should probably move to comp.language.java.gui.
Okay I'll drop it but I find NT will switch from thread A to B before
A enters a lock. Thus B runs and deadlock is avoided.
I guess I should say thread starvation also
which I lumped into race condition. Anyway from experience I find that code
which runs
on NT locks up tight under Unix I've never experienced the reverse. And on
investigation there is a bug in the code.
But this disccusion should not be here it happens with Green threads to.
I just figured if I was complaining I might as well say it all : )
