[Qt-interest] QGraphicsItem and Threads

[marc at mferland.net]

Quoting Thiago Macieira <thiago at kde.org>:

> Em Terça-feira 20 Outubro 2009, às 11:02:42, você escreveu:
>> AFAIK Win32 allows GUI operations in any thread - but all the operations
>>  for a given window must be done in the same thread.  I suspect all child
>>  windows belonging to the same parent have to be in the same thread as
>>  well.  I believe X is the same.  So I assume Qt is dumbed down to suit Mac
>>  OSX, or maybe it is due to the extensive use of caches: fonts, images,
>>  etc.
>
> On X, all operations are serialised through the X connection socket. That's a
> shared resource, belonging to the entire application.
>
> If multiple threads were writing to that socket, they'd need to coordinate to
> ensure that one thread does not step on the other one's toes. They   
> must either
> lock the socket or execute only atomic writes -- which the POSIX API does not
> guarantee, so atomic writes are out.
>
> Not to mention of course coordination between multiple operations and reading
> from the socket. Only one thread can read from the socket.
>
> The alternative to that is to open one socket per thread. But libX11 doesn't
> do that and its API is also not thread-safe. I'm told libxcb can do it, but
> none of the major toolkits for X11 (Qt included) use it.
>
> In any case, you're also right about the extensive use of caches and other
> resources. Since the Qt GUI API was designed to work in a single thread, it
> makes use of that fact to do lazy-initialisation, caching, etc. Some of the
> performance improvements introduced may require modifying a global state of
> some sort, which in turn would require locking if it were multithreaded.

I see that Qt supports the XEmbed extension (through the  
QX11EmbedContainer class). Would this be an alternative to threads?  
This way, each QGraphicsView widget would be an independent process  
and so the "main" gui thread would not be overloaded when dealing with  
lots and lots of events.

The drawback here is that it doesn't seem to be a very portable solution.

I guess you'd also have to create a protocol to communicate with this  
process if you want to control the widget, etc.

Marc