Analyze performance of dpi change event handling

[akoch-yatta]

Description
Over the previous releases the performance of a full refresh after a DPI change was detected seems to have significantly decreased. A deeper analysis of possible improvements, e.g. via profiler, is required to identify measures to improve the performance again. Goal of this issue is to do the structured analysis and identify the most problematic areas.

Reproduction
Trigger a DPI change of a big UI, e.g. the full Eclipse IDE, by dragging it to a different monitor with monitor specific scaling active. The refresh takes a decent amount of time.

Expected Behavior
A fast refresh after a DPI change event in complex UIs

Necessary configuration:

--

Additional knowledge
One idea could be to remove the redrawInPixels draw in Composite::handleDPIChange

[HeikoKlare]

As a first subtask of this, I would expect an analysis of the actual performance-influencing factors. We can of course try the proposed removal of redrawInPixels calls, but in my opinion we all need to get an overview of what impacts performance.
So I would propose to first do some sampling to identify the critical operations and analyze what's going on there.

[akoch-yatta]

Yes, this task should be only about the analysis. Just wanted to mention the one idea I already had 😄

[amartya4256]

These places take the most of the CPU time on DPI_CHANGED:

• Composite:handleDPIChange - redrawInPixels inside doesn't take long at all. hence it is not a problem as it seems.
• Composite:setSize, Composite:sendResize
• Composite:layout(): calls GridLayout:layout
• Control:setBoundsInPixels(): The ultimate place where the OS call is made to resize and move. There are many places where the client wants to set the size which is already set. Adding a check before setting the dimensions improves the speed, although couldn't find a cleaner way to perform the check.
• Gridlayout.layout: Layout seems to be expensive and is mostly called upon Composite:sendResize
• Image:win32_getHandle() (20%) - On the first DPI_CHANGED to a zoom level, it creates image handles on demand. The next time, it doesn't take that long.

I have created a branch with some ugly fixes, which seems to increase the performance by 500 to 1200 ms. Here: eclipse-platform/eclipse.platform.swt#2233

[HeikoKlare]

Do you maybe have some snapshots to share, where we can see the distribution of time spent on the different tasks/methods?

Regarding the improvement by 500 to 1200 ms (which already sounds nice in absolute values): what is the reference value, i.e., how long does it take with/without the improvements in total, or what is the relative improvement?

Did you also test different scenarios, i.e., does the kind/number of UI elements maybe play a role in how long it takes? I sometimes have a product that adapts quickly (in few 100 milliseconds) and I sometimes have a product that requires multiple seconds to adapt, but I did not investigate yet whether there is a pattern / some specific source of the increased time.

[amartya4256]

Here are the tested scenarios:

1. The runtime SDK Product itself
2. The preferences dialog with all the pages open.

The performance degrades with the number of views opened. The runtime SDK seems to scale extremely quicker as compared to the preferences dialog. Also on profiling, I found that the methods mentioned above are the hot ones but they aren't consistently hot. For some runs, they are very quick but for some others they are very slow. These methods easily consume 5 to 20% of the total CPU time while scaling.

Here is a snapshot of the profiler: