bugGNU Octave - Bugs: bug #32319, refresh plot code needed after...

 
 

bug #32319: refresh plot code needed after printing plot

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Tue 01 Feb 2011 06:28:29 PM UTC  
 
Category: Plotting with OpenGLSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Crash
Status: FixedAssigned to: None
Originator Name: Michael GodfreyOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Tue 12 Mar 2013 10:22:03 PM UTC, comment #21:

No follow-ups after a year so presumably the patch did fix things. Closing report

Rik <rik5>
Project Administrator
Fri 17 Feb 2012 01:15:36 AM UTC, comment #20:

ping !

With the recent changes to graphics.cc, _init_fltk_.cc, and print.m (below) does this problem persist ?

If so, does adding "waitpid(0)" immediately after the print command resolve the problem?

Ben Abbott <bpabbott>
Project Member
Thu 29 Sep 2011 04:03:55 PM UTC, comment #19:

Re-titling bug report to capture the remaining issue to be fixed.

Rik <rik5>
Project Administrator
Tue 15 Feb 2011 05:54:55 PM UTC, comment #18:

I have now pushed this changeset. I could also reproduce the issue with the dirty plot window with and without the patch, so we need a seperate bug report for this.

Konstantinos Poulios <logari81>
Project Member
Sun 13 Feb 2011 05:09:37 AM UTC, comment #17:

I have done some more tests using slow
connections. The original problem has
not reappeared. So, I am pretty sure that is
is fixed.

However, now that print works reliably there
is an issue: after the print command the
plot window ends up in various states depending
on timing:

1. The display does not change and ends up correct.
2. The display changes during the display (resizes,
for example) and then ends up OK.
3. Ends up all black.
4. There are probaly other states.

Clicking on the plot window usually causes it
to be refreshed to its correct state. But, this
may take a few tries.

So, it would be good to consider some code which is
executed just before exit from the print command
which refreshes the plot window.

In any case, this patch (bug32319-1b.diff) should be
converted to a changeset (add and update to Changelog)
and pushed. It definitely fixes the original problem.
The items above were surely true before, but not
noticed due to Octave crash.

Again, an important problem fixed. Thanks!!!

Michael Godfrey <godfrey>
Sat 12 Feb 2011 04:39:41 PM UTC, comment #16:

bug32319-1b.diff replaces all previous patches.

This looks good!!!

I will do some more testing, but the test that always failed
now works.

There is a minor point that affects use of fltk generally:
If your WM is configured not to give focus to the plot
window when it is initially created then changes to the window
do not appear until the window is first given focus. After
the first focus things work OK. So, in the case of my print
test, if I just run the test which is simply
plot(1:200)
print testpdf.pdf
the plot window appears correctly after the plot(1:200)
but ends up as "snow". As soon as I click on it the
correct plot appears. This is just a minor nuisance.

Thanks very much for resolving the long-standing problem.

it the plot appears correctly.

After some more tests I expect to recommend closing this
bug.

By the way, the graphics.cc part of the patch got a "patch
offset by 5 lines but succeeded" message with respect to
what I think is the current development tip. You may want
to check this before it is committed.

Michael Godfrey <godfrey>
Sat 12 Feb 2011 09:35:21 AM UTC, comment #15:

Ok, the misuse of waitpid explains the problem.

However, I have fixed the previous patch witch doesn't use waitpid at all. Could you take a look at?

bug32319-1b.diff replaces all previous patches.

