[Qt-interest] Create a new GUI Thread

[Bill KING]

Shot in the dark, but with your plots, have you tried drawing to a
QPixmap inside the threads, and then just pumping that to the screen
occasionally? Theoretically it should be no different than drawing to a
window, but you tell the UI when to update its idea of the visuals.

Luke Campagnola wrote:
> On Mon, Mar 2, 2009 at 18:56, David Johnson <david at usermode.org
> <mailto:david at usermode.org>> wrote:
>
>     The GUI parts of the application need to be in the same thread. It's a
>     limitation on both X11 and Mac. There may be ways around this
>     under Windows,
>     but it is not supported and may break with new Qt releases.
>
>
> I thought that might be the case, but I'm pretty surprised by it--why
> should X11 care whether two windows are controlled by two separate
> processes or by two threads in the same process?
>
>     But since QThreads can easily communicate with each other, there
>     is very
>     rarely a need for GUI elements to be in different threads. Have a
>     worker
>     thread do the heavy lifting, then communicate its results to the
>     main GUI
>     thread.
>
>
> In my case, the majority of the heavy lifting is in GUI operations (ie
> graphicsview updates--multiple scrolling plots and video displays).
> I've already farmed out all of the non-GUI labor to other threads, but
> the GUI is still too heavy for one core to handle efficiently.
>
> Whether or not there is a real need to have multiple GUI threads, from
> an application design standpoint it often makes a lot of sense.
> Separating a GUI and the data it displays means there is added
> overhead in message passing and a lot of extra programming. 
>
> To me, asking why you would want to have multiple GUI threads is like
> asking why you would want to have multiple processes running in X. If
> you're only using one program at a time, there's no need to have
> multiple processes at all. As the system becomes more complex, it
> makes sense to logically divide X control into multiple processes that
> draw into their own windows. Likewise, the software I am writing is
> complex enough that it makes a lot of sense to break the application
> up into components that operate independently and draw their own GUI.
> The only difference for me is that my components also need to exchange
> large amounts of data and at times must be able to synchronize easily.
>
> I'm stuck somewhere between using a slow, monolithic application and
> using multiple applications communicating via IPC. Seems like right
> now there's just no really elegant solution to the problem, although
> DBUS looks somewhat promising if it can become a little less
> unix-centric..
>
> Q
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>   


-- 
Bill King, Software Engineer
Qt Software, Nokia Pty Ltd
Brisbane Office