[Crust-discuss] Goals?

[Tobias Hunger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> What are the technicals goals of the Crust project?

> To create a windowing system that is not as "bloated" as X.

Why not going for a windowing system that's technically superior?

> X has too many levels between the user and the hardware, which
> creates alot of overhead.  Look at the Gnome program-to-hardware
> interface:
>
>   1.Device Drivers -- Handle keyboard and mouse input. 
>   2.X server -- Handles graphical screen output and obfuscates keyboard and 
>      mouse,

Obfuscates?

>   3.Xlib -- A horrendously complex library for basic windowed graphics, 
>   4.Gimp Drawing Kit -- Quarantines the atrocious Xlib within a wrapper
>      library. 
>  5.Gimp ToolKit -- Provides a set of widgets, or user interface elements, 
>      like text boxes, buttons, scrollbars, etc. 
>   6.Gnome -- Provides internationalization, audio support, the Gnome panel, 
>      standard keybindings, standard icons, etc. 
>
> I will try to decrease this the number of levels to atleast three and a
> half.
>
>   1. Device drivers -- Handles graphic acceleration and framebuffer

What handles the mouse, keyboard, graphictablets, etc.? Is there a abstraction 
of the input-devices or is each client left alone with them?

>    2.0. Surface server -- Handles onscreen surfaces
>    2.1. Surface client library -- Provides drawing primitives, working on 
>          surfaces.

Isen't this somewhat like gdk?

>   3. Client library (for example GNUstep).
Or:
3. Client Library (for example gtk)
4. Gnome

So you got 5 layers (if you do not use tricks like 2.0, 2.1) instead of 6 with 
X. You sacrifice the one layer giving network transparency. Yes, that gives 
you a speedup, I'm rather sure of that. I doubt it is too much. And I 
consider network transparency a key feature of a windowing system! IMHO you 
are throwing out the one thing X did right and stick with all the problems of 
X.

> Another goal is to make it as fast as possible; Instead of making a RPC to
> the server for every graphic primitive, almost everything is handled in the
> client library.  When the client library is done with the update of the
> surface,

You know that DISPLAY=:0.0 is a shortcut through all the RPC too? It does not 
get rid of it completly of course, but it gets around some of the 
network-layer.

Anyway: Letting the client-library handle the look and feel of applications is 
repeating the toolkit-mess we all know and love from X.

> it notifies the surface server about it and it will move (bitblit) the
> surface into the framebuffer.

This is the next issue I have with CRUST: it is heading for the same low level 
of graphic primitives that X is using: Pixels. You can only accelerate 
pixel-drwawing so much. MacOS X is heading for OpenGL as its rendering 
backend, Windows for DirectX 8 (or 9?), why do you stick to blitting pixels?

Other issues I have are: Device dependent (can't print arbitrary graphics on 
screen), language dependent (you code is in C(++?), so clients need to be 
too), the old reinvent-the-wheel-syndrom (you write your own HW-access stuff 
instead of using existing libs), non-portable (you seem to rely on MIG from 
the HURD). I don't want to mention that Fresco (http://www.fresco.org/) does 
not have any of these issues;-)

I know that I'm telling anything new, Johan, but Wolfgang brought up this 
topic and I happened to go through your mailing-list archive once more.

- -- 
Gruss,
Tobias

- ------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
address@hidden                      So I installed Linux.
- ------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9DzbAv0FZW3NyoqURAqvVAKC3Rp2SXgRQDbuE7UqHqXNzPHuMxgCfafOq
4q3fZ89Ocut63RCc4pbAgxI=
=A5Mg
-----END PGP SIGNATURE-----