Re: AWT Comments

Date view Thread view Subject view Author view

From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 06 1999 - 13:23:31 EST


>
> >- 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,

 I downloaded XTC and played with it; and Kaffe popped the Flower demo
and the Button demo up without a hitch, so I was impressed. Unfortunately,
some of the other tests caused Dr. Watson to terminate exceed/W, but hey
that's what I get for using NT.

Nevertheless, I think XTC is a really cool thing. Let me reply to your
points:

ad (2): External libs (I assume you mean libpng, libjpeg, libgif, etc.) do
not depend on X, or do they? In fact, the way it's now is probably wrong;
these should go in libraries/awt/png, libraries/awt/jpeg, libraries/awt/gif.

I looked at imgpng.c some and I don't immediately see why it was necessary
to mix them with X dependent stuff. Is there a fundamental reason why
that's so or is it just a result of quick hacking?

So, using XTC or the like would still allow these performance-critical
routine to be native. Nobody would want to implement image scaling in
jitted Java (also it may be possible using gcj, but why reinvent the wheel).
In fact, factoring out the X dependent parts will allow for easier ports
to Win32, etc. and might even simplify the custom edition.

ad (1): I don't see where portability would come in. The way I would
envision it, there would simply be an alternative Toolkit singleton where
all the methods that are now natively implemented in wnd.c or evt.c would
be implemented in Java based on XTC. You either use the Xlib based one,
or you use the XTC based one.

Also, XTC's license is very nice: it's public domain with no restrictions
whatsoever.

        - Godmar


Date view Thread view Subject view Author view

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