
Thread beginning with comment 293189
RE[3]: syllable desktop
by nulleight on Wed 26th Dec 2007 12:07 UTC
Member since:

Well my original point is that networking design makes X serial(over the socket) but it doesn't have to be so.

X is limited to 1 even queue, and if there are alot of events there, it stalls. Imagine one thread for a mouse and one for keyboard events( for example using select() on /dev/input/eventX). When i press a button, i lock a mutex in a window and change it's properties and at the same time recieve an event in another thread from a mouse which is above another window which i can lock and do something dependent on mouse button. At this time nothing is drawn. Then a video adapter thread locks what's on screen and draws it an so forth, while other threads can continue to recieve events. But in the case of X11 everything is serialized over the socket, ther parallelism is lost. All events come after each other and in case of Xlib each event blocks. But even xcb doesn't have the advantage if one needs a reply.

I also don't say you need any trade-off like network transparency. You can have a special thread that could gather all the events and send them over the network. I'ts just that X design traded off latency for those few than needed network transparency. So everyone has to suffer because of network transparency instead of
choice to suffer it only if they have to.

Regarding the xcb go to their homepage and try to find good documentation. I also have an example which works whith xlib but doesn't work with xcb. I can send you the code on request. From my point of view xcb is a half-harted poorly documented attempt to address latency but not the design X protocol.

The whole thing could be remedied whith open source drivers at which point noone would have to use X11.
This maybe very off-topic but it's one of the reasons projects like this on top of linux kernel make so much sence in my opinion. Linux has great hardware support now and a more flexible windowing system( or another os or whatever you call it, i'll go with any) on top of it would be much better inmho.

Edited 2007-12-26 12:12

Reply Score: 1

RE[4]: syllable desktop
by renox on Wed 26th Dec 2007 22:22 in reply to "RE[3]: syllable desktop"
renox Member since:

I think that the locking/ordering of events in the multiple queue design you're suggesting must be quite hard:
Say Window A is selected at the beginning.
a-A mouse event select Window B.
b-A key is pressed.
Depending whether a or b occurred first, the key pressed event must be sent to Window A or B.
So these queue must sometime be synchronised carefuly..

I wonder how BeOS worked, with one queue or with multiple queues?

While I don't know if a different thread&queue to handle each device is interesting, I think that a different thread in the GUI server for each client application makes sense as this simplify the multiplexing of clients: currently an application even if low priority may flood the X server, making the higher priority application appear less responsive than it ought to..
With a different thread in the X server for each client app, maybe the OS scheduling could solve this issue, of course there is still the risk of a priority inversion caused by shared resource (and as the videocard itself is shared, it's not truly possible to avoid sharing)..

Reply Parent Score: 2