Refs #5176.
forEachDecorationAtCell and getDecorationsAtCell previously scanned every
registered decoration on each call. With thousands of search highlights this
becomes O(total decorations) per cell and blocks rendering during viewport
refreshes.
Maintain a Map of buffer line -> decorations that cover that line. Multi-line
decorations are indexed on every line in their span, so mixed single-line and
multi-line workloads stay fast without falling back to a full scan.
Keep the index aligned with buffer mutations:
- Register and unregister decorations in the line buckets on add/dispose.
- On trim, shift line keys synchronously (before marker handlers run).
- On insert/delete, re-index affected decorations in a microtask after marker
line updates are applied.
Inject IBufferService so line listeners follow the active buffer. Add unit
tests for trim, dispose-on-trim, insert, and dense single-line plus multi-line
lookup. Add DecorationService.benchmark.ts to measure sparse hits and
viewport-sized grid scans with 20k decorations.
Co-authored-by: Cursor <cursoragent@cursor.com>
This lets the embedder choose which Document object to use for creating
elements, adding event listeners, etc. The reason this exists is because
when working with multiple windows it can be convenient to create all
elements under the primary window to make instanceof usage consistent.
See microsoft/vscode#195595
- New 'trace' log level in the API, you should expect very spammy logs when
trace is on and filter them down. As opposed to 'debug' which should be more
readable.
- traceCall decorator logs the args and return value of the decorated method.
Wecan use this on key functions in various parts of the code to assist
debugging issues that are hard to reproduce such as #4665.
- Decorated a few webgl render methods for #4665.
- There's an early exit in traceCall when not on the trace log level so the
runtime impact when not in trace is negligable.
Part of #4665