octave bug tracker notifications

Michael Godfrey | 19 Jun 2012 03:17

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

URL:
  <http://savannah.gnu.org/bugs/?36679>

                 Summary: Timing error for multiple plots
                 Project: GNU Octave
            Submitted by: godfrey
            Submitted on: Tue 19 Jun 2012 01:17:10 AM GMT
                Category: Plotting with OpenGL
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: Michael Godfrey
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

I am sorry to say that this problem is hard to document by an
example since it depends on timing of a sequence of plots.

(Continue reading)

headers

Michael Godfrey | 19 Jun 2012 15:50

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #1, bug #36679 (project octave):

I was unclear about one point below: the pause(6)
needs to be placed within the sequence:

hold on
... some plot calls
hold off

Each figure is made up of quite a few plot calls which
add data curves to the figure.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

headers

Michael Godfrey | 19 Jun 2012 17:26

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #2, bug #36679 (project octave):

One additional fact:  I tried replacing
the pause(6), placed immediately before
the print command, with:
drawnow();
pause(3);

For the cases that worked without the pause
the figure with all the data is shown during the
pause.  For the case that failed, only a blank
figure is shown until after the pause when
the print ...  is running.

So, it appears that drawnow() not working
and print failing to produce the correct BB
are related.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah

(Continue reading)

headers

Michael Godfrey | 21 Jun 2012 21:00

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #3, bug #36679 (project octave):

I have located the code in print.m which
seems to cause the BB change.  The line is
at 323:

    set (opts.figure, "position", fpos);

If this line is commented out the BoundingBox
for all plots in the loop is the same without
any pause() commands.  However, it is not the
size that was previously "correct." It is
the samller size which occurs after a number of
plots without any pauses.

It is also true that this command causes the figure on the 
screen to move up (and I assume) expand. Having the
figure jump on the screen during print() is not too
good.  The original position and size is restored
when print() is done.

So, the reason for the BB size change is that the 
set command above does not always take effect before
print actually generates to output file.

Two things need fixing:

(Continue reading)

headers

Michael Godfrey | 21 Jun 2012 21:31

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #4, bug #36679 (project octave):

A bit more information: the obvious
purpose of the 
set (opts.figure, "position", fpos); 
is to make the figure BB be invariant
to the size and position of the figure on 
the screen.  This is consistent with the 
Matlab way.  For the same plot in Matlab
and Octave (using set above) I got:
Matlab:
t1.ps:9:%%BoundingBox: (atend)
t1.ps:162:%%PageBoundingBox:    73   215   552   589
t1.ps:347:%%BoundingBox:    73   215   552   589
t2.ps:9:%%BoundingBox: (atend)
t2.ps:162:%%PageBoundingBox:    73   215   552   589
t2.ps:347:%%BoundingBox:    73   215   552   589

Octave:
t1.ps:3:%%BoundingBox: 70 232 548 602
t1.ps:4:%%HiResBoundingBox: 70.900000 232.300000 547.100000 601.600000
t1.ps:52:%%PageBoundingBox: 0 0 612 792
t2.ps:3:%%BoundingBox: 70 232 548 602
t2.ps:4:%%HiResBoundingBox: 70.900000 232.300000 547.100000 601.600000
t2.ps:52:%%PageBoundingBox: 0 0 612 792

(Continue reading)

headers

Rik | 29 Jun 2012 20:31

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #5, bug #36679 (project octave):

Following your logic, I wonder if the most of the calls which alter figure
attributes return before the effects of those changes have been propagated.

It makes some sense.  Changing the figure position property properly causes
some listeners to fire.  If the print script continues before the listeners
have had a chance to execute themselves then you might have results which are
out of sync with what should be appearing on the screen.

Just for the sake of testing, you might want to add a pause() statement just
before the actual call to print the figure which is at line 412 of print.m.

If a delay works there, then we can think of how to approach this.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

(Continue reading)

headers

Michael Godfrey | 29 Jun 2012 20:53

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #6, bug #36679 (project octave):

Rik,

Thanks for thinking about this.  I have tried quite
a number of experiments using pause(). Including placing
a pause() at line 412 as you suggested. Somewhat to
my surprise this pause() and pause() immediately 
before the print() in my code does not in general help.  

What seems to be mor reliable is to place pause(n) 
statements between the sequences of plot() commands.
It appears to be the case that if a long sequence of plot()
commands with hold on are given, the system gets into
a state such that it never reaches a correct state for
printing.
(Even though the dispalyed plot is correct!)

A key part of this problem, I think, is the current
requirement that the figure has to be rendered in order
for print() to work.  It is obvious that Matlab has found
a way around this even though they appear to use OpenGL.
In Matlab you can move the figure to anywhere on the screen
and then do a print().  The figure does not move as a result.
In Octave, if you move the figure, it then is moved back to 
an "original" position when print() is done. It is also

(Continue reading)

headers

Michael Godfrey | 30 Jun 2012 15:36

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #7, bug #36679 (project octave):

