[L2Ork-dev] Exalibur bug #2: patch loading speed
jon.w.wilkes at gmail.com
Thu Sep 10 09:41:51 EDT 2020
On Thu, Sep 10, 2020 at 3:50 AM Albert Graef <aggraef at gmail.com> wrote:
> 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.)
Honestly, it didn't occur to me to test with the web app. I'll have a look.
> 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.
>> 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/
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
More information about the L2Ork-dev