From: Godmar Back (gback@cs.utah.edu)
Date: Wed Jan 06 1999 - 20:21:26 EST
>
> On Thu, 07 Jan 1999, Godmar Back wrote:
> >So, would it be fair to summarize your statement that the toolkit
> >approach is a good one for an awt that a) requires synchronization and
> >b) must map many of its structure to native data structure of the
> >underlying system?
>
> Correct.
>
> >An Xproto approach, on the other hand, would
> >neither require a) nor b) and would hence benefit from a more streamlined
> >interface? Such an interface would probably also require rewriting some
> >of the methods that invoke toolkit methods.
>
> It needs sync, too (would do that at least via the output streams), since X
> needs it. And I don't see that we could get rid of all natives (images etc.).
> We probably would eat up any speed benefit we get for simple things like
> drawLine in other places (images). In order to get more speed (if any), it
> would require a lot of changes.
>
You seem to be looking at it only from the speed angle, and that
may be okay. The reason I liked the idea was to make us independent
from having to have an Xlib implementation linked with the kaffe
executable, when kaffe's awt in fact only uses a fraction of it;
and also to solve the hairy problems with integrating it into the
threading system.
As an example, take the OSKit: even though it does have an xclient
library (which we haven't tested with kaffe's awt), I think a solution that
wouldn't require one may produce a kernel that's a lot smaller.
My thinking about making png/gif/jpeg independent was similar: basically,
being able to include any of those libs without having to include Xlib.
I still don't quite follow the XImage argument, but I need to look at the
code more closely to see what you're saying.
Then again, depending on Xlib may not be too much of a burden and it's
available on most platforms anyway.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:30 EDT