3D X

[Carsten Haitzler (The Rasterman)]

On Sun, 02 Apr 2006 12:16:38 +1000 Russell Shaw <rjshaw at netspace.net.au>
babbled:

> Carsten Haitzler (The Rasterman) wrote:
> > On Sat, 01 Apr 2006 16:28:35 +1100 Russell Shaw <rjshaw at netspace.net.au>
> > babbled:
> > 
> >>Hi,
> >>To get everything to tilt at an angle, you just add an X protocol to
> >>set a server transform to give whatever zoom or rotation to be applied
> >>to everything on the X screen. Also, XCreateWindow would take a "z"
> >>dimension for its distance "above" its parent. The total work to do that
> >>in the X server would be pretty straight forward.
> >>
> >>To get 3D alpha compositing, the server just maintains an in-memory
> >>(double-buffer) of the screen (the superposition of all individual windows),
> >>and an off-screen copy of each individual window.
> >>
> >>Erasing a window is just a matter of linear scaling and subtraction of the
> >>pixel values of the window from the screen (composite of all windows).
> >>
> >>What's all this stuff about "compositing managers" ?
> >>
> >>I don't get why 3D composited X windows are "hard" or complex to do.
> > 
> > summary... your fingers are still way too green mate. :) trust me - from
> > those that have been  around these traps for a while. the composite method
> > is the right way to go. its a great design in principle. it has rough edges
> > - missing bits, hooks, pipeline elements (being fixed - i bitch about them
> > all the time), but until you really understand how it all works - from the
> > hardware to x's internals to client-side programming at the low levels
> > (that means xlib levels)... you won't appreciate that.
> > 
> > just have some faith in the fact that it is being done right.
> 
> Hi,
> There's little documentation on what a compositing manager *does*.

i haven't had to read a single document - checking some headers and putting
together with the rest of x - the bulb just goes "aha" - in teh broad sense.
sure - there are niggly details - but the broad concept is simple. composite
redirect rendering of a window TO a backing pixmap that is accessible like
normal pixmaps. now the pixel contents exist somewhere independent of their
window on screen. the rest is just re-cycling basic knowledge of the rest of x.

> I'll find out more about X internals when i've done porting a subset
> of it to another cpu (still to do). I don't need any of the 3D stuff
> just for a GUI, and would rather have a fast simple and small 2D GUI
> that runs on well on old hardware than a 3D one that is slow is
> molasses on a 10GHz pc. There's something fundamentally wrong when
> Win95/98 still beats X in every way (in part due to just the M$ widget
> system).

most of the problems of x are not to do with design - in fact x scales better
design-wise than just about any competing systems - because hardware is looking
more and more like x - an sync request pipeline. it degenerates well if you
don't do round-trip requests all the time (pure stupidity in an async system
like x). the biggest problems with x are

1. driver support. frankly most of this is because specs are not made public or
not full specs, or closed drivers are just crap, or limited.
2. just missing optimisation paths because people dont have the time to work on
it all. unlike win9598 - no one is being PAID to work on it. u don't have people
fulltime devoting themselves to launching x off into hyperspace in the numbers
you have for the linux kernel for example. frankly fulltime paid coders MATTER
- they have the time and ability to focus enough on problems to get the hard
ones fixed.
3. you need to dig deeper (as you admitted) into how it all works.

> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)