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

Abierto
  • ¿Algo no está bien?
#445 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
44/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
react-native, typescript
Área
backend, mobile

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
158
Forks
17
Merge medio
4 d 4 h
PR fusionados (30 d)
23

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rive-app/rive-nitro-react-native

Todos los issues de rive-app/rive-nitro-react-native

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.