bugGNU Octave - Bugs: bug #31305, slow contour plot

 
 

bug #31305: slow contour plot

Submitter:  Ben Abbott <bpabbott>
Submitted:  Mon 11 Oct 2010 05:58:39 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  dbateman
Originator Name:  Ben Abbott Open/Closed:  * Closed
Release:  * dev Operating System:  * Mac OS
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 Sep 2011 08:46:34 PM UTC, comment #63: 

sorry for replying late, in the meanwhile you have found out what happened. I applied the patch only to the default branch because I considered that it would break the ABI. I had a short discussion with jwe at that point.

Konstantinos Poulios <logari81>
Tue 06 Sep 2011 08:24:40 PM UTC, comment #62: 
Ben Abbott <bpabbott>
Group Member
Tue 06 Sep 2011 06:49:03 PM UTC, comment #61: 

No, I meant that it is OK  to apply it only to the default branch and NOT apply it to the stable branch.  Not every bug fix has to be done on stable.  I'm not sure this one can be, at least not as it is currently written.  It adds a function, which I think would normally be OK, but it also appears to change the meaning of another significantly.  So I'm not sure that it is completely safe.  Seems better to me that it just be skipped for the stable branch.

John W. Eaton <jwe>
Group administrator
Tue 06 Sep 2011 05:59:32 PM UTC, comment #60: 

John,

You meant "stable" correct?

I'm not aware of any reason not to apply it to stable. But I'm not proficient enough in c++ to judge if there are any binary compatibility problems.

Ben Abbott <bpabbott>
Group Member
Tue 06 Sep 2011 05:50:21 PM UTC, comment #59: 

I think it is OK to apply the patch only to the default branch.  Or is this a serious regression from a previously released version?  Also, does the patch cause any binary compatibility problems?

John W. Eaton <jwe>
Group administrator
Tue 06 Sep 2011 04:32:18 PM UTC, comment #58: 

Rik is correct it has been applied to the default branch. However, it has not been applied to the stable branch.


$ patch -p1 < ~/Downloads/bug31305.changeset
patching file src/graphics.cc
Hunk #2 succeeded at 4694 (offset -106 lines).
Hunk #3 succeeded at 5210 (offset -106 lines).
Hunk #4 succeeded at 5863 (offset -106 lines).
Hunk #5 succeeded at 5873 (offset -106 lines).
patching file src/graphics.h.in
Hunk #3 FAILED at 3418.
Hunk #4 succeeded at 3723 (offset -4 lines).
Hunk #5 succeeded at 3733 (offset -4 lines).
Hunk #6 succeeded at 3769 (offset -4 lines).
1 out of 6 hunks FAILED -- saving rejects to file src/graphics.h.in.rej




Ben Abbott <bpabbott>
Group Member
Tue 06 Sep 2011 04:04:32 PM UTC, comment #57: 

I believe the patch has already been applied.  I downloaded the very last attached file which was bug31305.changeset.  It won't apply cleanly, but that is partly because the actual diffs seem already to be in the code base.  I checked a number of the diffs within the patch and they were all present, but I did not check 100% of them.

Rik <rik5>
Group administrator
Tue 06 Sep 2011 03:02:23 PM UTC, comment #56: 

I think this is an example where we'd hope to have this tested before applying the patch. Perhaps that was a poor choice (we forgot about it).

The patch no longer applies cleanly for me, so it will need to be reproduced.

Ben Abbott <bpabbott>
Group Member
Tue 06 Sep 2011 02:31:38 PM UTC, comment #55: 

I'm confused.  Was the patch applied?  If not, why was this report closed?

John W. Eaton <jwe>
Group administrator
Sun 04 Sep 2011 11:07:00 PM UTC, comment #54: 

This issue is ancient, but seems to have a patch which could be applied

Rik <rik5>
Group administrator
Mon 04 Jul 2011 03:08:11 AM UTC, comment #53: 

Sorry for the delay in replying.
Ok. Now the patch is working.

Running tic; contour(rand(20)); toc; I got:

- Octave 3.4.2 with patch: 4-5 sec
- Octave 3.2.4: 7-9 sec
- Matlab 2010b: 1.5 sec in the first run and less than 1 sec (0.3 - 0.6 sec) in subsequent runs, even changing to rand(30).

Gilberto A S Segundo <gilbertosegundo>
Tue 28 Jun 2011 04:28:49 PM UTC, comment #52: 

Ok. My apologies, I applied the patch to the default branch, but did not try to do so on the stable branch. I've tried that now and encountered the same error as did Gilberto. The patch can be applied if the portion below ...


114 @@ -3413,6 +3418,12 @@
115            calc_ticklabels (ztick, zticklabel, zscale.is ("log"));
116        }
117
118 +    void update_font (void);
119 +    void update_fontname (void) { update_font (); }
120 +    void update_fontsize (void) { update_font (); }
121 +    void update_fontangle (void) { update_font (); }
122 +    void update_fontweight (void) { update_font (); }
123 +
124      void sync_positions (const Matrix& linset);
125      void sync_positions (void);
126
127 @@ -3716,7 +3727,7 @@


Is changed to ...


114 @@ -3413,6 +3418,12 @@
115            calc_ticklabels (ztick, zticklabel, zscale.is ("log"));
116        }
117
118 +    void update_font (void);
119 +    void update_fontname (void) { update_font (); }
120 +    void update_fontsize (void) { update_font (); }
121 +    void update_fontangle (void) { update_font (); }
122 +    void update_fontweight (void) { update_font (); }
123 +
124      void sync_positions (void);
125      void sync_positions (void);
126
127 @@ -3716,7 +3727,7 @@


With this change (line 124 only), the time required for "tic ; contour (rand (20)) ; toc" drops from about 60 sec a bit less than 4 sec.

Ben Abbott <bpabbott>
Group Member
Tue 28 Jun 2011 03:15:41 PM UTC, comment #51: 

Yes. I did not know that the version 3.4.2 had been released :-). Well, I tried to apply the patch in 3.4.2 and I got the same result:

octave-3.4.2$ patch -p1 < bug31305.changeset
patching file src/graphics.cc
Hunk #2 succeeded at 4694 (offset -106 lines).
Hunk #3 succeeded at 5210 (offset -106 lines).
Hunk #4 succeeded at 5863 (offset -106 lines).
Hunk #5 succeeded at 5873 (offset -106 lines).
patching file src/graphics.h.in
Hunk #3 FAILED at 3418.
Hunk #4 succeeded at 3717 (offset -4 lines).
Hunk #5 succeeded at 3727 (offset -4 lines).
Hunk #6 succeeded at 3763 (offset -4 lines).

