No way to know when ViewModelImageProperty.set() has been applied (listener is a no-op on the new backend)

Aperta
  • Qualcosa non va?
#445 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
44/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
react-native, typescript
Ambito
backend, mobile

Direzione di ricerca

Start by tracing ViewModelImageProperty.set() and addListener() in the React Native package, then inspect the Android and iOS backend implementations mentioned in the issue. Compare how image writes are applied with number and string writes, and check the existing view readiness and frame APIs. Done means providing a reliable signal after a bound write is applied or drawn, with coverage for the reported paused-view behavior.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

android bug enhancement iOS

Versions: @rive-app/react-native 0.5.10 (rive-android 11.14.3, rive-ios 6.29.0), new backend, React Native 0.86. Seen on a Pixel 9 Pro XL.

Problem

Since 0.5.8, imageProperty.set(image) decodes the image asynchronously and applies it later, which fixed the memory growth. But JS has no way to know when the image is actually applied and drawn:

  • ViewModelImageProperty.addListener() is a no-op on the new backend, on both Android ("Image property listeners not supported in experimental API") and iOS (TODO: image property listener not yet available in concurrency API).
  • set() returns void, not a promise.
Why it matters

We show a static <Image> of an artwork, then hand over to a RiveView that draws the same artwork through an image property. Without a signal, the handover has to be a fixed timer:

  • If we swap too early, the Rive view is visible but hasn't drawn the image yet, so it blinks empty. On a Pixel 9 Pro XL the image lands about 450 ms after awaitViewReady() resolves.
  • If we swap too late, the view sits still before its animation starts.
  • Views we pause() after a short paint window stay empty for good if the image lands after the pause, because a paused view isn't redrawn.

Number and string writes have the same gap: a view revealed right after stringProperty.set() plus a trigger draws the artboard's baked placeholder for about 0.5 s on Android before the write lands.

Repro
  1. Load a file with an image property and create a view model instance.
  2. Mount a RiveView bound to it, and call imageProperty.set(image) with a RiveImage from RiveImages.loadFromURLAsync.
  3. Show the view as soon as awaitViewReady() resolves: it draws without the image for several hundred ms.
  4. Or call pause() about 250 ms after ready: the image never appears until playIfNeeded().
Request

Any one of these would work:

  1. Make ViewModelImageProperty.addListener() fire once a set has been applied.
  2. Have set() return a Promise<void> that resolves when the value is applied, or better, after the next frame that includes it.
  3. A view-level signal such as onFrameDrawn or awaitNextFrame() after pending data-binding writes have been processed.
  4. Have a paused view redraw once when a bound image or property changes, so a parked view doesn't stay stale.
Related

Since 0.5.8, a newer set() on the same property cancels one still decoding (the generation counter). That's correct, but setting the same image twice, for example once before the view binds and again after awaitViewReady(), throws away the first decode and delays the image further.

Lingua principale
TypeScript
Stelle
158
Fork
17
Merge medio
4g 4h
PR unite (30g)
23

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rive-app/rive-nitro-react-native

Tutte le issue di rive-app/rive-nitro-react-native

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.