Scope IME display attribute enumeration to the edited ranges

[akon47]

Fixes the typing lag reported in #7397.

Cause

TextServicesDisplayAttributePropertyRanges.OnEndEdit enumerates the display attribute property with a null target range, which enumerates it over the whole document:

displayAttributeProperty.EnumRanges(ecReadOnly, out attributeRangeEnumerator, null);

The property accumulates a range per previously composed run, so both the enumeration and the COM round trip it costs per range grow with document length — on every keystroke.

Only IMEs that set display attributes hit this (for example the modern Korean TSF IME, which underlines the composition). Measured on a 1,200 character RichTextBox, a single OnEndEdit enumerated 1,077 ranges of which exactly 1 carried an attribute, blocking the UI thread for ~3 seconds.

Fix

Use GetPropertyUpdate(editRecord) to obtain the ranges this edit actually changed and enumerate the property within each of them — which is what the base class TextServicesPropertyRanges.OnEndEdit already does. This override had lost that scoping.

GetPropertyUpdate is promoted from private to protected so the override can reuse it.

Measurement

SendInput macro typing 안녕하세요 300 times into a RichTextBox (Windows 11 10.0.26200, .NET 8, x64 Release):

	mean / iteration	max	UI thread stalls
before	181.3 ms	3577.6 ms	13, totalling 15,898 ms
after	100.9 ms	127.4 ms	1, of 53 ms
legacy IME (reference)	101.5 ms	173.1 ms	none

The same harness with the IME in English mode showed no stalls before or after, confirming the cost is in the composition path.

Composition underline and the Hanja candidate window continue to render correctly, including mid-document, while scrolled, and immediately after fast typing.

Notes

• The same code is present on .NET Framework (PresentationFramework 4.8.9340.0), consistent with the original report that 4.8 is affected.
• Root cause was located with WPF's own IME tracer (IMECompositionTraceTarget) plus stack sampling during the stalls; analysis was done with the help of Claude Code, and every number above is a measurement from an actual run on my machine.

Microsoft Reviewers: Open in CodeFlow

[akon47]

@dotnet-policy-service agree

[akon47]

Updated the commit to address an edge case with input methods whose composition holds several display attribute ranges at once.

What changed and why

The first version scoped the enumeration to the ranges GetPropertyUpdate reports (the ranges an edit changed). That is enough for the Korean IME, whose composition is a single run, but it could drop an attribute for an IME where the composition has several attribute ranges and an edit updates only some of them — for example Japanese clause conversion, where moving the target clause changes only some clauses' display attributes while the rest must still be drawn.

The updated version enumerates over the smallest ACP span covering (a) every active composition (ITfContextComposition.EnumCompositions → ITfCompositionView.GetRange) and (b) every range this edit changed (GetPropertyUpdate). Display attributes can only live inside a composition or on a range the edit just touched, so this window finds every range the whole-document scan would find, for any IME, while keeping the cost proportional to the composition instead of the document.

Verification

Automated SendInput macro, 150 iterations per phase, alternating the stock and fixed builds (both built from the same source) in the same process. Windows 11 10.0.26200, .NET 8, x64 Release.

IME	stock max	stock stalls	fixed max	fixed stalls
Korean	1729 ms	6, 15	152 ms	0, 0
Japanese	1498 ms	59	491 ms	12
Chinese	596 ms	3	226 ms	0
English (no composition)	—	0	—	0

(stalls = iterations over 300 ms; Korean and English were run twice.)

Equivalence was checked with a temporary in-build oracle that, on every edit, also ran the original whole-document enumeration and compared its attribute-range set against the scoped scan:

IME	edits	mismatches	scan window (avg)
Korean	2109 ×2	0	1.3 chars
Japanese	3459	0	7.5 chars (multi-clause)
Chinese	1811	0	7.3 chars
English	1959	0	—

11,447 edits, zero mismatches — the scoped scan returned exactly the same set of display attribute ranges as the whole-document scan, including Japanese multi-clause compositions. The oracle was removed from the committed change.

The composition underline and candidate window render correctly in all three IMEs.

---

The analysis and the verification harness were done with the help of Claude Code; every number above is a measurement from actual runs on my machine, and I can share the harness if it helps.

🤖 Generated with Claude Code