Gilberto A S Segundo <gilbertosegundo>
Tue 28 Jun 2011 02:56:01 PM UTC, comment #50: 

Is there a reason you're using 3.4.1 rather than 3.4.2?

Ben Abbott <bpabbott>
Group Member
Tue 28 Jun 2011 02:29:54 PM UTC, comment #49: 

Ben Abbot, doing it on octave 3.4.1 I got:

patching file src/graphics.cc
Hunk #2 succeeded at 4694 (offset -106 lines).
Hunk #3 succeeded at 5210 (offset -106 lines).
Hunk #4 succeeded at 5863 (offset -106 lines).
Hunk #5 succeeded at 5873 (offset -106 lines).
patching file src/graphics.h.in
Hunk #3 FAILED at 3418.
Hunk #4 succeeded at 3717 (offset -4 lines).
Hunk #5 succeeded at 3727 (offset -4 lines).
Hunk #6 succeeded at 3763 (offset -4 lines).
1 out of 6 hunks FAILED -- saving rejects to file src/graphics.h.in.rej

In compilation process:

graphics.h: In member function 'void axes::properties::set_fontangle(const octave_value&)':
graphics.h:5858:31: error: 'update_fontangle' was not declared in this scope
graphics.h: In member function 'void axes::properties::set_fontname(const octave_value&)':
graphics.h:5870:30: error: 'update_fontname' was not declared in this scope
graphics.h: In member function 'void axes::properties::set_fontsize(const octave_value&)':
graphics.h:5882:30: error: 'update_fontsize' was not declared in this scope
graphics.h: In member function 'void axes::properties::set_fontweight(const octave_value&)':
graphics.h:5898:32: error: 'update_fontweight' was not declared in this scope

Gilberto A S Segundo <gilbertosegundo>
Tue 28 Jun 2011 01:55:04 PM UTC, comment #48: 

Gilberto, to apply the patch cd to the top of the source directory and ...


patch -p1 < bug31305.changeset
make


Ben Abbott <bpabbott>
Group Member
Tue 28 Jun 2011 01:42:34 PM UTC, comment #47: 

How can I apply this patch? I tried: patch src/graphics.h.in bug31305.changeset and patch src/graphics.cc bug31305.changeset but id did not work.

Can I use it on octave 3.4.1?

Gilberto A S Segundo <gilbertosegundo>
Mon 27 Jun 2011 07:46:50 PM UTC, comment #46: 

Kostas,

Your changeset works for me. Using the FLTK backend on my Mac, the time decreased from 61 sec to 4 sec.

Ben Abbott <bpabbott>
Group Member
Mon 27 Jun 2011 06:15:02 PM UTC, comment #45: 

Is it safe to apply this to stable?  We need to be careful now when adding or removing functions in stable so that we can preserve binary compatibility.  We also need to think about what happens to the library version numbers used by libtool.

Before committing, the changeset also needs some ChangeLog-like info in the commit message.

John W. Eaton <jwe>
Group administrator
Mon 27 Jun 2011 06:03:39 PM UTC, comment #44: 

The attached changeset should fix this performance issue.

I would appreciate if someone able to reproduce the bug could test these changes.

I would also appreciate if someone could run the dump_demos tests and check the results. My free time this period is quite limited.

(file #23576)

Konstantinos Poulios <logari81>
Sat 25 Jun 2011 01:18:42 PM UTC, comment #43: 

Almost all of the time seems to be spent here:


  //FIXME: text_renderer could be cached
  ft_render text_renderer;
  text_renderer.set_font (get ("fontname").string_value (),
                          get ("fontweight").string_value (),
                          get ("fontangle").string_value (),
                          get ("fontsize").double_value ());


in the function axes::properties::get_ticklabel_extents in the file graphics.cc.  So yes, I'd say that caching text_renderer is the right thing to do!

John W. Eaton <jwe>
Group administrator
Fri 24 Jun 2011 11:15:03 PM UTC, comment #42: 

In that changeset, in order to fix some other bug, I had enabled the calculation of label positions even for empty labels. This means that if we test the performance on a plot with nonempty labels the performance with or without this changeset should be similar.

If the contour plot involves some long iteration, maybe a more general solution would be to disable all costly callbacks at the beginning and re-enable them when the contour loops are finished. I am not familiar with the contour code but these are my first thoughts on this issue.

Konstantinos Poulios <logari81>
Fri 24 Jun 2011 08:37:20 PM UTC, comment #41: 

I haven't had a chance to try to understand why this problem is happening, but I have narrowed it down to this changeset:


changeset:   12502:13640f7f40bb
user:        Konstantinos Poulios <logari81@googlemail.com>
date:        Sun Mar 06 16:54:39 2011 +0100
summary:     improve calculation of axes tightinset for empty axes labels/title


so I'm copying Kanstantinos on this bug report.

John W. Eaton <jwe>
Group administrator
Thu 23 Jun 2011 04:21:52 PM UTC, comment #40: 

I see similarly bad results going from 3.4.0 to 3.4.1

I did a little digging and found that the call to _go_patch_ in plot/private/__contour__.m is now much slower than it was in 3.4.0.

I don't see anything obvious (there were no changes to _go_patch_ itself, as far as I can tell) so probably the best way to find the cause would be to bisect between the current sources and the 3.4.0 release point in the mercurial archive.


John W. Eaton <jwe>
Group administrator
Thu 23 Jun 2011 02:38:27 PM UTC, comment #39: 

Hello. I'm using Debian Linux, 32 bits.
I used octave 3.2.4 from Debian repository and octave 3.4.1 compiled by myself. In both the contour function is very slow compared with matlab 2010b (7.11.0) for linux.

Running the commands:

tic;
contour(rand(20))
toc;

I got:
- octave 3.2.4: Elapsed time is 7.66252 seconds
- octave 3.4.1: Elapsed time is 25.7015 seconds
- matlab 2010b: Elapsed time is 0.963400 seconds


Gilberto A S Segundo <gilbertosegundo>
Tue 02 Nov 2010 04:12:47 AM UTC, comment #38: 

It occurred to me that changing zlim to [0.1 1] should hide the contour since it is at z = 0.

The disappearing ticklabels I see for zlim = [-1, 1] reappear if I change the figure's position property. On MacOS 10.6 with FLTK 1.1.10 it is necessary to change the position property to render other aspects of the plot correctly also.

Thus, I suspect this is an isolated problem, but have opened a ticket indicating that.

https://savannah.gnu.org/bugs/index.php?31518

Ben Abbott <bpabbott>
Group Member
Tue 02 Nov 2010 03:53:02 AM UTC, comment #37: 

I don't know why zlim has an effect, but I think it is independent of this bug which I agree has been fixed.

I'll open another ticket.

Ben Abbott <bpabbott>
Group Member
Mon 01 Nov 2010 11:52:08 PM UTC, comment #36: 

Ben, with your "axis tight" fix, I now have both contour and contourf working correctly with the FLTK backend. So I decide to push this patch as you suggested. See the changeset

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

With this patch contour(rand(10)) is four times faster than it was previously on my machine and the hggroup::adopt function now has O(1) behavior rather than O(N) (where N is the number of contours already plotted). This being called when every contour is added to the contourgroup, this means that the speed should be even faster with larger contourgroups like the original authors case and that _contour_ should have O(N) speed rather than the O(N^2) it had previously.

However I don't understand the need for zlim to be set. The contours are plotted in 2D and so zlim should be ignored by the backends. Can you please explain? Though I suggest we close this bug report as we've addressed the original issue (and a few others in passing), so please start a new bug report.

D.

David Bateman <dbateman>
Group Member
Mon 01 Nov 2010 04:51:13 PM UTC, comment #35: 

David, with the changeset I pushed to fix "axis tight", and with your patch (patch.contour4) applied, the behavior of contour/contourf is much improved.

I recommend you push your changeset. For compatibility with Matlab please set zlim for the axes to [-1 1].

There may be some additional problems, but I expect they'll be easier to track down after your changeset is pushed.

Ben Abbott <bpabbott>
Group Member
Mon 01 Nov 2010 11:10:31 AM UTC, comment #34: 

I pushed a small changeset to fix "axis tight" so that it doesn't include the hggroup's zdata.

http://hg.savannah.gnu.org/hgweb/octave/rev/2114867f2a50

The reason is that contour plots store the patches cdata in the hggroup's zdata property.

To be entirely consistent with Matlab, contour/contourf should set zlim to [-1, 1].


Ben Abbott <bpabbott>
Group Member
Sat 30 Oct 2010 05:11:55 PM UTC, comment #33: 

In fact _patch_ already assumes a direct relationship between cdata and facevertexcdata. But the crash in the fltk backend made me doubt that this was correct. However, point 2) still holds as in the draw_patch method in gl-render.cc  if edgecolor was rgb then ec_mode was zero but facecolor was none and fc_mode was 2. This was combined with cdata being set to a default value and not being fed back to facevertexcdata data and thus the crash. My changeset from last night fixes this.

