Design improvement for scaling win32 widgets #62 #2483

amartya4256 · 2025-09-02T14:53:08Z

This PR improves thes design implementation for widgets in win32 by moving away from DPIZoomChangeRegistry to an event-driven design using ZoomChanged event and inheritance.

contributes to
#62 and #128

github-actions · 2025-09-02T15:03:22Z

Test Results

546 files ±0 546 suites ±0 34m 43s ⏱️ + 2m 27s
4 431 tests ±0 4 409 ✅ - 5 17 💤 ±0 5 ❌ +5
16 764 runs ±0 16 632 ✅ - 5 127 💤 ±0 5 ❌ +5

For more details on these failures, see this check.

Results for commit 70e8d3f. ± Comparison against base commit 508ad4a.

♻️ This comment has been updated with latest results.

HeikoKlare

I am a bit confused by this change, as it introduces a mixture of event processing and direct method calls for DPI change processing. I expected the following order of changes according to what we have discussed:

Replace CommonWidgetsDPIChangeHandler: use listeners instead
Replace DPIZoomChangeRegistry: make direct calls of handleDPIChange for the native controls instead
Replace direct handleDPIChange calls: use listeners instead
Make the listener calls asynchronous (may be combined with the previous step)

This change seems to be a mixture of the first three. Can we please split that up and make the changes in a more incremental, comprehensive way?

HeikoKlare · 2025-09-03T13:59:21Z

bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/TreeItem.java

