[L2Ork-dev] Exalibur bug #2: patch loading speed

[Albert Graef]

I'm afraid that I have not much to contribute to this discussion, except
that I wouldn't consider such monster patches good practice anyway. Alas,
that doesn't make the dragon go away. Does that patch load quicker in
browser-based Purr? (If it loads at all; I must admit that I haven't
closely followed Zack's progress lately.)

Albert

On Wed, Sep 9, 2020 at 5:06 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
wrote:

> Hi all,
>
> Seemingly simple question: let's suppose you open a "monster patch"
> with lots of objects, iemgui GUIs, and comments on it.
>
> It takes substantially longer for nw.js to display the canvas than it
> does for tk or tkpath to display it in Vanilla/Pd-l2ork 1.0.
>
> Question: what is nw.js spending the bulk of its time doing when
> loading the patch?
>
> Hint-- I've tested a "monster patch" that took about 20 seconds on an
> underpowered machine to display. Then I took the innerHTML of the page
> and saved it as a separate web page. If I opened that as the main page
> for a simple nw.js test app, it would display in less than a second.
>
> In other words-- the problem is *not* the number of DOM elements being
> displayed. Because that was exactly the same in my 1-second test app
> and Purr Data's 20-second "monster patch."
>
> My guess-- layout thrashing per DOM element being added from
> backend->GUI. But I haven't measured that to be true. Worse, I tried
> using requestAnimationFrame and it didn't solve the problem.
>
> Best,
> Jonathan
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20200910/507ec5d6/attachment.html>