On 04/04/2017 11:52 AM, Dan Allen wrote:
Hi Bill,

What you've listed below is pretty much how my printing mechanism works.  This
works perfectly and I'm happy with it.

I'm still a little confused as to why the preview can't operate in the same
way.  If another thread paints into a QImage and then informs the dialog using a
signal such that the GUI thread can then display it on the screen, why is this
an issue?

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.

Bill

Why does the GUI thread have to do the time consuming task?  The Qt
documentation for QImage states "When using QPainter on a QImage, the painting
can be performed in another thread than the current GUI thread."

Yes. That is my understanding too, as stated above.


Thanks,

Dan Allen.


On 03/04/17 14:49, william.croc...@analog.com wrote:
On 04/01/2017 09:48 AM, Dan Allen wrote:
Hi Bill,

I agree, however when the print is quite complex it makes the GUI very
unresponsive.

Painting into an off screen image is not GUI related. The print preview could
show something like "Generating Preview" while a background thread generates it
and then show it when it's ready for example. This would prevent the GUI from
seeming unresponsive to the user. I wasn't sure if there was a current method to
do something like this.


Yes. We agree that the actual printing is non GUI, but if you want
to show a print preview or progress meter, that is GUI and needs
to stay in the main thread.

So, something like:
- Create a progress meter dialog.
- Start your printing in a sub thread.
- The main thread waits, perhaps in a sub-QEventLoop, servicing events.
- After a few seconds, if printing has not completed, show the dialog.
- The sub-event loop monitors the printing process with a thread safe
  communication mechanism, like signals and slots.
- When the printing completes, close the dialog.
- Exit your sub-event loop.

Thanks,

Dan Allen.


On 01/04/17 13:43, william.croc...@analog.com wrote:
On 04/01/2017 03:41 AM, Dan Allen wrote:
Hi,

Could anyone tell me if it's possible to paint into a QPrintPreviewWidget in
another thread, and if so, how?

I have created a class to perform printing and this runs in another thread.
When used for printing it works fine.  However when used for the print
preview,
nothing is shown unless I force the signal to either Qt::DirectConnection
(i.e.
use the GUI thread) or Qt ::BlockingQueuedConnection (i.e. block the GUI
thread).

Dan:

Conventional wisdom, if not the rule of law, states that all GUI activity
should be done from the main thread. You may just be experiencing
the Qt library enforcing this rule.

Bill

Thanks,

Dan Allen.


_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest



_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Reply via email to