D.

David Bateman <dbateman>
Group Member
Sat 30 Oct 2010 02:04:40 PM UTC, comment #32: 

David,

AFAIK facevertexcdata is derived from cdata, and according to is just cdata re-arranged in another way. It does not depend on edgecolor or facecolor; however facevertexcdata is only used when edgecolor or facecolor have the value flat or interp.

So to comment your points:
1) facevertexcdata should not be empty when it's needed (edgecolor or facecolor are set to flat or interp)

3) in the 3 cases, facevertexcdata will be [1 0 0], as Ben confirmed; this is normal as cdata is the same in the 3 cases and corresponds to the RGB color of the single face of the patch

Michael Goffioul <goffioul>
Sat 30 Oct 2010 01:56:37 PM UTC, comment #31: 

Just occurred to me to check how Matlab set's zlim.

After a contour plot, Matlab set's "zlim" to [-1 1].

Ben Abbott <bpabbott>
Group Member
Sat 30 Oct 2010 01:55:54 AM UTC, comment #30: 

again with tip 11168 and patch.contour4 applied I see some addition problems (which may be unrelated to his problem) ...

contour (rand (20)) # no contour, and tickmarks/labels are ok
pause
zlim ([0 1])  # gives the expect result.
pause
zlim ([-1 1]) # contour is ok, but no tickmarks/labels.
pause
zlim ([.1 1]) # no contour, but tickmarks/labels are ok.

Ben Abbott <bpabbott>
Group Member
Sat 30 Oct 2010 01:46:35 AM UTC, comment #29: 

Forgot to follow up on the printing. With the tip at 11168 and David's patch.contour4 patch applied, I'm able to print the contours as well.

Also, while "axis tight" results in a blank window with axis limits [1 20 1 20], using "xlim([1 20]); ylim([1 20])" gives the proper result.

I experimented with how axis() sets the limits for the "tight" option. If I modify axis:__do_tight_option__ as ...

function _do_tight_option_ (ca)
set (ca,
     "xlim", _get_tight_lims_ (ca, "x"),
     "ylim", _get_tight_lims_ (ca, "y"))
# set (ca,
#      "xlim", _get_tight_lims_ (ca, "x"),
#      "ylim", _get_tight_lims_ (ca, "y"),
#      "zlim", _get_tight_lims_ (ca, "z"));
endfunction

Then "contour(peaks(20))" gives the correct result.

Changing to ...

function _do_tight_option_ (ca)
zlim_orig = get (ca, "zlim")
zlim_tight = _get_tight_lims_ (ca, "z")
set (ca,
     "xlim", _get_tight_lims_ (ca, "x"),
     "ylim", _get_tight_lims_ (ca, "y"),
     "zlim", _get_tight_lims_ (ca, "z"))
endfunction

Then when I call "contour(rand(20))", I see a blank axis box and the debug lines give ...

    zlim_orig =   0   1
    zlim_tight =   0.0047762   0.9994125

If I follow up with "zlim([0 1])", then I see the correct result.

Ben Abbott <bpabbott>
Group Member
Sat 30 Oct 2010 01:01:30 AM UTC, comment #28: 

With the tip at 11168 and David's patch.contour4 patch applied, contour(rand(20)) produces a blank axes, and contourf(peaks(20)) works correctly. If I comment out 'axis ("tight")' in _contour_.m then contour(peaks(20)) produces the correct result but without proper axis limits.

Ben Abbott <bpabbott>
Group Member
Sat 30 Oct 2010 12:26:05 AM UTC, comment #27: 

After David's changeset (11168) and without patch.contour4, I get the proper patches result for ...

    contour (rand (20))

and

    contourf (rand (20))

However, the axis limits are not correct. If I do a "axis tight", the "contour" patches are no longer visible but those from "contourf" are ok. I tried to print the result, but ...

print -dpdfwrite contourf_11168.pdf
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete

The back-trace is ...

