[L2Ork-dev] Curious slowdown on a GOP array interaction

[Jonathan Wilkes]

On Wed, Jun 17, 2020 at 11:42 AM Ivica Ico Bukvic <ico at vt.edu> wrote:
>
> Try the attached patch and try moving the points inside the point-inv array. It works a lot slower and has a much higher cpu footprint than any other array in the patch. This is on 0.46.2. Might be worth trying it on 0.14.7 or 0.20 for comparison.

Here's a *single* click on the hitbox for the trace of point-inv:

scalar_vis 0 ab172508
scalar_vis 1 ab172508
canvas_map ab168a08 0.000000
canvas_map ab168a08 1.000000
scalar_vis 1 ab169c80
scalar_vis 1 ab16a180
scalar_vis 1 ab16a4d8
scalar_vis 1 ab16a838
scalar_vis 1 ab171e50
scalar_vis 1 ab1721b0
scalar_vis 1 ab172508

In other words:
1. Destroy a DOM element, then create and append it again. (Already slow.)
2. Unmap the entire canvas that the graph belongs to, then redraw
everything! (Holy shit.)

It's a testament to the GUI toolkit that it doesn't flicker when doing this.

No idea why specific values of the data scaling properties could
trigger a remap. Trippy stuff.

What needs to be happening is for garrays to send back new path data
in response to mouse
motion. Not remap the entire canvas, and not even toggling visibility.
Just send the updated
path data and the GUI will update it without mutating the DOM. That
will be plenty fast.

Notice I already have a hack to do that inside curve_vis-- if I call
it with vis value "-1" it will
forgo the creation of a new DOM element (e.g., gui_draw_vis) and
instead skip to just configuring
the path and attribute data for an existing element (e.g.,
gui_draw_configure_old_command).

So we eat the cost of making two calls to the gui to create a new
element-- that is, gui_draw_vis
followed by gui_draw_configure_old_command-- in order to make a single call to
gui_draw_configure_old_command when we need to update graphics for
scalars using the
old [filledpolygon] crap.

Additionally, we queue those calls in scalar_configure so that if the
backend is trying to update
a ton of data structure junk it will only send a single command on the
pollgui schedule.

This is why the pacdata game works in Purr Data but freezes up in Pd Vanilla.

So the infrastructure is there. We can start but doing to plot_vis
what I already did for curve vis.
But then we have to go into the garray mouse motion handler and figure
out how to get it to
call scalar_configure instead of redrawing everything every goddamned
time. Hell, I got so frustrated
with a simple graph label visibility bug that I ended up redrawing the
whole fucking canvas when
the user changes the graph name!

I guess we could start by just commenting the shit out of the garray
code. No matter what it's going
to be messy. But even with Pd Vanilla and simple Tk they are
generating dropouts because they don't
properly throttle array data. So this is something we need to do if we
want to get sane responsiveness
with array motion and redrawing. (Plus the 100 to 1000x performance
gains we get will overshadow
any differences in nw.js performance between versions.)

-Jonathan






>
> Another couple of problems (as noted in issues I submitted last night):
>
> Properties is sometimes available in the popup and sometimes isn't inside the subpatch. We need to either make it work consistently or not. I have no idea why this is happening however.
> Clicking on objects while the subpatch is open is often impossible. glist_xtopixels and glist_ytopixels inside g_graph.c often shows that xval (which is I belive cursor position) shows some super large number (I think the largest either positive or negative float value), suggesting something is getting messed up inside backend somewhere along the way.
> We may consider simply enabling jump-on-click at all times, since other one is a pain to use and is not really useful.
>
> Best,
>
> Ico
>
> --
> Ivica Ico Bukvic, D.M.A.
> Director, Creativity + Innovation
> Institute for Creativity, Arts, and Technology
>
> Virginia Tech
> Creative Technologies in Music
> School of Performing Arts – 0141
> Blacksburg, VA 24061
> (540) 231-6139
> ico at vt.edu
>
> www.icat.vt.edu
> www.performingarts.vt.edu
> l2ork.icat.vt.edu
> ico.bukvic.net