Nathan Meyers wrote:
>
> Jonathan Mark Brooks wrote:
> >
> > I suspect that they didn't get the point. What people are asking for is
> > that the graphical elements of java be implemented with GTK+ rather than
> > Motif or some other platform specific GUI kit (GTK exists for win32 now as
> > well...). Even Swing must at some level call on GUI elements that are
> > coded not with Java but with a lower-level graphics library.
>
> What is it exactly that people are asking for?
>
> Yet another implementation of the AWT (YAAWT) or a good GUI?
>
> It should certainly be possible to do YAAWT with
> <name-your-favorite-toolkit>. It will look different from all the other
> YAAWTs, and add yet another layer of complexity to the already difficult
> problem of writing Java apps that look good on all platforms.
>
> Swing is a good GUI -- in fact, an excellent GUI -- with a good set of
> widgets and a collection of L&Fs that look good everywhere.
> Unfortunately, it suffers from some serious performance problems for a
> couple of reasons:
>
> 1) Everything is implemented in Java.
But thats not quite right. As you as below, swing still needs to use
some bits on the AWT which in turn HAVE native peers. The only
difference with swing is that it only uses a minimal number of native
peers - the top-level windows are still using native peers.
> 2) "Lightweight" components are anything but lightweight. They move a
> significant amount of activity from the X server to the client, where it
> is handled much less efficiently and with much higher network bandwidth
> costs between client and X server. (This is not a new issue; Motif dealt
> with it years ago in the widgets vs gadgets debate.)
I'm afraid I haven't heard of this - what was the question and did the
debate produce any interesting answers ?
> Several things *could* happen to improve the Swing performance story:
>
> 1) Portions of Swing could be implemented natively.
True.
> 2) Swing could increase its reliance on native windows rather than
> owning everything below the top-level window.
Probably a bad idea. Afterall swing is supposed to provide xplatform
gui, if you start using more native stuff you just come right back to
the AWT way, since I can't think of anything useful the native windowing
system can provide apart from peers to make things faster, though I
suppose having another interface to the native windowing system to
provide faster basic drawing routines might help??
> 3) The relentless upward march of clockspeeds could make Swing
> performance acceptable, as finally happened to MSWindows a few years ago
> :-).
To my mind (and I don't claim to be a graphics expert by any stretch of
the imagination) what makes swing so slow is that it tries to be too
much at once. Ok dynamically changeable l&f's are good, ok having a huge
comprehenive api is good, etc... but what would be better would have
been a rock solid _smaller/simpler_ api that people could build on to
make more sophisticated gui interfaces. The fact that this represents
Suns approach to Java, ie. throw in everything including the kitchen
sink and to hell with stability/performance makes perfect sense of the
way swing has turned out.
Also I'm not convinced that there is anything that makes pure-java gui
implmentations intrinsically slow so having pure java gui like swing is
IMHO a good idea - it's just that it needs to be implemented properly.
Maksim.
>
> Nathan Meyers
> [EMAIL PROTECTED]
>
> ----------------------------------------------------------------------
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Remember Darwin; building a better mousetrap merely results in smarter
mice.
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