(gdb) bt
#0  0x1c478054 in gleClipLinesPlane ()
#1  0x1c47842c in gleFeedbackLineLoopFunc ()
#2  0x1c389bd8 in glEnd_Exec ()
#3  0x93d0f557 in glEnd ()
#4  0x0016ac18 in opengl_renderer::patch_tesselator::end (this=0xbfff6f4c) at gl-render.cc:429
#5  0x0016a858 in opengl_tesselator::tess_end (t=0xbfff6f4c) at gl-render.cc:307
#6  0x9547d0b3 in __gl_renderBoundary ()
#7  0x954802ba in gluTessEndPolygon ()
#8  0x00165e7d in opengl_renderer::draw_patch (this=0x16f2f970, props=@0x330ae08) at gl-render.cc:256
#9  0x001456f7 in opengl_renderer::draw (this=0x16f2f970, go=@0xbfff730c) at gl-render.cc:550
#10 0x0016e5df in glps_renderer::draw (this=0x16f2f970, go=@0xbfff730c) at gl2ps-renderer.cc:88
#11 0x0016bce2 in opengl_renderer::draw (this=0x16f2f970, h=@0xbfff7358) at gl-render.h:56
#12 0x0016abf8 in opengl_renderer::draw (this=0x16f2f970, hlist=@0xbfff7390) at gl-render.h:69
#13 0x001445a5 in opengl_renderer::draw_hggroup (this=0x16f2f970, props=@0x3281808) at gl-render.cc:2747
#14 0x0014580c in opengl_renderer::draw (this=0x16f2f970, go=@0xbfff8560) at gl-render.cc:552
#15 0x0016e5df in glps_renderer::draw (this=0x16f2f970, go=@0xbfff8560) at gl2ps-renderer.cc:88
#16 0x0016205e in opengl_renderer::draw_axes (this=0x16f2f970, props=@0x325f408) at gl-render.cc:1742
#17 0x001453b8 in opengl_renderer::draw (this=0x16f2f970, go=@0xbfff8b9c) at gl-render.cc:544
#18 0x0016e5df in glps_renderer::draw (this=0x16f2f970, go=@0xbfff8b9c) at gl2ps-renderer.cc:88
#19 0x0016bce2 in opengl_renderer::draw (this=0x16f2f970, h=@0xbfff8be8) at gl-render.h:56
#20 0x0016abf8 in opengl_renderer::draw (this=0x16f2f970, hlist=@0xbfff8c4c) at gl-render.h:69
#21 0x00147821 in opengl_renderer::draw_figure (this=0x16f2f970, props=@0x325b208) at gl-render.cc:598
#22 0x001452a3 in opengl_renderer::draw (this=0x16f2f970, go=@0xbfff8e0c) at gl-render.cc:542
#23 0x0016e5ab in glps_renderer::draw (this=0x16f2f970, go=@0xbfff8e0c) at gl2ps-renderer.cc:79
#24 0x0016bce2 in opengl_renderer::draw (this=0x16f2f970, h=@0xbfff8ea8) at gl-render.h:56
#25 0x17810749 in OpenGL_fltk::draw (this=0x1912eee0) at DLD-FUNCTIONS/fltk_backend.cc:155
#26 0x027d0058 in Fl_Gl_Window::flush ()
#27 0x027edd0e in Fl_X::flush ()
#28 0x027ede5d in Fl::flush ()
#29 0x027eeca2 in Fl::wait ()
#30 0x1780919b in plot_window::print () at /Users/bpabbott/Development/mercurial/local_clone/src/DLD-FUNCTIONS/fltk_backend.cc:753
#31 0x1780919b in figure_manager::do_print () at /Users/bpabbott/Development/mercurial/local_clone/src/DLD-FUNCTIONS/fltk_backend.cc:1622
#32 0x1780919b in figure_manager::print () at /Users/bpabbott/Development/mercurial/local_clone/src/DLD-FUNCTIONS/fltk_backend.cc:1481
#33 0x1780919b in fltk_backend::print_figure (this=0x2d57400, go=@0xbfff92c8, term=@0xbfff92f8, file=@0xbfff92f4) at DLD-FUNCTIONS/fltk_backend.cc:1847
#34 0x00205c30 in graphics_backend::print_figure () at /Users/bpabbott/Development/mercurial/local_clone/src/graphics.h:6540
#35 0x00205c30 in Fdrawnow (args=@0x1f48b5e8) at graphics.cc:6540
#36 0x004a45e6 in octave_builtin::do_multi_index_op (this=0x3063b40, nargout=0, args=@0x1f48b5e8, lvalue_list=0x0) at ov-builtin.cc:129
#37 0x004a3414 in octave_builtin::subsref (this=0x3063b40, type=@0xbfff97f4, idx=@0xbfff97b0, nargout=0, lvalue_list=0x0) at ov-builtin.cc:64
#38 0x004a3d0c in octave_builtin::subsref (this=0x3063b40, type=@0xbfff97f4, idx=@0xbfff97b0, nargout=0) at ov-builtin.cc:47
#39 0x005c8704 in octave_value::subsref (this=0xbfff97d0, type=@0xbfff97f4, idx=@0xbfff97b0, nargout=0) at ov.cc:1202
#40 0x005c8779 in octave_value::subsref (this=0xbfff97d0, type=@0xbfff97f4, idx=@0xbfff97b0, nargout=0, lvalue_list=0x0) at ov.cc:1213
#41 0x006a5445 in tree_index_expression::rvalue (this=0x1f47c030, nargout=0, lvalue_list=0x0) at pt-idx.cc:408
#42 0x006a570c in tree_index_expression::rvalue (this=0x1f47c030, nargout=0) at pt-idx.cc:278
#43 0x006a3f5e in tree_index_expression::rvalue1 (this=0x1f47c030, nargout=0) at pt-idx.cc:419
#44 0x006987ac in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x1f47c100) at pt-eval.cc:729
#45 0x006cb3df in tree_statement::accept (this=0x1f47c100, tw=@0xe66760) at pt-stmt.cc:152
#46 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x1f47c150) at pt-eval.cc:765
#47 0x00084681 in tree_statement_list::accept (this=0x1f47c150, tw=@0xe66760) at pt-stmt.cc:216
#48 0x00694d3b in tree_evaluator::visit_unwind_protect_command (this=0xe66760, cmd=@0x1f47c170) at pt-eval.cc:996
#49 0x0069bed9 in tree_unwind_protect_command::accept (this=0x1f47c170, tw=@0xe66760) at pt-except.cc:100
#50 0x006986fc in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x1f47c650) at pt-eval.cc:700
#51 0x006cb3df in tree_statement::accept (this=0x1f47c650, tw=@0xe66760) at pt-stmt.cc:152
#52 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x1f47b0d0) at pt-eval.cc:765
#53 0x00084681 in tree_statement_list::accept (this=0x1f47b0d0, tw=@0xe66760) at pt-stmt.cc:216
#54 0x00699b07 in octave_quit [inlined] () at /Users/bpabbott/Development/mercurial/local_clone/libcruft/misc/quit.h:359
#55 0x00699b07 in quit_loop_now [inlined] () at /Users/bpabbott/Development/mercurial/local_clone/src/pt-eval.cc:265
#56 0x00699b07 in tree_evaluator::visit_simple_for_command (this=0xe66760, cmd=@0x1f47c620) at pt-eval.cc:359
#57 0x006a9cf4 in tree_simple_for_command::accept (this=0x1f47c620, tw=@0xe66760) at pt-loop.cc:116
#58 0x006986fc in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x1f47a6c0) at pt-eval.cc:700
#59 0x006cb3df in tree_statement::accept (this=0x1f47a6c0, tw=@0xe66760) at pt-stmt.cc:152
#60 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x1f462bb0) at pt-eval.cc:765
#61 0x00084681 in tree_statement_list::accept (this=0x1f462bb0, tw=@0xe66760) at pt-stmt.cc:216
#62 0x005b9365 in octave_user_function::do_multi_index_op (this=0x30682d8, nargout=1, args=@0x1f40a1e8, lvalue_list=0x0) at ov-usr-fcn.cc:450
#63 0x005b4945 in octave_user_function::subsref (this=0x30682d8, type=@0xbfffa2a4, idx=@0xbfffa260, nargout=1, lvalue_list=0x0) at ov-usr-fcn.cc:303
#64 0x005b579c in octave_user_function::subsref (this=0x30682d8, type=@0xbfffa2a4, idx=@0xbfffa260, nargout=1) at ov-usr-fcn.cc:286
#65 0x005b991f in octave_user_function::subsref (this=0x30682d8, type=@0xbfffa2a4, idx=@0xbfffa260) at ov-usr-fcn.h:263
#66 0x005c83b4 in octave_value::subsref (this=0xbfffa280, type=@0xbfffa2a4, idx=@0xbfffa260, nargout=1) at ov.cc:1200
#67 0x005c8779 in octave_value::subsref (this=0xbfffa280, type=@0xbfffa2a4, idx=@0xbfffa260, nargout=1, lvalue_list=0x0) at ov.cc:1213
#68 0x006a5445 in tree_index_expression::rvalue (this=0x19192b30, nargout=1, lvalue_list=0x0) at pt-idx.cc:408
#69 0x006a570c in tree_index_expression::rvalue (this=0x19192b30, nargout=1) at pt-idx.cc:278
#70 0x006a3f5e in tree_index_expression::rvalue1 (this=0x19192b30, nargout=1) at pt-idx.cc:419
#71 0x0068499e in tree_simple_assignment::rvalue1 (this=0x1f0cd6c0) at pt-assign.cc:206
#72 0x006987ac in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x4ad3f90) at pt-eval.cc:729
#73 0x006cb3df in tree_statement::accept (this=0x4ad3f90, tw=@0xe66760) at pt-stmt.cc:152
#74 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x4ad3fa0) at pt-eval.cc:765
#75 0x00084681 in tree_statement_list::accept (this=0x4ad3fa0, tw=@0xe66760) at pt-stmt.cc:216
#76 0x006985c1 in tree_evaluator::visit_switch_command (this=0xe66760, cmd=@0x4a84e50) at pt-eval.cc:847
#77 0x006ca12c in tree_switch_command::accept (this=0x4a84e50, tw=@0xe66760) at pt-select.cc:223
#78 0x006986fc in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x4a8fc60) at pt-eval.cc:700
#79 0x006cb3df in tree_statement::accept (this=0x4a8fc60, tw=@0xe66760) at pt-stmt.cc:152
#80 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x2e4a9c0) at pt-eval.cc:765
#81 0x00084681 in tree_statement_list::accept (this=0x2e4a9c0, tw=@0xe66760) at pt-stmt.cc:216
#82 0x00694d3b in tree_evaluator::visit_unwind_protect_command (this=0xe66760, cmd=@0x1f0f3740) at pt-eval.cc:996
#83 0x0069bed9 in tree_unwind_protect_command::accept (this=0x1f0f3740, tw=@0xe66760) at pt-except.cc:100
#84 0x006986fc in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x1f0f2fb0) at pt-eval.cc:700
#85 0x006cb3df in tree_statement::accept (this=0x1f0f2fb0, tw=@0xe66760) at pt-stmt.cc:152
#86 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x2e472e0) at pt-eval.cc:765
#87 0x00084681 in tree_statement_list::accept (this=0x2e472e0, tw=@0xe66760) at pt-stmt.cc:216
#88 0x005b9365 in octave_user_function::do_multi_index_op (this=0x3067aa4, nargout=0, args=@0x1f414138, lvalue_list=0x0) at ov-usr-fcn.cc:450
#89 0x005b4945 in octave_user_function::subsref (this=0x3067aa4, type=@0xbffface4, idx=@0xbfffaca0, nargout=0, lvalue_list=0x0) at ov-usr-fcn.cc:303
#90 0x005b579c in octave_user_function::subsref (this=0x3067aa4, type=@0xbffface4, idx=@0xbfffaca0, nargout=0) at ov-usr-fcn.cc:286
#91 0x005c8704 in octave_value::subsref (this=0xbfffacc0, type=@0xbffface4, idx=@0xbfffaca0, nargout=0) at ov.cc:1202
#92 0x005c8779 in octave_value::subsref (this=0xbfffacc0, type=@0xbffface4, idx=@0xbfffaca0, nargout=0, lvalue_list=0x0) at ov.cc:1213
#93 0x006a5445 in tree_index_expression::rvalue (this=0x2e46c80, nargout=0, lvalue_list=0x0) at pt-idx.cc:408
#94 0x006a570c in tree_index_expression::rvalue (this=0x2e46c80, nargout=0) at pt-idx.cc:278
#95 0x006a3f5e in tree_index_expression::rvalue1 (this=0x2e46c80, nargout=0) at pt-idx.cc:419
#96 0x006987ac in tree_evaluator::visit_statement (this=0xe66760, stmt=@0x2e46d20) at pt-eval.cc:729
#97 0x006cb3df in tree_statement::accept (this=0x2e46d20, tw=@0xe66760) at pt-stmt.cc:152
#98 0x006955ab in tree_evaluator::visit_statement_list (this=0xe66760, lst=@0x2e46d80) at pt-eval.cc:765
#99 0x00084681 in tree_statement_list::accept (this=0x2e46d80, tw=@0xe66760) at pt-stmt.cc:216
#100 0x00424a81 in main_loop () at toplev.cc:570
#101 0x003c04ea in octave_main (argc=6, argv=0xbfffb040, embedded=0) at octave.cc:894
#102 0x00001f80 in main (argc=6, argv=0xbfffb040) at main.c:35
(gdb)

