[Interest] QPrintPreviewWidget

william.crocker at analog.com william.crocker at analog.com
Tue Apr 4 18:56:28 CEST 2017


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.crocker at 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.crocker at 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 at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Interest mailing list
>>>> Interest at qt-project.org
>>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>>
>>> _______________________________________________
>>> Interest mailing list
>>> Interest at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/interest
>>>
>>>
>>>
>> _______________________________________________
>> Interest mailing list
>> Interest at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/interest
>
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
>
>



More information about the Interest mailing list