-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Slow rendering for devices with lots of properties #31
Comments
I cannot reproduce this with e.g. Surge via the CLAP interface. |
I cannot reproduce with CLAP Surge XT either. I now think this is related to the length of the property labels I use. For LV2 I am currently using the full label provided by LV2, which could be something like "LFO1 Wave Width" in case of padthv1. It seems that layout for these is more complicated? If I replace the label with just the property number (like "42") the issue goes away. So maybe I need to shorten the labels like clap does.
No just the song time is changing (play needs to be on to see the effect). For some reason a changed song time retriggers a relayout that also seems to relayout the properties, even though they remain constant. |
For this purpose, we have parameter_guess_nick(), if you just register the properties with nick="", parameter_guess_nick() will be used automatically. |
I can reproduce the slowish layout with CLAP and Surge XT if I make the following change:
I tested (on Ubuntu 22.04)
For some reason Firefox (121.0.1 (64-Bit) - Ubuntu snap) refused to display the Anklang UI completely, just displaying "ANKLANG: Importing Modules..." and nothing more. |
While working on LV2 support, I've observed that playing a song with devices that have lots of properties (like 100 or more) make the UI unresponsive during playback if the knobs are visible during playpack. I've used the Chrome profiler to find out why. It seems that Chrome has to update its layout all the time, so the large number of properties slow down the layout process. It can be avoided by disabling telemetry on the position view like this:
so it seems that we need something better than we have now for implementing the mapping from telemetry to position view without triggering a relayout.
The text was updated successfully, but these errors were encountered: