Remove expectedImprovement in DelegatedInkTrailPresenter

concepts

1. expectedImprovement removed

   Probe the prototype for the removed attribute; pair with a working PerformanceObserver({type: "event"}) reading the actual pen-input latency.

2. Delegated vs undelegated trails

   The motivation's pitch — "all improvement is good improvement" — made tangible. Side-by-side pads: one draws every frame in JS; the other delegates the wet ink to the OS compositor. Meters show the per-event latency difference.

3. Ink-trail clinic (5 symptoms)

   Five symptoms a real ink app might present (reading the property, passing it as an option, A/B benchmarking on it, DevTools deprecation log, not using it). For each: a diagnosis, side-by-side broken/fixed code, and a live ink canvas verifying the Chrome 130 pattern works on this device.

4. Ink latency probe

   Draw freely on a canvas with touch/mouse/stylus. PerformanceObserver({type:"event"}) measures real pointermove latency and plots it as a live histogram — the replacement for the removed expectedImprovement attribute. Attempts navigator.ink.requestPresenter() and reports delegated-ink status.

why it shipped

expectedImprovement tells web developers how much improvement the DelegatedInkTrails API will provide to their current ink latency. However, this attribute is not worth increases to fingerprinting entropy. The difference in cost to the web developer between using the expectedImprovement attribute and actually delegating the "wet" ink trail to the OS/Browser is minimal, and upon additional discussion, there was no good reason found for the web developer not delegating the ink trail after receiving some value from the expectedImprovement attribute (all improvement is good improvement). The remov

references

• ChromeStatus entry
• Spec