Hi Paul,
Paul Davis wrote:
> 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.
XCBs design seems to be superior to xlib also in the single threaded
case, as it does not impose latencies of synchronous calls. AFAIK with
xlib this can only be achieved by using multiple connections and
multiple threads, please correct me if I am wrong.
> 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.
I did some programming of the Win32 API, which's threading model is
_inherently_ broken (and especially hard in combination with COM/OLE).
We should not use it as an example of how to do it right.
>
> 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.
I agree, for most applications it is sufficient to use a single thread
to deal with the user interface. Consequently applying event driven
techniques the single thread approach is even feasible (and more easy to
implement, IMHO) for most applications themselves.
>
> 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.
Yep, seems that we are off-topic ;-)
>
> --p
>
>
Kay
--
Sun Microsystems GmbH Kay Ramme
Sachsenfeld 4 Senior Technical Architect
20097 Hamburg Phone: (+49 40) 23646 982
Germany Fax: (+49 40) 23646 550
http://www.sun.com/staroffice mailto:[EMAIL PROTECTED]
http://www.sun.com/openoffice
http://udk.openoffice.org
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
_______________________________________________
Desktop_architects mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