(file #22657)

Konstantinos Poulios <logari81>
Project Member
Sat 12 Feb 2011 06:31:30 AM UTC, comment #14:

That is a misuse of waitpid in the _fltk_print_ function. The waitpid function waits for subprocesses given a process ID. But in this context PID is a file ID that refers to a pipe that is open for writing, not a process ID.

John W. Eaton <jwe>
Project Administrator
Sat 12 Feb 2011 05:13:45 AM UTC, comment #13:

Again, I was not paying as much attention (doing too many
things at once) as needed. Basically, forget the immediately previous comment.

The make with the 2 patches was OK, and the reported result
shows that it still fails as before.

Sorry about the noise.

Michael

Michael Godfrey <godfrey>
Sat 12 Feb 2011 05:04:47 AM UTC, comment #12:

No, I paniced too soon. The comment was
with respect to the system build with both
patches.

But, I should have noticed:

src/graphics.cc:7408: if (++drawnow_executing <= 1)
src/graphics.cc:7456: error ("drawnow: invalid argument, expected `expose' as argument");
src/graphics.cc:7498: error ("drawnow: nonexistent directory `%s'",
src/graphics.cc:7529: error ("drawnow: nothing to draw");
src/graphics.cc:7532: error ("drawnow: invalid debug_file, expected a string value");
src/graphics.cc:7535: error ("drawnow: invalid colormode, expected a boolean value");
src/graphics.cc:7538: error ("drawnow: invalid file, expected a string value");
src/graphics.cc:7541: error ("drawnow: invalid terminal, expected a string value");
src/graphics.df:25: XDEFUN_INTERNAL (drawnow, args, , "-- texinfo --\n@deftypefn {Built-in Function} {} drawnow ()\n@deftypefnx {Built-in Function} {} drawnow (\"expose\")\n@deftypefnx {Built-in Function} {} drawnow (@var{term}, @var{file}, @var{mono}, @var{debug_file})\nUpdate figure windows and their children. The event queue is flushed and\nany callbacks generated are executed. With the optional argument\n@code{\"expose\"}, only graphic objects are updated and no other events or\ncallbacks are processed.\nThe third calling form of @code{drawnow} is for debugging and is\nundocumented.\n@end deftypefn")
=========================
This explains why I got the same result as before.

Michael Godfrey <godfrey>
Sat 12 Feb 2011 04:00:52 AM UTC, comment #11:

Please forget the preceeding comment. I ran test in wrong
system.

More soon.

Michael Godfrey <godfrey>
Sat 12 Feb 2011 03:57:37 AM UTC, comment #10:

After applying both patches I still get:
octave:2> print testpdf.pdf
error: drawnow: nonexistent directory `/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile=testpdf.pdf /tmp/oct-Kam3Ep.ps - ; rm /tmp/'
error: called from:
error: /d/src/octave/hg/octave/scripts/plot/__fltk_print__.m at line 153, column 5
error: /d/src/octave/hg/octave/scripts/plot/print.m at line 382, column 12
============================
Is part of the problem with the: rm /tmp/

Michael Godfrey <godfrey>
Sat 12 Feb 2011 01:35:45 AM UTC, comment #9:

Try this one on top of the previous one.

(file #22654)

Konstantinos Poulios <logari81>
Project Member
Sat 12 Feb 2011 12:47:39 AM UTC, comment #8:

I tried a test:

octave:1> plot(1:200)
octave:2> print testpdf.pdf
error: drawnow: nonexistent directory `/usr/bin/gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -dEmbedAllFonts=true -dOptimize=true -dEPSCrop -sPAPERSIZE=letter -dFIXEDMEDIA -sOutputFile=testpdf.pdf /tmp/oct-KxoDC9.ps - ; rm /tmp/'
error: called from:
error: /usr/local/share/octave/3.5.0+/m/plot/__fltk_print__.m at line 153, column 5
error: /usr/local/share/octave/3.5.0+/m/plot/print.m at line 382, column 12
octave:2>
============================================
Looks like a minor fix is needed.

Michael Godfrey <godfrey>
Sat 12 Feb 2011 12:24:25 AM UTC, comment #7:

Please test the attached patch. Unfortunately I cannot test it right now due to broken graphic drivers but theoretically it should work.

(file #22653)

Konstantinos Poulios <logari81>
Project Member
Fri 11 Feb 2011 09:54:37 PM UTC, comment #6:

In _init_fltk_.cc. line 764 drawing is set to printing mode:

canvas->print (fid, term);

then in _init_fltk_.cc. line 768 we call:

mark_modified ();

which triggers graphics redraw that ends up at some canvas->draw asynchronously.

It seems that

waitpid (pid);

at line 159 of _fltk_print_.m is not a sufficient guarantee that the code execution will reach and complete line 160 _init_fltk_.cc:

rend.draw (gh_manager::get_object (number));

where the actual printing takes place before it closes the pipe at line 161 of _fltk_print_.m:

pclose (pid);

Maybe we need some other check.

Konstantinos Poulios <logari81>
Project Member
Fri 04 Feb 2011 07:14:55 AM UTC, comment #5:

To provide an aid to fixing this problem,
there are 3 possible results of the print
command:

1. The command completes without showing an
error and the PDF is correct.

2. The error message is displayed and no PDF
is written

3. The command completes without showing an
error, but the PDF is incomplete.

I speculate that the reason for case 3 is that the
gl2ps fdopen executes while the file exists but
has not yet been fully written. This could be
tested by changing the code that writes the file
to lock it until the write is complete.

Michael Godfrey <godfrey>
Thu 03 Feb 2011 07:07:58 AM UTC, comment #4:

OK, I reopened this report with a new summary.

John W. Eaton <jwe>
Project Administrator
Thu 03 Feb 2011 07:03:27 AM UTC, comment #3:

John,
I would not quite call this fixed. The SEG FAULT
is prevented, but the print file does not get
generated. All I accomplished was to prevent
the SEG FAULT.

The problem of how to prevent gl2ps from trying
to read the file that has not been written yet remains.

Michael Godfrey <godfrey>
Thu 03 Feb 2011 06:12:13 AM UTC, comment #2:

Thanks, I checked in this changeset, credited to you:

http://hg.savannah.gnu.org/hgweb/octave/rev/11427f71699b

John W. Eaton <jwe>
Project Administrator
Tue 01 Feb 2011 06:52:59 PM UTC, comment #1:

The attached, very crude, patch prevents
the SEG FAULT.

The current plot ends up corrupted and
a CR is required before the octave> prompt
appears, but then things look normal and
other plotting can be done.

Michael

(file #22583)

Michael Godfrey <godfrey>
Tue 01 Feb 2011 06:28:29 PM UTC, original submission:

I thought that there was an outstanding report on this, but I
could not find it. In any case, I have tested this problem
and it still happens when fltk plotting is used over a remote
connection or a connection such that graphics rendering takes
too long. This has been a long standing failure. But, I
have an interim suggestion:

The failure now occurs at line 5650 of gl2ps.c:
gl2psMsg(GL2PS_ERROR, "Bad file pointer");
gl2psFree(gl2ps);
gl2ps = NULL;
return GL2PS_ERROR;
==========================
However, the specific cause is at line 46 of gl2ps-renderer.cc:
FILE *fp = fdopen (fid, "wb");
============================
It is the fact that fdopen returns NULL that causes the failure.
Would it be better to test for fp == NULL at this point and if
possible make a non-fatal return? This would be better than the
current SEG FAULT which loses any current work.

I have attached a bt of the current failure. And, I will
try to learn more about the cause of this problem, but I
know little about OpenGL.

Michael

Michael Godfrey <godfrey>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #22657:  bug32319-1b.diff added by logari81 (6kB - text/x-patch)
file #22654:  bug32319-2a.changeset added by logari81 (2kB - application/octet-stream)
file #22653:  bug32319-1a.changeset added by logari81 (5kB - application/octet-stream - patch for testing)
file #22583:  gl2ps-renderer.diff added by godfrey (634B - application/octet-stream)
file #22582:  fltk_bad_pointer added by godfrey (3kB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bpabbott (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by logari81 (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by godfrey (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 12 Mar 2013 10:22:03 PM UTCrik5StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Thu 29 Sep 2011 04:03:55 PM UTCrik5Summaryprinting sometimes fails with error "gl2ps-renderer: fdopen failed"=>refresh plot code needed after printing plot
    Sat 12 Feb 2011 09:35:21 AM UTClogari81Attached File-=>Added bug32319-1b.diff, #22657
    Sat 12 Feb 2011 01:35:45 AM UTClogari81Attached File-=>Added bug32319-2a.changeset, #22654
    Sat 12 Feb 2011 12:24:25 AM UTClogari81Attached File-=>Added bug32319-1a.changeset, #22653
    Thu 03 Feb 2011 07:07:58 AM UTCjweStatusFixed=>None
      Open/ClosedClosed=>Open
      SummaryGL2PS error: Bad file pointer=>printing sometimes fails with error "gl2ps-renderer: fdopen failed"
    Thu 03 Feb 2011 06:12:13 AM UTCjweStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Tue 01 Feb 2011 06:52:59 PM UTCgodfreyAttached File-=>Added gl2ps-renderer.diff, #22583
    Tue 01 Feb 2011 06:28:29 PM UTCgodfreyAttached File-=>Added fltk_bad_pointer, #22582

    Back to the top


    Powered by Savane 3.1-cleanup