I have errands to run. If someone doesn't get to it first I'll test patch.contour4, with tip 11168, when I return.

Ben Abbott <bpabbott>
Group Member
Fri 29 Oct 2010 11:49:11 PM UTC, comment #26: 

For each patch the facevertexdata = [1 0 0]

The facecolor and edge color are exactly as specified. A pdf is attached (davids_patches.pdf).

(file #21866)

Ben Abbott <bpabbott>
Group Member
Fri 29 Oct 2010 06:05:58 PM UTC, comment #25: 

Can we keep this discussion on the bug-tracker.

I see several factors contributing to this crash. If any one of them was fixed we wouldn't have the crash.

1) In the get_color_data method if the facevertexdata is empty then we shouldn't call convert_cdata. So something like

octave_value
patch::properties::get_color_data (void) const
{
  octave_value fvc = get_facevertexcdata();
  if (fvc.isempty ())
    return Matrix ();
  else
    return convert_cdata (*this, fvc, cdatamapping_is ("scaled"), 2);
}

should be used

2) If facecolor or edgecolor is "none" in gl-render.cc(void
opengl_renderer::draw_patch (const patch::properties &props)) and the equivalent function for surfaces, then the fc_mode and ec_mode values should be "0" as these colors shouldn't play a part in the color calculation.

