Re: Printing issues with Qt toolkit

[Rik]

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

 

Pantxo