[Interest] QPrintPreviewWidget

Roland Hughes roland at logikalsolutions.com
Tue Apr 4 19:32:36 CEST 2017

Not ignoring your question Bill, but this response answered it better.

There is always __something__ which gets in the way. Ultimately you end 
up needing an object which can only exist in the primary thread due to 
the tight coupling of that thread to the underlying windowing system and 
that object being "GUI" instead of data.

On 04/04/2017 12:00 PM, interest-request at qt-project.org wrote:
> I do not think that is an issue.
> I think you can paint to a QImage in a non-GUI thread, because
> a QIMage is a non-GUI object, unlike a QPixmap which is (or at least
> was historically) a "GUI" object.
> The term GUI (in this conversation and in my understanding)
> is generally when you interact with the underlying window system to
> create and use Windows which appear on the screen.
> Yes, the QPainter class lives in the QtGUI module, but I do not
> believe it's use is restricted to the main thread. On Linux and
> in the past, interaction with the X11 server was limited to the main
> thread. That is why use of QPixmap was limited to the main thread.
> That is why use of on screen Windows was limited to the main thread.
>   From the QPixmap doc:
>       "...pixel data in a pixmap is internal and is managed
>        by the underlying window system."
> So (at least in the past) when you draw on a QPixmap, instructions
> are being sent to the "underlying window system" and (in the past)
> that was across a network connection to the X11 server.
> How any of this has changed with the introduction
> of QPA (Qt Platform Abstraction) I do not know.

Roland Hughes, President
Logikal Solutions


More information about the Interest mailing list