3) In _patch_(setvertexdata) It's not clear to me now whether the value of facevertexdata should be derived from cdata, edgecolor or facecolor and what are the rules to calculate this derived value. If you can run

h = patch([0, 1, 1], [0, 0, 1], 'edgecolor', 'none', 'cdata', [1,0,0], 'facecolor',[0,1,0])
get(h,'facevertexcdata')

h = patch([0, 0, 1], [0, 1, 1], 'edgecolor', [0,0,1], 'cdata', [1,0,0], 'facecolor','none')
get(h,'facevertexcdata')

h = patch([0, 0.5, 1], [0, 1, 0], 'edgecolor', [0,0,1], 'cdata', [1,0,0], 'facecolor',[0,1,0])
get(h,'facevertexcdata')

in matlab and see what it gives (including the face and edge colors used), I'll fix these three issues and I'm certain this bug will go away.

D.



David Bateman <dbateman>
Group Member
Fri 29 Oct 2010 07:29:27 AM UTC, comment #24: 

My testing came to an abrupt end. I was experimenting plotting patches and found a simple combination that crashes Octave. There's a new bug in the tracker. The following crashes Octave for me

patch ([0 1 1 0], [0 0 1 1], "b", "facecolor", "none")


Ben Abbott <bpabbott>
Group Member
Fri 29 Oct 2010 06:49:23 AM UTC, comment #23: 

After further experimenting, what I found is that changing facecolor from "flat" to [1, 1, 1] produces an image for contour(rand(20)) that looks correct.

However, this never works twice in a row.

>> clear all
>> contour (rand (20))


produces the an image that looks correct

>> clear all
>> contour (rand (20))
>> contour (rand (20))


The second plot is not blank

>> clear all
>> contour (rand (20))
>> clear all
>> contour (rand (20))


The second plot looks correct.

I'll do some more tests.

Ben Abbott <bpabbott>
Group Member
Fri 29 Oct 2010 03:28:03 AM UTC, comment #22: 

Please ignore my last comment. I just built with no patches applied and "contour(rand(20))" works fine, but "contourf(rand(20))" resulted in ...

panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete

With contour_fix2.patch the fltk versions of both contour(peaks(20)) and contourf(peaks(20)) each produce empty axes.

With patch.contour4 contour(peaks(20)) is also blank, but contourf(peaks(20)) works properly.



Ben Abbott <bpabbott>
Group Member
Fri 29 Oct 2010 01:50:13 AM UTC, comment #21: 

If I remember correctly, this was working when the contour_fix2.patch was applied, but now with contour_fix.patch.

Diffing the two I get ...

$ diff contour_fix.patch contour_fix2.patch
4c4,13
< @@ -232,138 +232,111 @@
---

> @@ -211,6 +211,8 @@

>    add_patch_children (hg);

> +  axis tight
> +
>    if (!isempty (opts))
>      set (hg, opts{:});
>    endif
> @@ -232,138 +234,115 @@

82,88d90
< -            lvl_bel_idx = tmp(1);
< -            ## Set color of patches found.
< -            cont_lev(ma_idx) = cont_lev(lvl_bel_idx);
< -          else
< -            ## Set lowest level contour to NaN.
< -            cont_lev(ma_idx) = NaN;
< -          endif
122,124c124,131
< +          lvl_bel_idx = tmp(1);
< +          ## Set color of patches found.
< +          cont_lev(ma_idx) = cont_lev(lvl_bel_idx);
---

> +          if (! isempty (tmp))
>              lvl_bel_idx = tmp(1);
>              ## Set color of patches found.
>              cont_lev(ma_idx) = cont_lev(lvl_bel_idx);
>            else
> -            ## Set lowest level contour to NaN.
>              cont_lev(ma_idx) = NaN;
>            endif


I'm a bit embarrassed to admit it, but I don't understand why this worked. I came about this change by experimenting.

In any event, perhaps it gives some hints?

Ben Abbott <bpabbott>
Group Member
Thu 28 Oct 2010 10:29:35 PM UTC, comment #20: 

Weird contourf(peaks()) works but contourf(rand(10)) doesn't. For the GL code I copied a block of Micheal's code to treat the unclosed patches that weren't treated in his code. However, for contourf, all of the patches are closed, so this part of the code I added isn't even used.

I had a look at this problem but I don't know this code well enough to try and fix it. I added Micheal cced to this message and hope he can help.. Micheal could you apply the last of my patches in this bug report and try

backend fltk
contourf(peaks()) ## Works
pause(5)
contourf(rand(10)) ## Doesn't work

with the tip of the repository

David

David Bateman <dbateman>
Group Member
Thu 28 Oct 2010 04:24:28 AM UTC, comment #19: 

David, your help is much appreciated. I'm only knowledgeable enough to be dangerous.

I've applied your patch (after pulling you changeset). I ran the demos for contour and contourf with no problems.  I also tried "contour(rand(20))" and "contourf(rand(20))". the former works for both the gnuplot and fltk backends. The latter works for gnuplot but produces a blank plot for the fltk backend.

Ben Abbott <bpabbott>
Group Member
Thu 28 Oct 2010 01:11:11 AM UTC, comment #18: 

