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.
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.