Open work

[vogella]

Motivation

To avoid overload of the Eclipse project work that is not yet finished should be captured here.

Remove outdated migration code in workspace chooser

File: bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/ide/ChooseWorkspaceData.java

Branch: wip-legacy-migration-code-removal

Remove the legacy XML file-based persistence fallback (readPersistedData_file() method and related code). This migration path was introduced in September 2004 (commit 5c3df86) to transition from a custom XML file (<config>/org.eclipse.ui.ide/recentWorkspaces.xml) to the configuration area preference store. The code comment itself states the fallback "should be needed no more than once per-user, per-configuration."

After 21+ years, any user who has launched Eclipse even once has been migrated. The following can be removed:

• readPersistedData_file() method
• compatibleFileProtocol() method
• getPersistenceUrl() method
• The fallback check in readPersistedData() (lines 426-428)
• PERS_FOLDER, PERS_FILENAME, PERS_ENCODING_VERSION constants
• The XML interface (xml tag constants used only by the file reader)
• Unused imports (java.io.FileReader, java.io.Reader, java.net.URL, org.eclipse.ui.IMemento, org.eclipse.ui.WorkbenchException, org.eclipse.ui.XMLMemento, org.eclipse.osgi.service.datalocation.Location)

[Win32] Fix SashLayout flickering with deferred layout

Repo: eclipse.platform.swt
Branch: deferred-layout
SWT Bugs: 558392, 563712

On Win32, Composite.requestLayout() schedules a deferred layout via Display.runDeferredLayouts(), but unlike the GTK implementation, it does not suppress repainting during the layout pass or flush pending paints afterward. This causes visible flickering (e.g., scrollbar back-and-forth) during sash resizing because SetWindowPos/MoveWindow triggers immediate WM_PAINT for each repositioned child, making intermediate layout states visible.

Fix (two commits):

1. Suppress repainting during layout: Wrap the deferred layout pass in setRedraw(false)/setRedraw(true) on all shells, so WM_SETREDRAW(0) batches all painting until layout completes, then RedrawWindow atomically repaints the final state.
2. Call update() after layout: Flush all pending paint requests immediately after the layout pass (matching GTK behavior), ensuring the new layout renders within the same event loop tick.

This fix is Win32-specific because GTK and Cocoa have compositor-level batching that naturally prevents intermediate-state flickering.

[vogella]

CTabFolder improvement branches (local, eclipse.platform.swt repo)

feature/cache-computeSize (based on eclipse/master)
Cache renderer.computeSize() results during the layout pass in updateItems(). Avoids redundant text measurement calls that scale O(N) with open tabs on every resize.

feature/split-drawSelected (based on eclipse/master)
Split the 202-line drawSelected() into drawSelectedBackground(), drawSelectedForeground(), and buildSelectedTabShape() for readability.

feature/split-computeControlBounds (based on eclipse/master)
Split the 182-line computeControlBounds() into five named layout phases: layoutLeadControls, layoutTrailControls, distributeFillSpace, layoutOverflowControls, repositionChevron.

[vogella]

Problems view filter dialog UI redesign

Local branch ui-filter-dialog-redesign contains the UX improvements, ready for a future PR:

• Compact scope combo — Replace 5 radio buttons with a single dropdown; working set "Select..." button shown/hidden dynamically
• Collapsed advanced sections — Types filter starts collapsed by default; Scope and Severity/Description stay expanded
• Limit controls cleanup — Combined into single "Limit items per group:" row
• Disable config when showing all — Configuration group and limit area disabled when "Show all items" is checked

The bug fix (vanishing markers) was split out into eclipse-platform#3862.

[vogella]

• [Win32] Fix flickering during deferred layout (Bug 558392) - Add update() call in Display.runDeferredLayouts() on Win32 to match GTK behavior. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=558392

[vogella]

Renderer Performance Tracing

Added performance tracing instrumentation to the wip-legacy-migration-code-removal branch (0c87212).

What it does: A RendererPerfTracer utility writes CSV trace data to ~/renderer-perf-trace.csv covering 15 hotspots across 10 renderer classes. Tracing is always active in this build.

Usage:

1. Build the IDE from branch wip-legacy-migration-code-removal
2. Launch and use the IDE normally (open/close editors, switch perspectives, use menus, resize sashes, switch tabs, save files)
3. Close the IDE
4. Analyze ~/renderer-perf-trace.csv

CSV format: timestamp_ms,hotspot_id,duration_ns,detail

Traced hotspots:

