Description
DPI change processing was recently modified to be executed asynchronous:
This introduced a regression in user experience when opening child shells (such dialogs, quick outline view and the like), as they may be layouted for a different monitor (and its zoom) than they are finally placed first to then be relayout while already being visible. The issue was reported and is documented here:
Reproduction
- Have two monitors with different zooms
- Start a current Eclipse SDK product (not a runtime instance) from one of the monitors (i.e., start the
.exe from within the Windows explorer or from the taskbar on that monitor)
- Move the window to the other monitor then it was started on (if it does not already open there)
- Open any dialog, quick outline view or the like
- The shell that opens will first layout according to the monitor zoom the application was started from to then be relayouted for the current monitor.
Expected Behavior
Child shells should always open in a properly layouted way.
This can be achieved by making the DPI change processing for child shell synchronous, but that's rather a workaround for the underlying issue than an actual fix.
For an actual fix it shall be investigated whether the shell can already be layouted for the correct monitor/zoom when doing the layouting the first time on being opened. Current guess is that the shell is created for the monitor on which the application was started, thus also having a position on and the zoom of that monitor assigned. When the shell becomes visible (during processing the call to open()) it's relocated to the correct monitor, leading to the DPI change event that is then processed asynchronously.
This latter point may also affect, contribute to, or even solve:
Description
DPI change processing was recently modified to be executed asynchronous:
This introduced a regression in user experience when opening child shells (such dialogs, quick outline view and the like), as they may be layouted for a different monitor (and its zoom) than they are finally placed first to then be relayout while already being visible. The issue was reported and is documented here:
Reproduction
.exefrom within the Windows explorer or from the taskbar on that monitor)Expected Behavior
Child shells should always open in a properly layouted way.
This can be achieved by making the DPI change processing for child shell synchronous, but that's rather a workaround for the underlying issue than an actual fix.
For an actual fix it shall be investigated whether the shell can already be layouted for the correct monitor/zoom when doing the layouting the first time on being opened. Current guess is that the shell is created for the monitor on which the application was started, thus also having a position on and the zoom of that monitor assigned. When the shell becomes visible (during processing the call to
open()) it's relocated to the correct monitor, leading to the DPI change event that is then processed asynchronously.This latter point may also affect, contribute to, or even solve: