Make DPIChangeExecution execute with a higher priority #2906
Conversation
This commit introduces the usage of a separate thread to start processing the DPI Change events by executing the handlers using Display#syncExec to provide higher priority to the DPIChangeExecuting tasks.
| } | ||
| if (asyncExec) { | ||
| control.getDisplay().asyncExec(operation::run); | ||
| executor.submit(() -> { |
There was a problem hiding this comment.
Just an idea: couldn't we even simplify this by just having a single async task that sequentially runs through the controls and performs a syncExec with the operation on them? Maybe could even get rid of the counter then as there would be a single reponsingle (the executor) for tracking the process.
Maybe that's not possible or too complicated to adapt the implementation, but could be an interesting potential for simplification.
There was a problem hiding this comment.
There is currently one executor per DPI_CHANGE event yes. I could try getting rid of the counter and see how it affects the overall event.
There was a problem hiding this comment.
After having a look, I think it is not possible to track the end of execution without using a counter because all the controls are notified from within handleDPIChange event and that happens during the execution of each control.
|
@amartya4256 do you have some snippet or the like to share for testing this? Something like an action to trigger async executions that will block the DPI change processing in an Eclipse application or even a plain SWT snippet that spawns according async executions? |
|
Nevermind, I just used this simple snippet for test: public static void main (String [] args) {
System.setProperty("swt.autoScale.updateOnRuntime", "true");
Display display = new Display ();
Shell shell = new Shell(display);
shell.setSize(500, 100);
shell.setLayout(new FillLayout());
Label label = new Label(shell, SWT.NONE);
label.setText("Hello");
for (int i = 0; i < 2000; i++) {
display.asyncExec(() -> {
try {
Thread.sleep(100);
} catch (InterruptedException e) {
}
});
}
shell.open ();
while (!shell.isDisposed ()) {
if (!display.readAndDispatch ()) display.sleep ();
}
display.dispose ();
}This mimics a bunch of async tasks being spawned, preventing DPI change handling from being processed. That's also what actually happens as you can see the label not being rescaled when moving the shell to another monitor. However, this change does not fix it. Turns out that So I think to achieve that the DPI change processing is preferred over application-side tasks scheduled at the |
2 participants
This PR introduces the usage of a separate thread to start processing the DPI Change events by executing the handlers using Display#syncExec to provide higher priority to the DPIChangeExecuting tasks.
It doesn't fix the issue in vi-eclipse/Eclipse-Platform#530 but executes the DPI Change tasks with a higher priority making sure the execution happens quicker.