octave-bug-tracker
[Top][All Lists]
Advanced

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

[Octave-bug-tracker] [bug #36679] Timing error for multiple plots


From: Michael Godfrey
Subject: [Octave-bug-tracker] [bug #36679] Timing error for multiple plots
Date: Tue, 19 Jun 2012 01:17:11 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0

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.
I am attaching the zip of 2 plots which show the problem.
These 2 plots have the same BoundingBox if produced with a
pause(6) between the sets of plot calls which create them.
If the pause(6) is commented out the second plot has the 
samller BoundingBox as shown by:
[pbdsl3:n1] grep Bound *.ps
vds1.ps:3:%%BoundingBox: 43 219 587 617
vds1.ps:4:%%HiResBoundingBox: 43.600000 219.400000 587.000000 616.900000
vds1.ps:52:%%PageBoundingBox: 0 0 612 792
vds2.ps:3:%%BoundingBox: 41 213 573 569
vds2.ps:4:%%HiResBoundingBox: 41.500000 213.700000 572.500000 568.800000
vds2.ps:52:%%PageBoundingBox: 0 0 612 792

At first I thought that the change in BB size was due to some
environment change between the plots since they allways had the
correct BB if produced separately.  But, I cleaned up the code
and inserted additional cleanup as:
for fig = 1:2
close all
clear -x fig
hold off        %
figure(fig)     % This set of three commands MUST be set for correct BB
hold on         %

This seemed to "work" in some cases but eventually failed
depending on, I think, the complexity of the plots.

I seems odd that only the BB appears to be affected.

If anyone has any tests that they would like me to run
I will try to help.  I tried to put together a simple example,
but -- of course -- that did not fail.

The Linux system is Fedora 17 x86_64.  And, I just recompiled
the devel system with the latest patches including the 
plotyy.m fix.





    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Tue 19 Jun 2012 01:17:10 AM GMT  Name: plots.zip  Size: 44kB   By:
godfrey

<http://savannah.gnu.org/bugs/download.php?file_id=26057>

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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