Using OpenGL as a window manager

[Martijn Sipkema]

> > The X server should do no more than to allow multiple clients to
> > use the graphics hardware simultaneously. Higher level abstraction
> > can be done on the client side.
> 
> This is an interesting point of view and I would like to hear
> the opinion of the other readers of this list. Thanks for point-
> ing it out, anyway. I worried that my post could be considered
> off-topic and I'm glad to see that it was not.

I'm afraid I'm not exactly an authority on what is off-topic on this
list :)

> X is much more than a fast method for letting multiple clients
> access the framebuffer and we should all leverage its strength.
> Nothing prevents clients from just reverting to X for mouse and
> pointer handling and using PutImage to draw on the screen. This
> would be like sending a PNG of a web page. It would give users
> an exact match of what the author intended, but it would not be
> the web anymore.

I'm not saying clients should use PutImage for rendering. In fact
I think clients should use only OpenGL/GLX for rendering. I also
think that transparent windows is a hard thing to do right (and
maybe not even that useful), let alone transformed windows
(which really aren't useful at all).

For example, the way transparent windows are implemented
now is entirely server side, i.e. the client doesn't really know about
it (except that it renders with an alpha dst). One could also
implement it by having the client request the underlying window(s)
to be rendered into its own (using an OpenGL extension). That may
be more flexible than the former approach, though it also has
worse performance due to more context switches.

> Higher level abstraction -can- be done on the client side, but
> the question is "why". Adding such a layer of abstraction for
> the sake of redoing things that would be better done into the X
> server is a bad idea. IMHO the best way to overcome X protocol
> limitations is improving the X protocol.

Putting a higher level of abstraction on the client side could be
done using a library or by using a user interface server using
the X server for output.

> If you think that a completely different X server can be designed
> to better handle the different needs of future graphics, I can
> agree with you (even if I don't see why it couldn't be done in
> the existing framework), but we must avoid the error of looking
> at the X protocol from two incompatible positions. I see X as a
> network protocol and an efficient way of enabling distributed
> computing. I'm sure that's not your case, but many see X as a
> legacy inheritance and would like to see it reduced to a compa-
> tibility layer.

I'm not saying X should be changed completely, allthough a
modernized and small OpenGL based X12 does sound nice :)

--ms