Skip to content
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

Open
swesterfeld opened this issue Dec 5, 2023 · 4 comments
Open

Slow rendering for devices with lots of properties #31

swesterfeld opened this issue Dec 5, 2023 · 4 comments
Assignees
Milestone

Comments

@swesterfeld
Copy link
Collaborator

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:

diff --git a/ui/b/positionview.js b/ui/b/positionview.js
index e74a7cd..1662126 100644
--- a/ui/b/positionview.js
+++ b/ui/b/positionview.js
@@ -123,6 +123,7 @@ class BPositionView extends LitComponent {
   }
   recv_telemetry (teleobj, arrays)
   {
+    return;
     if (!this.timer_text) return;
     const ds = "\u2007"; // FIGURE SPACE - "Tabular width", the width of digits
     const s3 = n => (n >= 100 ? "" : n >= 10 ? ds : ds + ds) + n;

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.

@tim-janik
Copy link
Owner

I cannot reproduce this with e.g. Surge via the CLAP interface.
Are all the properties changing all the time, or why would they be re-rendered?

@swesterfeld
Copy link
Collaborator Author

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.

Are all the properties changing all the time, or why would they be re-rendered?

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.

@tim-janik
Copy link
Owner

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.

For this purpose, we have parameter_guess_nick(), if you just register the properties with nick="", parameter_guess_nick() will be used automatically.

@swesterfeld
Copy link
Collaborator Author

I can reproduce the slowish layout with CLAP and Surge XT if I make the following change:

diff --git a/ase/clapdevice.cc b/ase/clapdevice.cc
index 73eff31..faf0f41 100644
--- a/ase/clapdevice.cc
+++ b/ase/clapdevice.cc
@@ -29,7 +29,7 @@ struct ClapPropertyImpl : public Property, public virtual EmittableImpl {
 public:
   String ident      () override   { return ident_; }
   String label      () override   { return label_; }
-  String nick       () override   { return parameter_guess_nick (label_); }
+  String nick       () override   { return label_; }
   String unit       () override   { return ""; }
   String hints      () override   { return ClapParamInfo::hints_from_param_info_flags (flags); }
   String group      () override   { return module_; }

I tested (on Ubuntu 22.04)

  • make run
  • Chrome Version 120.0.6099.199 (Offizieller Build) (64-Bit)

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.

@swesterfeld swesterfeld assigned tim-janik and unassigned swesterfeld Jan 14, 2024
@tim-janik tim-janik added this to the v0.3.0 milestone Jan 27, 2024
@tim-janik tim-janik modified the milestones: v0.3.0, v0.4.0 Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants