octave-maintainers
[Top][All Lists]
Advanced

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

Re: Printing issues with Qt toolkit


From: Pantxo Diribarne
Subject: Re: Printing issues with Qt toolkit
Date: Thu, 12 Nov 2015 21:57:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Le 09/11/2015 08:23, Daniel J Sebald a écrit :
On 11/08/2015 07:41 AM, Pantxo Diribarne wrote:

Le 07/11/2015 01:36, Rik a écrit :

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





@Rik:



Q1: yes, probably. A good place to see those threading issues in action

is trying to run scripts to generates demo plots (see attached

dump_plot_demos.m). Using non patched stable branch you'll observe that

some images are not generated: not reproducible, i.e. failing demo

images are not always the same but there are always failures on one or

another. Also you'll see a bunch of warnings (not clearly related to

failing images) "warning: gl2ps-renderer::draw: empty feedback buffer

and/or nothing else to print" .

With the patch (50ms sleep) no such warning and all images are properly

generated.



Q2: I used the attached "print_fail.m"  to evaluate the proportion of

failing prints for bug 44463:

sleep 10ms -> 2/100

sleep 50ms -> 0/100

I am pretty sure the result will depend on if your system is busy with

other softwares, and it is thus not a definite solution to our threading

issues. But I also think it is much better than the current situation.



I'm pretty sure of that too.  Sure, it turns a common bug into a rare,
obscure bug, but in the long run there is still a structural issue to
address: thread management and data interchange.



I saw mention of a new Octave version.  Any possibility of getting some
of the gnuplot printing/plotting bug fixes incorporated?



Dan



Hi,

I applied the 50 ms delay for now:

http://hg.savannah.gnu.org/hgweb/octave/rev/a7903de9c359

Thank you all for your feedback.

Pantxo




reply via email to

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