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-requ...@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
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
