Coalesce editor re-styles caused by preference bursts - #4360
Conversation
A theme switch writes every preference key individually, and two listeners per editor reacted to each key by re-running the presentation reconciler: AbstractTextEditor invalidated the whole document, SourceViewerDecorationSupport repainted the annotation painter. Both now schedule one re-style per UI event loop turn. The painter's colors are still updated synchronously, only the repaint is deferred. Assisted-by: multiple AI agents and layers of automated tooling 🤖
|
That sounds interesting. But isn't this a general issue that preference changes are "published" one by one? The change looks like it "only" fixes the issue for text editors. What about other parts of the UI? Don't they suffer from the same issue? If yes: Can't we fix it at the central place once for everything (e.g. by changing preferences / publishing them in one bulk-call)? |
Maybe. This would need a detailed analysis, changing such a central behavior is very dangerous. |
Ok. Let's see. |
There was a problem hiding this comment.
🟡 Changes recommended
The new coalescing contract needs regression coverage.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Coalesces editor restyling during preference bursts, complementing related JDT highlighting optimizations.
Changes:
- Defers and coalesces full text-presentation invalidation.
- Defers annotation repaint while applying colors synchronously.
File summaries
| File | Description |
|---|---|
SourceViewerDecorationSupport.java |
Coalesces annotation painter repaints. |
AbstractTextEditor.java |
Coalesces full-document presentation invalidations. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 1
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| * Re-styles the whole document once per UI event loop turn, so a burst of | ||
| * preference changes costs one re-style instead of one per key. | ||
| */ | ||
| private void invalidateTextPresentationLater() { |
A theme switch writes every preference key on its own, and each key made every open editor re-run its presentation reconciler:
AbstractTextEditorinvalidated the whole document,SourceViewerDecorationSupportrepainted the annotation painter over the highlighted range. With dozens of keys per switch that cost adds up per editor.Both listeners now schedule at most one re-style per UI event loop turn, so a burst of preference changes costs one whole-document and one annotation re-style per editor instead of one per key. The painter's colors are still applied synchronously, only the repaint is deferred, so nothing is displayed with stale colors.
Verified that
org.eclipse.ui.workbench.texteditorcompiles. Note that in the theme-switch profile I took, the platform path this changes is only a small share of the stall; the bulk sits in JDT's semantic highlighting, which is eclipse-jdt/eclipse.jdt.ui#3142.