[L2Ork-dev] Exalibur bug #2: patch loading speed
aggraef at gmail.com
Thu Sep 10 03:49:36 EDT 2020
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.)
On Wed, Sep 9, 2020 at 5:06 PM Jonathan Wilkes <jon.w.wilkes at gmail.com>
> 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.
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
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...
More information about the L2Ork-dev