Updating multiple components at once

[szk2s]

Hi, I'd like to share and discuss a problem we have met in the previous project.

Goal

At NovoNotes, we made a spatial audio plugin.
Our plugin requires to render multiple components on the source position change. (knobs and 2D plot which we call "pan area")
The parameters are x, y, z, which are stored in APVTS.

Problem

When parameters and components have a one-to-one relationship, the knob moves smoothly.
But they lose the smoothness when components increases.

• One knob, one parameter
  

• Three knobs, one parameter
  

• Six knobs, one parameter
  

• Here is the time profiler log of XCode Instruments. The first run is the one knob example, the second is the 3 knobs one, and the third is the 6 knobs one. All of them indicate very high CPU usage, but not so different as it looks.

The test code looks like this.

          <ParameterSlider
            paramId="MainGain"
            onDraw={Slider.drawRotary(sliderTrackColor, sliderFillColor)}
            mapDragGestureToValue={Slider.rotaryGestureMap}
            {...styles.knob}
          >
            <Label paramId="MainGain" {...styles.label} />
          </ParameterSlider>
          <ParameterSlider
            paramId="MainGain"
            onDraw={Slider.drawRotary(sliderTrackColor, sliderFillColor)}
            mapDragGestureToValue={Slider.rotaryGestureMap}
            {...styles.knob}
          >
            <Label paramId="MainGain" {...styles.label} />
          </ParameterSlider>
          <ParameterSlider
            paramId="MainGain"
            onDraw={Slider.drawRotary(sliderTrackColor, sliderFillColor)}
            mapDragGestureToValue={Slider.rotaryGestureMap}
            {...styles.knob}
          >
            <Label paramId="MainGain" {...styles.label} />
          </ParameterSlider>

Our workaround

We have written native components in C++ and injected APVTS via its constructor.

Question

How can I solve this without writing native components?

[szk2s]

I switched the JS engine to Hermes, tried to optimize React code, but neither solved this.

[nick-thompson]

Great question @szk2s, thanks for all the detail.

Yea, as Josh mentioned already, Hermes in Release mode will be a big winner. And yea @JoshMarler I'm down to mark Hermes the default, I think that will suit the majority of cases and likely provide a better development experience (especially when we get chrome devtools support going).

But, I think we should dig deeper here:

I tested 10 knobs at once, it was within the range of practical use, though the CPU rate is quite higher than the native component.

I think we can make this better still, and ideally, I want to support 10 knobs like this without even blinking. Briefly looking through the example code again, I have a few suspicions:

We're going to do a lot of tree reconciling here on every parameter update. Each ParameterSlider will listen to the event, fetch their latest value from the store, and then setState. React should catch these and identify the parent component of all ParameterSliders as the root of the "dirty" subtree and do it's reconcile pass there. That means that every node underneath will be subject to the reconcile pass, which we really don't need, because we're not actually going to change anything about the component tree or component properties on such an update– the only change we're trying to make here is to set some values and then notify the underlying CanvasView to run a repaint(). So, I think we can make some real improvements here with some careful shouldComponentUpdate hooks and being careful about which values live on this.state and which don't. We should also look to confirm that these changes do all end up in the same batch, otherwise we'll run the reconciler pass multiple times.

Looks like I've got a bit of digging to do to get into this :)

[szk2s]

Thanks, Nick! I did some refactors and optimizations at #249

[nick-thompson]

Awesome, thanks @szk2s! I'm aiming to make some time this evening to check out your PR

[nick-thompson]

Just posted some more here: #249 (comment)

Big wins to be had! I'm going to start picking off some of the easy internal ones.

[TimSusa]

Hi,

I am maybe late to the round. But it seems nobody mentioned about the usage of a debouncer or some kind of requestAnimationFrame Approach. Fast moves coming from drastic coordinate changes, as I see here, are always problematic, so thats where React can get ugly.
Lot of value changes in short amount of time will hit performance. So you always go better to reduce speed of changes or downsample that what you further use. Every state change will trigger a repaint. This is expensive. Approaches: Memoization of state, Animations, https://reactjs.org/docs/animation.html, or Come up with useEffect Hook blocking re-render, https://reactjs.org/docs/hooks-effect.html. -> It might be what you mean with shouldComponentUpdate (which I would avoid better taking hooks)

Furthermore Canvas can be very tricky, if you forget about cleaning and restoring. See my Example here: https://github.com/TimSusa/react-canvas-rotary-knob/blob/master/src/RotaryKnob.tsx

Cheers Tim