Shai, Ben

I don't think the code in _contour_ should be consolidated. The main reason its separate is that the filled contours need to be sorted by their size so that they are correctly layered and all visible, whereas as the unfilled contours don't. The process of calculating the areas of the contours is expensive and will slow up the contour function even further.

Your patch doesn't address the underlying issue that the gnuplot backend used {x,y,z,c}data properties to draw the patches whereas the fltk one appears to rely on the faces, vertices and facevertexcdata properties instead. Incorrect updating between these values seems to be the cause of the black contours. The changeset

http://hg.savannah.gnu.org/hgweb/octave/rev/131d56b6d9a3

I just pushed should address that part. The final issue with the FLTK backend is that it doesn't respect unclosed contours, and in fact just drops them. Your patch artificially closed these contours and with gnuplot something like contour(rand(10)) had undesired line that represented the missing parts of the contour lines. The render itself needs to be modified to fix this.

As for the speed of the contour function I propose the following changes

1) Make _contour_ itself handle the updating between {x,y,z,c}data and vertices, faces, facevertexcdata properties, so that we can use _go_patch_ rather than the patch function. This means that the listener functions for each patch are not setup, and only a single set of listeners to the contourgroup are installed. This gives a significant improvement in the speed

2) The code in

graphics.cc(static octave_value make_graphics_object (const std::string&, const octave_value_list&))

is then the major source of the slow speed of the contour function. There are two major contributors to the speed of this function

2a) The adopt method of the hggroup that is called from make_graphics_object, caused a calculation of the axis_limits of all its child objects. However the adopt method only needs to compare its current value with its old value. Making this change made the adoption of children to hggroups very low cost regardless of the number of children

2b) The xset call in make_graphics_object function essential uses the rest of the time in the creation of a patch object. The reasiun is that the set methods of the graphics_object classes can call an update method that in certain cases is slow. In particular this is slow for {x,y,z,c}data in that the limits are calculated. Its difficult to get rid of this calculation, but what can be improved is that the call to xisnan in the get_array_limits template function can be removed as comparisons with NaN are always false. This will give a slight improvement.

I can't see any other obvious means to speed up the contour function, But these changes give me a roughly 4x speed up.

I attach a patch with the code that I consider works pretty well. If it works for both of you I'll add a changelog and push it.

D.

