Re: Is the Linux Graphics Stack Backwards?

"stork" <stork@xxxxxxxxxxxx> wrote:
>GDI32.DLL only does drawing and it thunks down to a graphics driver
>that is, in the simplest case, a one to one mapping of GDI32 calls.
>USER32.DLL handles all the input and also also the windowing. So
>windowing and input is completely abstracted from drawing.

X is not terribly dissimilar. Applications call the X library. The X
library converts that to protocol, which gets sent to an X server, and
unwrapped into function calls. In XFree86/XOrg, those function calls
eventually call well-defined entry points in a graphics-card-specific

X includes only the bare minimum of windowing. Most of the windowing
functionality is actually implemented by window managers, which are
separate and replaceable.

>I want to go through the mental excercize of making my own desktop
>layer that is not X on Linux. In other words, it would be -fun- to take
>the raw mouse input streams, keyboard input streams, and, if all I had
>was a simple drawing layer at level 0, go and implement a windowing
>engine on top. Well, not necessarily a windowing engine, basically,
>just get rid of the whole concept of "windows" altogether and do
>something different.

There are dozens of graphics systems for Linux besides X, some of which are
small enough to play with and quite entertaining. I might suggest you take
a look at Microwindows.

>>Also, remember that the Xorg developer team is
>>constantly coding new stuff to make X faster and/or make it support more
>>video cards, so unless you can attract a bunch of skilled developers to
>>your project, you'll fall behind them right quick. HTH!
>That to me says that they are just bundling the drawing code with all
>the other stuff. It's unfortunate that the drawing and calling the
>graphics card stuff is not modularized in the project.

I don't think that's quite fair, especially in XFree86/XOrg. Most of the
layers of the server are entirely hardware independent -- very generic
drawing code, very similar to GDI. At the lowest level, that generic code
calls into an installable graphics driver module, which is specific to the
current graphics chip. The entry points to these driver modules are
vaguely similar the original protocol, similar to the way that the GDI
driver interface is vaguely similar to the application interface to GDI.
- Tim Roberts, timr@xxxxxxxxx
Providenza & Boekelheide, Inc.

Relevant Pages

  • Re: Obsoleteness of X concept
    ... different video cards video memory and it's called "kernel video ... driver to draw current X screen layout ... different capabilities in the drawing primitives. ...
  • Re: /boot/loader graphics support & extensibility
    ... and drawing filled rectangles (e.g. to clear the screen ... and different graphics hardware supports ... The Forth code calls the rectangle function. ... what will be the bitmap format of the temporary ...
  • Re: Looking for some help.
    ... machine, 30 seconds, freeze. ... Unfortunately, doing a graphics test that uses hardware acceleration, ... Nvidia and ATI have binary driver packages ... I don't see a reason to buy any more disk drives. ...
  • Re: How do I turn off write combining programatically?
    ... I should not bother with GDI+ and try the DirectX drawing stuff. ... I just do something like this in paint event ... ... Any exception thrown while drawing with a Graphics will tend to ... >> screensaver, and my posted sample in sheer disgust and destroy all source ...
  • RE: Direct memory access controller driver problem ?
    ... no driver is installed, but on the other hand says it is working normally!! ... DMA controller is turned off. ... 8Mb to run the graphics, yet everything I can see points to the graphics card ... install the chipset installation utility,then the graphics driver,if the ...