-	for (TreeItem item : treeItem.getItems()) {
-		DPIZoomChangeRegistry.applyChange(item, newZoom, scalingFactor);
+	for (TreeItem item : getItems()) {
+		item.notifyListeners(SWT.ZoomChanged, event);


Shouldn't this be a directcall to handleDPIChange for now?

Hmm alright let me think of an order.

HeikoKlare · 2025-09-03T13:59:57Z

bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Widget.java

@@ -191,6 +190,14 @@ public Widget (Widget parent, int style) {
 	reskinWidget ();
 	notifyCreationTracker();
 	this.setData(DATA_NATIVE_ZOOM, this.nativeZoom);
+	registerDPIChangeListener();


With this PR, we stick to the synchronous processing of the event via direct methods calls, so no need to aready add this listener, right?

HeikoKlare · 2025-09-03T14:01:47Z

bundles/org.eclipse.swt/Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/CCombo.java

+private void handleCComboDPIChange(Event event) {
+	updateAndRefreshChildren(childWidget -> {
+		childWidget.notifyListeners(SWT.ZoomChanged, event);
+	});
+}


This intermediate method can be removed by directly making the notifications in the update method.

HeikoKlare · 2025-09-03T14:02:03Z

bundles/org.eclipse.swt/Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/CCombo.java

+	addListener(SWT.ZoomChanged, event -> {
+		handleCComboDPIChange(event);
+	});


Suggested change

addListener(SWT.ZoomChanged, event -> {

handleCComboDPIChange(event);

});

addListener(SWT.ZoomChanged, this::handleCComboDPIChange);

HeikoKlare · 2025-09-03T14:02:14Z

bundles/org.eclipse.swt/Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/CCombo.java

@@ -2026,19 +2029,24 @@ public boolean traverse(int event){
 	return super.traverse(event);
 }

+private void handleCComboDPIChange(Event event) {


Suggested change

private void handleCComboDPIChange(Event event) {

private void handleDPIChange(Event event) {

HeikoKlare · 2025-09-03T14:02:47Z

...les/org.eclipse.swt/Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/StyledText.java

-	styledText.setCaretLocations();
-
+	caretSet.stream().filter(Objects::nonNull).forEach(caretToRefresh -> {
+		((Caret) caretToRefresh).notifyListeners(SWT.ZoomChanged, event);


The set is already types as Caret, so why cast to Caret here again?

HeikoKlare · 2025-09-03T14:03:10Z

bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Composite.java

 	}
-	composite.redrawInPixels (null, true);
+//	redrawInPixels (null, true);


It has been removed in a previous PR. My bad, I would rebase this PR now.

HeikoKlare · 2025-09-14T14:51:50Z

bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/Widget.java

-private static void handleDPIChange(Widget widget, int newZoom, float scalingFactor) {
-	widget.nativeZoom = newZoom;
-	widget.setData(DATA_NATIVE_ZOOM, newZoom);
+void handleDPIChange(Event event, float scalingFactor) {


Why change the signature here instead of sticking to the existing parameters?

We agreed about passing the same event down the same hierarchy and since we have made the method non static now, we do not need Widget anymore but rather the event.

HeikoKlare · 2025-09-14T14:53:13Z

bundles/org.eclipse.swt/Eclipse SWT/win32/org/eclipse/swt/widgets/TabFolder.java

-	for (int i = 0; i < tabFolder.getItemCount(); i++) {
-		DPIZoomChangeRegistry.applyChange(tabFolder.items[i], newZoom, scalingFactor);
+	for (int i = 0; i < getItemCount(); i++) {
+		items[i].notifyListeners(SWT.ZoomChanged, event);


Shouldn't this be items[i].handleDPIChange(...) for now?

amartya4256 · 2025-09-15T11:32:40Z

@HeikoKlare I think we have mixed up things. With this PR we just wanted to move to Event driven architecture and not make it asynchronous. I understand that both the terms go hand in hand but we must note that the event model in SWT is synchronous and if an event is sent by a caller, at first the stub is executed and the caller waits for the event to be processed and then moves forward. Hence, this PR doesn't implement asynchrony. That's also the reason why I called notifyListeners instead of calling handleDpiChange because every widget registers to a listener then they must receive the DPI_CHANGE event also through listeners and not by some other widget calling handleDPIChange on them. The follow up PR would implement asynchrony while calling notifyListeners by the following:

void sendZoomChangedEvent(Event event, Shell shell) {
	AtomicInteger handleDPIChangedScheduledTasksCount = (AtomicInteger) event.data;
	handleDPIChangedScheduledTasksCount.incrementAndGet();
	getDisplay().asyncExec(() -> {
		try {
			if(!this.isDisposed()) {
				notifyListeners(SWT.ZoomChanged, event);
			}
		} finally {
			if (handleDPIChangedScheduledTasksCount.decrementAndGet() <= 0) {
				shell.WM_SIZE(0, 0);
			}
		}
	});
}

and notifyListeners will be replaced by this method.

amartya4256 · 2025-09-15T11:48:53Z

So from what you are proposing and what I think how we could do it, I devised the following order:

Remove DPIZoomChangeHandler and use direct handleDPIChange calls for internal classes and use ZoomChangedEvent for Common widget.
Move to Event driven model
Make the event driven model asynchronous.

(The only problem I see is in the first step. If we handle ZoomChangedEvent for Common widgets like StyledText, etc, they are not scaled in the hierarchical order. I need to test if it could cause any trouble.)

HeikoKlare · 2025-09-16T07:31:51Z

Sounds good, I would just try to split the first step into the adaptation of common/custom widgets and the adaptation of the native part to keep it as small as possible.

(The only problem I see is in the first step. If we handle ZoomChangedEvent for Common widgets like StyledText, etc, they are not scaled in the hierarchical order. I need to test if it could cause any trouble.)

But since everything stays synchronous, it should not matter whether you call a registry or whether you send an event.

This commit replaces the win32-specific caret scaling with API-based resizing to ensure proper repaint on DPI changes. Carets now update location/size via resize() in their DPI change handlers, removing platform dependencies. Additionally, StyledTexts set location, size and visibility of their carets first before calling the DPI change handler of Caret to make sure when Caret is repainted, the size, location and visibility are properly set.

This commit improves thes design implementation for widgets in win32 by moving away from DPIZoomChangeRegistry to an event-driven design using ZoomChanged event and inheritance. contributes to eclipse-platform#62 and eclipse-platform#128

amartya4256 · 2025-09-16T21:35:53Z

@HeikoKlare As per our discussion, Replacing CommonWidgetZoomChangeHandler with ZoomChanged Event handler is not possible since the Common widgets need to call for the handleDPIChange for their associated widgets which is win32 specific code and we cannot call notifyListeners on these widgets without making them register to ZoomChanged event as they still use DPIZoomChangeRegistry. Hence, the following is necessary to make it work all together:

Register Widget with ZoomChanged event.
Implement inheritance based super.handleDPIChange for widgets to mimic DPIZoomChangeRegistry's heirarchial behaviour.
For handling DPI Change for associated / children widgets, replace DPIZoomChangedRegistry.applyChange with widget.notifyListeners (This still executes synchronously).
Move the CommonWidgetZoomChangeHandler methods to the Common Widgets and register them on ZoomChanged events.
Remove CommonWidgetZoomChangeHandler & DPIZoomChangeRegistry/Handler.
Adapt the DPI_CHANGE event trigger point in Control to use Shell.notifyListeners

For the next step, i.e. asynchrony, we will replace these notifyListeners with a Widget:sendZoomChangedEvent which will call widget.notifyListener asyncly and handle the painting upon DPI scaling completion.

amartya4256 linked an issue Sep 2, 2025 that may be closed by this pull request

Design improvement for Win32 Widget scaling vi-eclipse/Eclipse-Platform#435

Open

amartya4256 mentioned this pull request Sep 11, 2025

Caret scaling implementation improvement on StyledText DPI change #2470

Open

HeikoKlare reviewed Sep 14, 2025

View reviewed changes

amartya4256 force-pushed the amartya4256/dpi_performance_improvement/design_improvement branch from 85b3b74 to 3bf732f Compare September 16, 2025 21:24

amartya4256 force-pushed the amartya4256/dpi_performance_improvement/design_improvement branch from 3bf732f to 70e8d3f Compare September 16, 2025 21:27

	private void handleCComboDPIChange(Event event) {
	private void handleDPIChange(Event event) {

Design improvement for scaling win32 widgets #62 #2483

Are you sure you want to change the base?

Design improvement for scaling win32 widgets #62 #2483

Uh oh!

Conversation

amartya4256 commented Sep 2, 2025

Uh oh!

github-actions bot commented Sep 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Test Results

Uh oh!

HeikoKlare left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amartya4256 commented Sep 15, 2025

Uh oh!

amartya4256 commented Sep 15, 2025

Uh oh!

HeikoKlare commented Sep 16, 2025

Uh oh!

amartya4256 commented Sep 16, 2025

Uh oh!

Uh oh!

github-actions bot commented Sep 2, 2025 •

edited

Loading