[Octave-bug-tracker] [bug #31305] slow contour plot

[David Bateman]

Follow-up Comment #18, bug #31305 (project octave):

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)
    _______________________________________________________

Additional Item Attachment:

File name: patch.contour4                 Size:33 KB


    _______________________________________________________

Reply to this item at:

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

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