On 11/04/2015 03:07 AM, address@hidden wrote:
Subject:
Printing issues with Qt toolkit
From:
Pantxo Diribarne <address@hidden>
Date:
11/04/2015 12:27 AM
To:
Octave Maintainers <address@hidden>
List-Post:
<mailto:address@hidden>
Precedence:
list
MIME-Version:
1.0
Message-ID:
<address@hidden>
Content-Type:
multipart/alternative; boundary=047d7b45105e3876ca0523b2c786
Message:
3
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?
I suppose the answer will depend roughly on whether you ask a
scientist (get it right) versus an engineer (get it done). Printing
is not a performance-oriented command located in the tightest inner
loop of someone's code, and so I don't have a problem adding a small
delay when the gain is large and the downside is small.
Question 1: Is this likely to help fix other printing bugs besides 44463?
Question 2: Since the bug is probabilistic, what range of delays did
you test (10, 20, 30, 40, 50)? And how many successes did you have at
50 ms to conclude that "it works". Is this 10/10, 50/50, 100/100, or
more?
Cheers,
Rik