Skip to content

Fix edit scope single-element flickering by retaining stale graphics until edited geometry is ready#9208

Draft
markschlosseratbentley wants to merge 1 commit into
masterfrom
markschlosser/edit-flicker
Draft

Fix edit scope single-element flickering by retaining stale graphics until edited geometry is ready#9208
markschlosseratbentley wants to merge 1 commit into
masterfrom
markschlosser/edit-flicker

Conversation

@markschlosseratbentley
Copy link
Copy Markdown
Contributor

Problem

When an element's geometry is modified during a GraphicalEditingScope, the dynamic tile system immediately discards the old graphics and requests new ones. Until the new graphics arrive (which requires tile generation), the element disappears for one or more frames, causing a visible flicker. This is especially noticeable during rapid/continuous edits of complex geometry where new geometry changes arrive before previous tile requests complete.

Solution

When an ElementTile's geometry is updated, retain children that have loaded graphics as stale fallbacks instead of disposing them. During tile selection, fall back to a stale child when no current match is available. Dispose stale children once fresh graphics arrive. When edits arrive faster than graphics can load, preserve the existing stale fallback rather than discarding it.

WIP: The behavior is gated by TileAdmin.retainStaleDynamicTileChildren (@internal, default true) so it can be toggled at runtime for comparison testing. Not proposing this become a permanent toggle! Just for testing this PR!

DTA tooling

  • dta deform element: New interactive PrimitiveTool that continuously rewrites the GeometryStream of selected elements on every mouse motion (not just placement transform). This exercises the exact code path that triggers flicker — select elements, click an anchor point, then move the mouse to see continuous geometry commits.
  • dta toggle stale children: Toggles the retainStaleDynamicTileChildren flag on/off to A/B compare the old (flicker) vs new (stale fallback) behavior.
  • openIModel.ts: Use BriefcaseConnection.openStandalone for writable mode to support editing tools.

Tradeoffs

With the fix enabled, there is a visual lag — the stale graphic shows the element at its previous committed position until the new graphic loads. This is an inherent tradeoff vs. the element disappearing entirely. The toggle keyin makes it easy to compare both behaviors.

Dataset / Repro Steps

Download testcase: flicker-test-simple-orig.bim.zip

  1. cd test-apps/display-test-app
  2. export IMJS_READ_WRITE=1
  3. npm run start
  4. Open above bim file.
  5. In keyin field: dta edit
  6. Select an element.
  7. In keyin field dta deform element. Click element. Begin dragging it around.
  8. Observe no flickering, but a bit of delay.
  9. Right click to stop
  10. In keyin field: dta toggle stale children
  11. Select an element.
  12. In keyin field dta deform element. Click element. Begin dragging it around.
  13. Observe lots of flickering.

Videos

The flickering:

yes-flicker.mov

Avoiding the flickering using this PR's approach:

no-flicker.mov

*--------------------------------------------------------------------------------------------*/

import { CompressedId64Set, Id64String } from "@itwin/core-bentley";
import { BentleyError, CompressedId64Set, Id64String } from "@itwin/core-bentley";
Comment thread test-apps/display-test-app/src/frontend/EditingTools.ts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants