[Octave-bug-tracker] [bug #56081] quiver and set() many data/property fields is ineficient with many listeners

[SillyMon]

URL:
  <https://savannah.gnu.org/bugs/?56081>

                 Summary: quiver and set() many data/property fields is
ineficient with many listeners
                 Project: GNU Octave
            Submitted by: sillymon
            Submitted on: Fri 05 Apr 2019 10:51:47 PM UTC
                Category: Plotting
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name: SillyMon
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.4.1
        Operating System: Microsoft Windows

    _______________________________________________________

Details:

__quiver__ sets a listener for all the data fields x/y/z/u/v/wData of the
quiver handle to update_data(h,~) when a change to the fields are made.
set(h, 'xData', 'yData') or more data variables or props trigers the same
callback functions update_data or update_props for every single data/prop
field being changed in one use of set.

this makes the updating of one single arrow take approx 0.1 sec, this is to
slow. Updating the position and size of a arrow constructed of 10 patches is
faster, almost 10 times faster. While quiver only uses 3 lines for a arrow as
far as i have looked.

There is no reason to run the update_data/props functions more than once for
each instance of set().
or at least there should be a way for the user to turn off and on the
listeners and decide when all new data is ready for update.
but update_data/props is local to __quiver__. testing gave a improvement to
0.05 sec for 


    %addlistener (hg, "xdata", @update_data);
    %addlistener (hg, "ydata", @update_data);
    addlistener (hg, "zdata", @update_data);
    %addlistener (hg, "udata", @update_data);
    %addlistener (hg, "vdata", @update_data);
    addlistener (hg, "wdata", @update_data);


other plotting functions seem to have the update_data part of the code built
in to octave. 

the __quiver__.m functions has many calculations repeated many times. fast
code dose not seem to have been of any concern in this implementation and much
of it seems like ripe, low hanging fruit for a rewrite.

Is there any way to tell octave that it should wait for more data before it
starts preparing for drawing/reacts to changes in the fields of a graphics
handle?




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56081>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/