On Thu, 2008-02-21 at 17:34 -0300, Tiago Vignatti wrote: > Again, the same reason: the lack of developers. But try to ask someone > who already tried to use multiple threads under Xlib. It's a painful. > And this is one of the XCB beauties.
thats very much a matter of opinion. X made a very conscious design decision very early on to impose no additional costs (i.e. mutexes) in what was then percieved to be the common case: single threaded GUI code. this is in marked contrast to (for example) the win32 drawing API(s) which do the opposite: they require no additional application code to handle mutexes for what was perceived by MS to be *their* common case: multithreaded GUI code. given that most developers working on X interact with it via a toolkit which poses its own locking issues independently of X, solutions to "i want to use multiples threads to call (GTK|Qt|FLTK|whatever) functions" are generally going to be most significant within those same toolkits. my primary app runs many, many threads that could theoretically interact with the graphics subsystem, but uses an architecture so that only one of them actually does so. this design works very well for many, perhaps even most, applications. don't get me wrong: i think XCB is an excellent idea and its a shame its not crossed the threshold of being ready for use everywhere. but you have been trying to make an argument about levels of the graphics stack at which certain things need to happen, and i don't believe your argument is sound or backed up by demonstrable evidence. --p _______________________________________________ Desktop_architects mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
