Is there anything faster / better / lower-level than <Drawing /> ?

[RCNNT-Industries]

Hey people!

I've done a custom interactive graph with virtualization, using the first version of Skia that landed on Expo. Then patched it every time Expo launched a new SDK. Latest attempt is for Reanimated 3 — but I feel like I'm using the API wrong!

I've got a top level canvas, containing 2 Groups with 4-5 Drawing inside each. They all do some sort of computation on the data that's passed on (basically plot values to a graph), and then in their drawing method use that data.

In a given drawing function I might loop over the data to create bars or headings.

Scrolling is handled by react-native-gesture-handler, and since the display is virtualized (only render what's visible on screen) I depend on at least 1 useSharedValue from react-native-gesture-handler. In practice that value is used to make an array of the data points to render — and the scroll is always offset by scrollX % COL_WIDTH (for the virtualizing).

Performance is decent enough (40+ fps at least), but not amazing.

When does a Drawing triggers it's drawing-method?
Is the any levels of cache-ing I may be able to apply?
Is there any lower level component than Drawing that might fit my needs better?

Best,
Erik

[wcandillon]

I would strongly suggest against using the <Drawing /> api has it relies on lock the JavaScript thread and this is one of our least tested component. My apologies for the confusion here.
With SkiaDOM, we try to build a high-performance scene graph for Skia that can run on the UI thread. When using the <Drawing /> component we break that contract completely (because it needs to call back to the JS thread) and it is possible that have yet to understand the consequences of doing that yet.

[hungtooc]

Will imperative API be developed and improved in the future?