2 posts tagged with "rendering"

@wonderlandlabs-pixi-ux/utils now provides a shared app-level render helper used by observe-drag and root-container.

What shipped​

• getSharedRenderHelper(app, config?) for app-scoped throttled render coordination.
• WeakMap singleton behavior keyed by app instance.
• First-config-wins policy per app (timing is locked by first retrieval).
• Automatic helper cleanup when app.destroy(...) is called.

Why it matters​

Multiple drag/zoom consumers on the same app now share one render-throttle stream instead of each creating independent throttled render pipelines. This ensures that multiple calls to the helper will all be throttled by the same initial settings and not multiply the number of renders requested.

If your app needs a specific timing profile, initialize the shared helper during app boot with your preferred config.

@wonderlandlabs-pixi-ux/window now documents a clear state-first pattern for runtime content updates in windows and titlebars.

New recommended pattern​

For dynamic content (toolbar actions, async updates, external events), use this flow:

1. Mutate window/titlebar state (including custom fields).
2. Request refresh by calling dirty() on the relevant store.
3. Upsert display objects from windowContentRenderer and/or titlebarContentRenderer.

Why this matters​

• Avoids Pixi artifacts from direct display-list mutation outside the refresh/ticker path.
• Coalesces multiple state changes between ticks into one final render snapshot.
• Prevents unnecessary add/remove churn when intermediate states cancel out before render.

Refresh-cycle timing​

• windowContentRenderer runs during WindowStore.resolve() via content refresh.
• titlebarContentRenderer runs during TitlebarStore.resolve().

This keeps content generation deterministic and aligned with the rest of the monorepo rendering model.