octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Printing issues with Qt toolkit


From: Pantxo Diribarne
Subject: Printing issues with Qt toolkit
Date: Wed, 4 Nov 2015 09:27:17 +0100

Hi,

I think part of the issues we currently experience when printing with Qt toolkit is due to threading.

Our printing process is as follows: except for pdf/epslatex and svg (for which we directly use gl2ps output) the figures are always printed to eps using gl2ps and then converted to the actual desired format using ghostscript.

For this to work, we need to be sure the base eps figure has been printed before we try to convert it. As Qt widgets run in a different thread than the interpreter we use the following construct in drawnow:

    gh_manager::unlock ();

    go.get_toolkit ().print_figure (go, term, file,
                                                      mono, debug_file);

    gh_manager::lock ();

As print_figure calls other methods (actually Figure::print in the end) which are run in another thread, it returns immediately, regardless of the job being actually finished. If we are lucky the toolkit's Figure::print method will grab the mutex fast enough to force drawnow to wait for the job to be finished. Unfortunately this doesn't work most of the time.

Here are the solutions I have thought about:
*1. Nasty but easy (could be part of 4.0.1): add a small sleep after print_figure to give enough time to Figure::print to grab the mutex. On my computer 50 ms is enough to fix e.g. bug #44463
*2. Not academic: let Figure::print and callers return a value so that print_figure only returns when the job is actually finished. This is not as straightforward as it sounds as Figure::print is currently called via signal/slot mechanism.
*3. Implement a more thread friendly method (using semaphores?).

Thoughts?
Someone strongly against solution 1 in 4.0.1?

Pantxo
 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]