ID	Hotspot	File
H01	findElements for CSS_ACTIVE_CLASS on every activation	StackRenderer
H02	findElements for placeholders on label/item changes	StackRenderer
H03	Unbatched updateWidget/requestLayout	ToolBarManagerRenderer
H04	ALL_SELECTOR update on every dirty flag change	ToolBarManagerRenderer
H05	ToolItemUpdater linear scan	ToolItemUpdater
H06	Unbatched scheduleManagerUpdate	MenuManagerRenderer
H07	Per-item EclipseContext creation in menu show	MenuManagerRendererFilter
H09	findElements for MPartStack on window activate/deactivate	WBWRenderer
H10	showTab without setRedraw batching	StackRenderer
H11	Limbo reparenting without setRedraw batching	PerspectiveStackRenderer
H12	synchCTFState recursive tree walk from getUIContainer	AreaRenderer
H13	Full model scan at app startup	ToolControlRenderer
H14	Uncoalesced RunAndTrack callbacks	ToolBarManagerRenderer
W1	Synchronous layout(true,true) on Windows (SWT bug 558392)	SashRenderer

The full analysis is in docs/performance.md.

[vogella]

Correction: The performance tracing commit has been moved to branch wip-adding-performance-trace-code. The wip-legacy-migration-code-removal branch has been restored to only contain the migration cleanup commit.

[vogella]

H10 Fix: Suppress intermediate repaints in StackRenderer.showTab()

Branch: wip-fix-showTab-setRedraw-batching (dcb99d7)

Performance tracing identified showTab() as the #1 hotspot — 72% of all measured renderer overhead (1,566 ms in a 2-minute session, worst single call: 977 ms frozen UI).

Root cause: showTab() performs multiple widget mutations (setParent, setControl, requestLayout, setSelection, adjustTopRight → pack() + requestLayout()) without suppressing intermediate repaints. Each mutation can trigger a full repaint/layout pass.

Fix: Wrap the widget mutation section in setRedraw(false) / setRedraw(true) on the CTabFolder. The lazyLoader event handler already did this for its own showTab call, but postProcess and other callers did not benefit. By moving the batching into showTab itself, all callers are covered.

---

Prompt for Gemini AI to summarize renderer-perf-trace.csv

When collecting new trace data, paste the CSV into Gemini with this prompt:

---

Summarize this Eclipse renderer performance trace CSV. The format is timestamp_ms,hotspot_id,duration_ns,detail.

For each unique hotspot_id, report:

1. Count — total number of events
2. Total time — sum of duration_ns converted to milliseconds
3. Avg time — average duration_ns converted to microseconds
4. Max time — maximum duration_ns converted to microseconds
5. P95 time — 95th percentile of duration_ns converted to microseconds

Sort the table by total time descending.

Also report:

• Session duration (max timestamp − min timestamp, in seconds)
• Total trace events
• Total hotspot time (sum of all duration_ns, in ms)

For the top 3 hotspots by total time, list the 5 slowest individual events with their timestamp, duration in ms, and detail string.

Finally, note any hotspot that fires more than 100 times per minute of session time — even if individual calls are fast, high frequency matters.

---

[vogella]

Prompt for Claude CLI to analyze trace data and update docs

When starting a new session with fresh trace data, use this prompt:

---

I am working on Eclipse Platform UI renderer performance improvements. The tracking issue is #9 and the performance analysis document is at docs/performance.md in the repository.

Here is a Gemini-generated summary of a new renderer-perf-trace.csv session:

[paste Gemini summary here]

Please:

1. Read the current docs/performance.md in the repo
2. Compare the new trace data against the existing measurements
3. Update docs/performance.md with the new data — keep the measurement summary table, update numbers, re-rank priorities if the data changed, and note whether previous fixes (like the H10 setRedraw batching) had the expected effect
4. If any hotspot moved significantly up or down in ranking, call that out explicitly
5. Recommend which hotspot to fix next based on the updated data
6. Commit the updated docs/performance.md and push to the branch wip-adding-performance-trace-code
7. Add a summary comment to Open work #9

---

[vogella]

Renderer performance trace update (Session 2 — 2026-04-16)

Updated docs/performance.md on branch wip-adding-performance-trace-code with new trace data (92s session, 1,808 events, 2,824ms total hotspot time).

Fix status

• H10 showTab setRedraw batching — DONE (commit dcb99d75 on wip-fix-showTab-setRedraw-batching). Validation trace needed with the fix applied.

Key changes from baseline

Hotspot	Session 1	Session 2	Change
H10 showTab (total ms)	1,566	1,817	+16% (fix not yet in trace branch)
H07 menu context (total ms)	568	954	+68% — now 34% of all hotspot time
H06 scheduleUpdate (calls/min)	268	490	+83% frequency
H03 updateWidget (max ms)	3.1	6.3	New spike

Next fix recommendation

H07 — per-item IEclipseContext allocation in MenuManagerRendererFilter.updateElementVisibility(). Once H10 is validated, H07 becomes the #1 hotspot. Worst single call: 373ms for a menu with 18 children. Fix: reuse one scratch context across the loop instead of allocating/disposing per item.

Commit: 2691080 on wip-adding-performance-trace-code

[vogella]

Migrated to https://github.com/vogellacompany/tasks/issues/1837