Hello,
my view is very different from yours.
I wonder if discussing here can be interesting.
>>The X server contains lots and lots of crufty old code going back to
the 1980s that nobody uses and nobody (including the X developers) wants
to maintain, but is required to claim to be an X server.<<
More precisely these 'obsolete' features are needed only if you want to
claim to implement the X protocol version 11.
If X developers wanted really to get rid of these features, it would be
technically very easy: just increment the major protocol version to 12
and remove the support of these features.
The difficult part is sociological: agreeing on which features to drop
and convince all the X clients to use X version 12 instead of X version
11 (not difficult technically if they don't use the dropped features).
The big differences between Wayland and X that I see are:
1) with Wayland communications between the applications and the 'display
manager' are made with 'shared video memory'.
This means that GPUs will be used very efficiently.
But this also means that the network transparency is not done anymore in
the display subsystem but above it.
2) with X, the communications between the programs and the 'display
server' use the X API which has two variants:
a- a shared memory variant for local usage, but here this is the main
memory used (RAM) not video memory, so the GPU cannot be used will full
efficiency (either the application don't use the GPU or it has to copy
the GPU's video memory back into the main memory to share it with the X
server which is not very efficient).
b- a socket variant, which allow network transparency.
I wonder if it would be possible to add to X a third variant for local
usage: use shared video memory to communicate between the client and the
server.
What would be the difference between this and Wayland?
BR,
Renaud.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