(file #21847)

David Bateman <dbateman>
Group Member
Sat 23 Oct 2010 11:40:50 AM UTC, comment #17: 

I'm working on the slow contour part of this bug report addressing two issues. Firstly using _patch_ rather than patch in _contour_ means that the callbacks aren't setup and that doubles the speed. The second improvement is that in the adopt function of the hggroups the axes limits are recalculated when each contour is added. Do the calcukation once at the last contour doubles rhe speed again. I'm still looking for other means to speed this ip

D.

David Bateman <dbateman>
Group Member
Sat 23 Oct 2010 10:31:17 AM UTC, comment #16: 

The color looks great for smooth surfaces. However ...

octave:1> contour (rand (5))
error: add_patch_children: A(I): index out of bounds; value 1 out of bound 0
error: called from:
error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/plot/private/__contour__.m at line 292, column 23
error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/plot/private/__contour__.m at line 212, column 3
error:   /Users/bpabbott/Development/mercurial/local_clone/scripts/plot/contour.m at line 62, column 19

I can't claim to understand how this function works, but I made a feeble attempt to fix it. The result works for me.

I also added "axis tight". I think this is the right thing to do. Matlab's contours have both xlimmode and ylimmode set to "manual" after a contour is rendered.


(file #21762)

Ben Abbott <bpabbott>
Group Member
Sat 23 Oct 2010 08:30:41 AM UTC, comment #15: 

I think that for historical reasons filled contours and outline contours were treated differently in _contour_.m

I consolidated it, and now all contours are drawn in the same way. This might be a little inefficient for outline contours only -- I'm not sure since I don't understand the filled contour code.

Anyway, my patch will probably not help in the original complaint -- it won't make contours faster, but it will make contour lines be in the right color

Shai

(file #21761)

Shai Ayal <shaiay>
Wed 13 Oct 2010 12:39:42 AM UTC, comment #14: 

I'm unfamiliar with how ML creates contours from patches. However, it is simple enough to provide more.

>> contour (peaks(10))
>> hp = findobj (gca, 'type', 'patch');
>> props = get (hp);
>> save -v6 props.mat props


I've attached props.mat

(file #21667)

Ben Abbott <bpabbott>
Group Member
Wed 13 Oct 2010 12:22:55 AM UTC, comment #13: 

Matlab gives an error for your example.

However, if the equivalent is used ...

patch ([0.2, 0.8, 0.5], [0.2, 0.2 , 0.8] , [0.5, 0.5, 0.5], 'facecolor', 'none', 'edgecolor', 'flat');

... I get warnings ...

Warning: Patch FaceVertexCData length (0) must equal Vertices length (3) for flat EdgeColor
Warning: Patch FaceVertexCData length (0) must equal Vertices length (3) for flat EdgeColor

If I try ...

patch ([0.2, 0.8, 0.5], [0.2, 0.2 , 0.8] , [0.5, 0.5, 0.5], 'facecolor', 'none');

... then I get a triangle.



Ben Abbott <bpabbott>
Group Member
Tue 12 Oct 2010 07:14:02 PM UTC, comment #12: 

contour uses patches to draw the contour lines. The patch cdata is supposed to determine the color of the edges, but it does not work in fltk.
The follwing code displays an empty triangle with black edges on fltk, although the edges should be blue according to the default colormap:

clf ()
axis ([0 1 0 1])
patch ([0.5, 0.6, 0.5],[0.5, 0.5 , 0.6] , "facecolor", "none", "edgecolor", "flat", "cdata" , 0.5)

Can you confirm matlabs behavior for his code?

Shai

Shai Ayal <shaiay>
Tue 12 Oct 2010 06:08:18 PM UTC, comment #11: 

Shai, the cotour lines should be color. You should get the proper result using the gnuplot backend.

Ben Abbott <bpabbott>
Group Member
Tue 12 Oct 2010 05:17:28 PM UTC, comment #10: 

Hi

running your example on the tip:

backend fltk
tic (); contour (rand (20)); toc ()
Elapsed time is 2.8145 seconds.

and I get black contour lines in the figure window. Is this not the expected result?

Shai

Shai Ayal <shaiay>
Mon 11 Oct 2010 10:47:38 PM UTC, comment #9: 

The fltk backend wasn't working correctly for me before. All I got was black contour lines. It may be that this change hasn't done any real damage there. I've cc'd Shai for his thoughts.

Ben Abbott <bpabbott>
Group Member
Mon 11 Oct 2010 10:43:47 PM UTC, comment #8: 

I don't really see how it can be vectorized as the length of each contour is different. However as it appears that matlab doesn't use this optimization, is it the right thing to do? Will it cause compatibility problems? Who's going to fix the issue this uncovered in the fltk backend?

I suppose the real issue is that the

graphics.cc(static octave_value make_graphics_object (const std::string&, const octave_value_list&))

function is slow for some reason. Maybe we should be try to speed that up rather than trying to work around the slow up in this function.

D.

David Bateman <dbateman>
Group Member
Mon 11 Oct 2010 10:20:22 PM UTC, comment #7: 

Using gnuplot, I agree the biggest slow down is with the pipe.

Regarding additional speed-up, can the generation of patches be vectorized?

Ben Abbott <bpabbott>
Group Member
Mon 11 Oct 2010 10:14:57 PM UTC, comment #6: 

The gnuplot prompt is always delayed when there is lots of data plotted. Is it delayed more they usual?

87? Ok, then matlab is not doing this type of optimization. Is there some other way of speed this up that we're missing?

D.

David Bateman <dbateman>
Group Member
Mon 11 Oct 2010 10:12:22 PM UTC, comment #5: 

Are you using the fltk backend? I see the same thing with fltk, but it works with gnuplot. I have no idea why yet. BTW I had a bug in the previous version that cause contours not to be closed, fix attached.

D.

(file #21660)

David Bateman <dbateman>
Group Member
Mon 11 Oct 2010 10:08:56 PM UTC, comment #4: 

Correction. The gnuplot backend produced the plot much faster as measured by ...

tic (); contour (rand (20)); tic ()

However, the return of the command prompt is significantly delayed.

Using the fltk backend, the figure window is empty.



Ben Abbott <bpabbott>
Group Member
Mon 11 Oct 2010 09:59:02 PM UTC, comment #3: 

Matlab also gives 87.

With the patch applied, I do see a significant increase in speed as well. Unfortunately, my plot window comes up empty.




Ben Abbott <bpabbott>
Group Member
Mon 11 Oct 2010 09:41:23 PM UTC, comment #2: 

What I mean by doing something like what is done in the scatter functions is like the attached patch. It seems to speed up the contour function significantly. My contour(rand(15)) call is now down to 0.5sec.

However, I still have no idea what matlab does to get this code to be fast. Also as the patches in the contourf function have to be sorted by their size to get them to be drawn correctly it can't be applied to the contourf code in _contour_.m

D.

(file #21659)

David Bateman <dbateman>
Group Member
Mon 11 Oct 2010 08:06:36 PM UTC, comment #1: 

Using _go_patch_ rather than patch will save the sending up of the listener functions that mean that changes to the patch xdata etc affects the vertices and faces variables. As the patch objects are wrapped in a contourgroup where the user is supposed to change the variables, that seems pretyy save. Doing that on my atom bring the execution time of contour(rand(15)) down from 8.3sec to 3.5sec on my atom machine, which is nice but not enough.

I suppose we can do what is done in the scatter function to treat all the patches with the same contourlevel as the same patch. However before doing this it would be interesting the known the behavior of matlab in these case. I suspect they also group contours in this manner. Could you run

a=[-1,0,1,0,-1,0,1,0,-1];
[c,h]=contour(kron(a,a'),-0.75:0.25:0.75);
length(get(h,'children')

in matlab and tell me what it gives? If it plots a patch for each contour it should give "87" as Octave currently does.

D.

David Bateman <dbateman>
Group Member
Mon 11 Oct 2010 05:58:39 PM UTC, original submission:  

Rendering contours relies upon a loop in the subfunction add_patch_children() of _contour_.m. Contours with a large number of patches render very slowly.

octave:15> tic ; contour(rand(20)); toc
Elapsed time is 3.266 seconds.
octave:16> tic ; contour(peaks(20)); toc
Elapsed time is 0.2346 seconds.
octave:17> tic ; contour(rand(30)); toc
Elapsed time is 8.055 seconds.
octave:18> tic ; contour(peaks(30)); toc
Elapsed time is 0.2556 seconds.

I'm not sure if this is a vectorization challenge, or if the slow down can be averted by calling _go_patch_() directly.


Ben Abbott <bpabbott>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #23576:  bug31305.changeset added by logari81 (6KiB - application/octet-stream - patch)
file #21866:  davids_patches.pdf added by bpabbott (3KiB - application/pdf)
file #21847:  patch.contour4 added by dbateman (33KiB - application/octet-stream)
file #21761:  contour_fix.patch added by shaiay (8KiB - text/x-patch - consolidate filled & empty contours)
file #21667:  props.mat added by bpabbott (49KiB - application/x-matlab-workspace - matlab patch properties)
file #21660:  patch.contour2 added by dbateman (7KiB - application/octet-stream)
file #21659:  patch.contour added by dbateman (7KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by logari81 (Posted a comment)
  • -email is unavailable- added by jwe
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by gilbertosegundo (Posted a comment)
  • -email is unavailable- added by shaiay (Posted a comment)
  • -email is unavailable- added by bpabbott
  • -email is unavailable- added by dbateman (Posted a comment)
  • -email is unavailable- added by dbateman
  • -email is unavailable- added by bpabbott (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 18 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-09-04 rik5 Open/ClosedOpen Closed
    2011-06-27 logari81 Attached File- Added bug31305.changeset, #23576
    2011-06-24 jwe Carbon-Copy- Added logari81
    2011-06-23 jwe Open/ClosedClosed Open
    2010-11-01 dbateman StatusNeed Info Fixed
        Assigned toNone dbateman
        Open/ClosedOpen Closed
    2010-10-29 bpabbott Attached File- Added davids_patches.pdf, #21866
    2010-10-28 dbateman Carbon-Copy- Added goffioul
    2010-10-28 dbateman Attached File- Added patch.contour4, #21847
    2010-10-23 bpabbott Attached File- Added contour_fix2.patch, #21762
    2010-10-23 shaiay Attached File- Added contour_fix.patch, #21761
    2010-10-13 bpabbott Attached File- Added props.mat, #21667
    2010-10-11 bpabbott Carbon-Copy- Added -email is unavailable-
    2010-10-11 dbateman Attached File- Added patch.contour2, #21660
    2010-10-11 dbateman Attached File- Added patch.contour, #21659
    2010-10-11 dbateman StatusNone Need Info
        Carbon-Copy- Added kloof <kerkklokker@gmail.com>

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code