Messages in this thread | | | From | Rik Hemsley <> | Subject | More GGI opining | Date | Thu, 26 Mar 1998 16:04:14 +0000 |
| |
--------------- GGI related diatribe follows ---------------
Right I'll try to be as concise as possible. This is already taking too much of the bandwith through vger. Truthfully, though, this is where this thread needs to be 'til the bitter end.
I'll attempt to avoid declarations of truth, instead hopefully giving some fuel for thought to those who write one-line sweeping statements. I'm not a kernel developer, and those who aren't shouldn't tell the developers what's right for Linux. ( a sweeping statement :)
What people really want: (?) After reading Jari's guesses at what he believes is necessary in a graphics, and more specifically a GUI system, I have to add to the disagreement. I spent a long time researching and writing a system similar to what GGI is trying to achieve, though it was fully user space. I gave up to work on other projects when I couldn't rouse enough interest.
Goals for graphics device abstraction layers:
1. Abstract away from the hardware at the raw level with a set of common functions. Provide 'wrappers' to the basic primitive functions of the hardware device. This is what svgalib does to begin with.
2. Provide accelerator functions with a common interface such that if the accelerator does not exist for the hardware device, it is implemented in an efficient algorithm and automatically used. This is what svgalib never got round to I believe (correct me)
3. Write device drivers for each piece of hardware.
4. Provide a means of creating widgets and giving them a message passing, or callback mechanism (toolkits). The Qt toolkit has tried a different approach to that of Motif etc by extending C++ to use a signals and slots system.
5. Write your user interface on top of layer the toolkit, your games on top of the raw accelerator functions, possibly inside the toolkit's objects.
X adds networking to this, which would also have to be a consideration for any other system. I still run xterms off Linux boxen, and we're not swapping all of them for NCs yet.
I spend some time doing graphics work, and I've yet to see what sort of gains will be made with the GGI system regarding:
a) Speed.
X11 is huge, granted, but it's not as slow as the GGI advocates are trying to points out. I used it quite happily on a 486 until a month ago, and that includes 3d modelling and rendering. If GGI had 3D-enabled drivers for all the non-voodoo cards around, that would be something, but seriously, is that happening ? Do I buy that voodoo now to use the 3D on the card for Mesa, or do I hang about for someone to write a driver for my Mystique 220 ?
b) Flexibility
The complaint that X is monolothic has ignored the power of X, as the equivalent of the 'top end' of Linux, i.e. the userland part of the kernel, if you pardon my analogy. Serving up fonts over a network is a good example of somewhere X shows its intelligent, if a little overworked, design.
c) Stability
X seems to have a habit of freezing some people's systems with particular hardware configurations. How will GGI improve upon this ? The stability of X is dependent on its drivers. The XFree86 distribution is stable in itself, but it relies on drivers written by those with the time or the need. GGI must be moving along the same lines. Surely the core developers aren't going to sit down with a room full of specs and hack away ? And if X can freeze the system, surely GGI in the kernel will do exactly the same with a broken driver ? I do not know the details of GGI's architecture yet, but I can't imagine how it will skirt that problem.
d) Compatibility
Surely the greatest consideration to make when designing any system is whether it will be either compatible with the system it replaces or simply have enough backing to make that irrelevant, a competitor. If X11 will run in GGI, that's great, but what's the point ? To run X applications without X, inside the GGI system, would mean what amounts to re-implementing X. Obviously this is not the plan. Is a new toolkit being written ? What happens to GTK and QT/KDE ?
At this point I give up. I'd like to mention that I'm not against the GGI project at all. If it works, I'll applaud the developers for doing something that has always been an ideal.
Cheers, Rik
-- Rik Hemsley Unix Admin (Linux, AIX, HP, DG, SCO, Interactive) Keyline Builders Merchants, Glasgow, UK
------------------- End GGI mouthing ---------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |