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

Wed Jun 17 21:18:56 EDT 2020

I finally caught-up with the thread and saw your first email (it got 
buried in my inbox). What you are suggesting sounds perfect. Please note 
that my z-order thingy curiously is not an issue even after the plot is 
redrawn in the current inefficient way. As long as there is another 
object created so that it sits on top of the gl_list is good enough 
which is really really strange...

One related bug to all this is that for some reason in 0.47 I cannot 
click on some plots regardless whether joc is enabled or not. On 
bargraph I can click but there is a weird x offset, so that when 
clicking on the first bar, you are actually controlling the 11th one 
(this relationship is constant regardless of the number of bars). I did 
note this in the issues and am trying to unpack it but since the 
bargraph is your baby and you are already working on the vis 
optimization, this may be something you may be able to address quicker 
than me. FWIW the bar offset is also there on 0.14.7, although I am not 
sure if one of my own patches may be responsible for the problem.

Best,

Ico

On 6/17/2020 3:05 PM, Jonathan Wilkes wrote:
> On Wed, Jun 17, 2020 at 2:51 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
>> Before you do, I think I came up with a solution that delegates much of
>> this control to the front-end and works around the scrollbar race
>> condition while keeping scrollbars as responsive as possible. This will
>> have to be a separate merge request overriding the previous scrollbars
>> implementation (to be uploaded shortly). The only thing still missing is
>> scaling the svg, rather than doing canvas_check_geometry all over.
> Ah, crap, another hard-coded kludge. But I don't know what that has to
> do with garray redrawing.
>
> -Jonathan
>
>> This
>> will only possible after the scalar click detection is moved to the
>> front-end.
>>
>> On 6/17/2020 2:37 PM, Jonathan Wilkes wrote:
>>> Okay, turns out I was part way there:
>>>
>>> see array_configure in g_scalar.c.
>>>
>>> There I am using a special case for plot_vis, but everything
>>> else is already optimized.
>>>
>>> I'm going to take a stab at amending plot_vis so that it
>>> can just update the damn data.
>>>
>>> I'll report back what I find...
>>>
>>> On Wed, Jun 17, 2020 at 1:34 PM Jonathan Wilkes <jon.w.wilkes at gmail.com> wrote:
>>>> On Wed, Jun 17, 2020 at 1:29 PM Ivica Ico Bukvic <ico at vt.edu> wrote:
>>>>> ... Curiously, as long as the array is not the top object, redraw is way faster. Even having a canvas that is on top of it in the gl_list (does not have to be above it visually, anywhere on the canvas),  makes things again super fast...
>>>> Another data point in favor of what I just wrote.
>>>>
>>>> If we only ever change the path data/element attributes of *existing*
>>>> DOM elements, z-order isn't changed, relayout isn't
>>>> triggered, everything will just work.
>>>>
>>>> -Jonathan
>>>>
>>>>> On 6/17/2020 1:20 PM, Ivica Ico Bukvic wrote:
>>>>>
>>>>> So, slowdown is linked to the z-order of the object being manipulated. If it is all the way in the back, it is fast, in the front it is slow...
>>>>>
>>>>> On 6/17/2020 11:54 AM, Ivica Ico Bukvic wrote:
>>>>>
>>>>> Oh, and the last element on any type of a plot is not clickable in most cases regardless whether joc is enabled.
>>>>>
>>>>> On 6/17/2020 11:53 AM, Ivica Ico Bukvic wrote:
>>>>>
>>>>> So, the slowdown is not there on 0.14.7, so this is definitely a 0.46.2 and 0.47 issue, and moving things around the canvas definitely has an effect. To add to the list below, inside the bar graph the click has a right offset both on 0.14.7 and 0.46.2, so this is definitely a bug on our end. Also, clicking on plots inside a subpatch, yields spotty results (both on 0.46.2 and 0.14.7), where sometimes only a single click works (could be something I added inside the pd_canvas.js or pdgui.js, so it would be helpful to know if you have the same problem). Lastly, as pointed out in the issues tracker, subpatches do not retain their positions when closed and reopened.
>>>>>
>>>>> On 6/17/2020 11:42 AM, Ivica Ico Bukvic 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.
>>>>>
>>>>> 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
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>> --
>>>>> 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
>> --
>> 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
>>
-- 
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