From performance point of view

 Hi all,


Before reading this 'first & short' email to this list,
I would like you start by doing:
wget http://blueos.free.fr/Static.tar.gz
tar -zxf Static.tar.gz
cd Static
./test
and press SPACE, move some windows, look at you cpu consumption.

 This code was coded in June 2002, and release in October 2002,
it evolved a lot after this date, is faster, consume less, but
the result is the same, it reaches the _ minimal _ performance 
that xserver must IMHO reach to be a success.

In the past, I had to 'sink' in the XFree86 code to understand
what the main issues were. I'm not a vodoo spirit, just a
software engineer who tried to find the best way to use Xfree,
so it could help for a new xserver.

If you have some time you can read:
http://www.osnews.com/story.php?news_id=1905

So I enjoy seeing a project like freedesktop to start,
and would be happy to help a bit if I can.
IMHO a 'revolution' can't appear if xserver stay X11 centric,
I mean that it's not bad to provide a Xlib or 'standard' extensions,
but I would like to push to trash (or fire) all the book about X
I have on my desk (yes, I have read more 2000 pages about the
subject...:( ).

Keys for userfriendly:
o non blocking UI operations
   -> 1 thread per window in userland
   -> 1 thread per xserver-internal-window (xserver-land)
  communications done by message queue
o implement a Syncro() function which block until the operations
before the the last Syncro() are _REALLY_ done.


Keys for performances:
o a composing manager as closed as possible of
the native bitmap management of modern gfx card
  -> full 32bits
o reduce the number of operations managed by the
servers (remember the RISC approach for processors)
  -> it means that an xlib compatibilty layer must be userland and
   only rely on the primitives operations
  -> client side widgets
  -> color conversion in userspace (no conversion for 32bits data of
course)
o 1 bitmap per window with a cache system ( bitmap rebuilt ondemand )
o  shared bitmap on local use (by shared memory if running on the same
computer) between the userland and xserser-land.
o a separate input server which communicate asyncronoulsy with the
xserver
o an 'input gate' which filter the inputs by looking at the rendering
status ( ex: flush intermediate mouse-moved event if the refresh rate
become to slow )
o integrated AA font rendering in the xserver. 
o be 'verticaly synchronised' on drawing.
o never ask a redraw for something already drawn (or stored in
the window bitmap)

I promised to make a short email, so I will not explain more now.
It's not 'thought' or 'guesses', all what I'm talking about
were tested, and validated.
If not kicked out, I would be happy to argue with a lot of more
description of the previous point, with con and pro, and a lot
of technical points.

Regards,
Guillaume


PS: Sorry for my bad english writing.