Also, I thought that additional drawnow() commands
in print.m might help, but they did not.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

headers

Rik | 1 Jul 2012 17:33

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #8, bug #36679 (project octave):

I'm still interesting in confirming that our thinking about the problem is
correct.  Our assumption is that if the callbacks had enough time to run, then
everything would be okay.

I should have remembered that pause() ties everything up.  But what about
using a busy loop as a delay element for testing?

The following code takes about 0.9 seconds on my computer.

for i=1:1e7, endfor;

You could always use tic/toc and adjust the loop range to get a delay
appropriate for your computer.

If this delay is inserted before line 412 of print.m do the problems go away?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah

(Continue reading)

headers

Michael Godfrey | 1 Jul 2012 21:56

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #9, bug #36679 (project octave):

I tried the for loop, but it did no good.
Then I just put back the 
drawnow();
pause(3);
in the "middle" of the sequence of plots with hold on.
This "fixed" it.
Then I removed the loop (actually I tried loop; pause(3); loop)
and it still worked.

So, this suggests that doing too many plot commands with
hold on and no drawnow(); is important.

Another factor is that this plotting script has a
for fig = 1:3
close all
clear -x fig
hold off        %
figure(fig)     % 
hold on         %
.............
as the start of its outer loop.
The first time through the loop has, as far as I can
remember, always worked.  Sometimes the second time fails,
but most often it is the last time through that fails.

(Continue reading)

headers

Michael Godfrey | 1 Jul 2012 22:56

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #10, bug #36679 (project octave):

Another experiment:

1. I removed all the pause() and drawnow()
   calls in my plotting code.
2. I inserted a drawnow() at the beginning
   of newplot().

newplot appears to be called by all the user
plotting commands, so I thought this would be
a useful place to force drawnow for each plot
command.

Right now it seems to work.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

(Continue reading)

headers

Michael Godfrey | 1 Jul 2012 23:06

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #11, bug #36679 (project octave):

And, as a final test for now, I deleted
the drawnow() in newplot() and the
plot in my code fails again.  No other
changes.

For anyone who understands this code:
doews drawnow in newplot do any harm?
Is this a reasonable fix?

I still feel that the "real" problem has
not been identified.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/

headers

Rik | 2 Jul 2012 18:08

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report. The mailing list is intended as a read-only
notification stream. Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #12, bug #36679 (project octave):

Responding in the order of the original comments:

1) reset () is broken for plots and doesn't actually reset all of the
properties to their defaults. There is already a bug report filed on that.
However, I have never had a problem if I actually use 'close all' to shut down
everything associated with the plotting engine.

2) newplot is called by everything but line(); so there is a possible bypass
route around any drawnow put in newplot()

3) I agree that we still don't have a clear understanding of this bug. If it
is related to callbacks, then putting drawnow() in the appropriate location
should fix it.

4) In newplot there is a call to __request_drawnow__ which sets a variable
that asks Octave to run drawnow the next time the user hits a prompt. This is
only a request, and it is possible that when running from a script several
plots are done in a row before the user is returned to a prompt and drawnow is
executed. What happens if you replace line 58 of newplot.m with a straight
call to drawnow () rather than to __request_drawnow__?

5) You may have done this in previous tests, but what happens if you put a
drawnow () call just ahead of line 412 in print.m? There is already a call to
drawnow () at the head of print.m but it is before a lot of properties have

(Continue reading)

headers

Michael Godfrey | 2 Jul 2012 22:39

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #13, bug #36679 (project octave):

I tried replacing the __request_drawnow__ with
drawnow();
Since the __request is within a case statement
this results in many fewer calls to drawnow
than having the drawnow() unconditionally called.
(In my cae there are 11 calls to newplot() for
each pass through the top loop, but ony one
is a case "replace" which leads to drawnow()
being called.)  However, the good news is that
this fixes the problem.  This also narrows the
scope for searching for the real cause of this 
error.

So, I am definitely in favor of changing line 58 of 
newplot() to drawnow();

I did previously try putting a drawnow() at line
412 of print.m but it did not help.  Also, tried
the usual pause()'s.

So, Rik, could you make the patch to newplot()?
This may not be a complete solution, but it will help
a lot. And, it is separate from other problems with
getting print() to be better behaved.

(Continue reading)

headers

Michael Godfrey | 2 Jul 2012 22:52

[bug #36679] Timing error for multiple plots

Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only
notification stream.  Info posted to this mailing list address won't appear in the tracker database where
it is most useful.

Follow-up Comment #14, bug #36679 (project octave):

Well, I was too optimistic.  I just tried another
similar plotting case, and have found that only
the unconditional drawnow() at the start of newplot()
works correctly.

So, instead of the proposed change to line 58 of
newplot() can we go with the insertion of drawnow();
after line 28?  Does this mean that the __request
at line 58 may still be needed?  Or should it be deleted
or changed to drawnow()?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?36679>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/