RE: AWT Comments

Date view Thread view Subject view Author view

From: peter@transvirtual.com
Date: Wed Jan 06 1999 - 06:04:51 EST


On Tue, 05 Jan 1999, Parmelan, Edouard wrote:
>- In Component.reshap() a COMPENENT_MOVED event is send if
> !sized && !moved. If I enclose it in the if (sized || moved)
> block, some NativeGraphic are not sync because there are
> not relative to parent Frame native window but relative to
> DefaultRoot() :(

There's a important difference compared to JDK: we only have lightweight
widgets. That means we don't have nested native Components, where exposes are
generated by the windowing system (for all levels of native windows). You most
often encounter this dfference with app - Containers (holding "native-like"
childs), re-implementing paint() without calling super.paint(). Since the spec
doesn't ask for native widgets, you can always consider this being a bug, but
we try harder.

The current AWT doesn't rely on COMPONENT_xx events for updating Graphics
objects for "native-like" Components anymore. I now let these Graphices listen
on ComponentEvents for all parents (except the toplevel), which is closer to
the real nature of the problem. And it doesn't force us to emit these events
artificially.

>- Eugene O'Neil write "X Tool Collection" (www.cs.umb.edu/~eugene/XTC).
> XTC is an object oriented, multi-threaded implementation of
> the X Window protocol, written in pure Java.

I know about this and consider it being a interesting alternative. In fact, I
thought about this by myself a year ago. Two reasons for why I didn't
settle on this:

(1) portability - the native interface is the same for all AWT implementations,
and it easily maps to various existing windowing systems / graphics libraries.
I'm still surprised that nobody already came up with a port to, say, Win32. Not
too hard to do.. Directly using the Xproto would shut this off. Not too bad if
you mainly think of Linux/xBSD? What about GGI (and the like)?

(2) External libs - we don't want to re-invent the wheel if it is already
working for us. Consider the effort it takes to implement native Jpeg / PNG
image production completely in Java. Ok, you can do this (as I have done it
once for the simple GIF), but that's not a simple task (look at the size of the
involved libs!).

Besides this, we would have to make sure to have the utmost IO speed available
before doing direct Xproto utilization. And we would have to improve JITed code
(look at the scaled image handling - this is not yet comparable to C if done in
Java).

I hope you don't think of me as just speaking "pro-domo" if I say we should
first concentrate on what we have. Keep in mind there's a new update ahead which
now runs the complete SwingSet (including GIF movies), Jacob and most other
apps playing it at least somehow to the rules (no, I don't support resizing in
paints!). And it even got faster (because of optional XShm and extended
Container/Component state propagation, getting rid of all these
parent-chain iterations for simple things like isVisible()).

-- Peter


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:30 EDT