On Sun, Nov 16, 2008 at 10:05:16AM +1100, Carsten Haitzler wrote:
> x's internals are definitely up for improvement - callium3d is  there to try
> and fix this by providing a better more organised and better accelerated 
> driver
> layer - but again - they aren't going to replace x... just clean up internals.
> what it means is - the rest of us can continue happily writing x apps and just
> "wait" for an improvement to pop out the pipeline. indeed x's internal
> acceleration layer could be improved. it has in the past (especially with xaa)
> proved an impediment if you have to code AT the driver layer. as such - x was
> originally designs (as a system - not specifically the xorg tree etc.) to 
> allow
> full freedom to implement the internals of x any way you like - so as such if
> you wanted to spend the effort x could accelerate just about everything as 
> long
> as hardware can do it, somehow - but the points at which that acceleration
> knowledge need to go into might be much higher up than xaa/exa. you'd have to
> write a "forked" x with all sorts of hooks higher up. - but it's possible...
> and then x client work as they always did - and get more use of the hardware 
> :)

MicroXwin ?


"MicroXwin is binary compatible to the Xlib API. However it is niether
client server nor network oriented. Graphics operations are
implemented in the linux kernel via a kernel module. An open source
Xlib library sends graphics commands to the kernel. There is no
network overhead and no context switch from X client to X server. This
makes our solution smaller and faster than traditional X Windows."

- John

Openmoko community mailing list

Reply via email to