Adapt double buffering use cases for multi-zoom

[akoch-yatta]

This PR replaces three use cases where GC together with Images where used to draw double buffered images. With new multi-zoom-setting in Windows this leads to multiple issues like:

• destructive scaling, e.g. up- or downscaling of the pixel data
• fragments, when buffer image and second buffer image use different zoom

The changes utilize the newly added ImageGcDrawer to provide a dynamic callback to draw on a correctly initialized GC on demand.

Most important changes are:

• cleanup of the buffer image on zoom change
• Always do a full draw when a new variant is requested

How to test

1. You need to use the branch from Callback for dynamic drawing with a GC on images eclipse.platform.swt#1734 for SWT.

2. Either make sure you have the the experimental monitor specific flag enabled or use -Dswt.autoScale.updateOnRuntime=true -Dswt.autoScale=quarter as additional VM arguments

3. Have at least two monitors with different zoom (e.g. one with 100, one with 150), detach a view and move it to the second monitor. Then you should be able to create fragments or other glitches in the text editors e.g. by just resizing it -> resizing always retriggers a full re-creation.

Example for OverviewRuler and LineNumberRulerColumn

If you have a monitor setup with 200% and 100%, have both (main view and detached view) on 200%, move one to the 100% monitor and resize the view remaining on 200%. You will see:
Before it blurry scales the 100% variant of the image and blurry scales the line number

After it correctly fetches the 200% variant of the image and the line numbers are redrawn sharply

Example for not refreshed line numbers

Use the same setup as above: 200% and 100% monitor, have both (main view and detached view) on 200%, move one to the 100% monitor and resize the view remaining on 200%. You should see the line number not correctly refreshed on scrolling though a file anymore

Important: As it is quite visible I want to mention, that the DefaultRangeIndicator will still looks glitchy like

in some scenarios. This is an additional issue related to ImageData and the destructive scaling of ImageData and will be fixed in a separate PR. This is a pre-existing issue, but the monitor aware scaling makes it way more obvious.

[github-actions]

Test Results

 1 818 files  ±0   1 818 suites  ±0   1h 30m 23s ⏱️ + 1m 13s
 7 715 tests ±0   7 487 ✅ +1  228 💤 ±0  0 ❌  - 1 
24 306 runs  ±0  23 557 ✅ +1  749 💤 ±0  0 ❌  - 1 

Results for commit 57666c4. ± Comparison against base commit 8029b47.

♻️ This comment has been updated with latest results.

[HeikoKlare]

Some minor additions on the PR:

• Testing the changes without the experimental preference for monitor-specific scaling on Windows, the behavior should be the exact same as before the PR. The mentioned remaining glitches will only occur when having that experimental feature enabled.
• Only derivation from the point above is the appearance on GTK when changing fractional scaling settings of the used monitors while running an Eclipse application. In this case, one should experience an improvement of the apperance of the line number ruler, see Callback for dynamic drawing with a GC on images eclipse.platform.swt#1734 (review)

This is how the improvement looks on GTK when switching from 100% to 150% scaling:

Before the changes

After the changes

[HeikoKlare]

The change looks good to me. I have tested it on all platforms together with eclipse-platform/eclipse.platform.swt#1734 and found no issues, but I will also test again today with the final state of the merged SWT changes.

I only have a minor comment on a potential code simplification.

[fedejeanne]

Thank you for adding the use cases to test @akoch-yatta .

I tested (in Windows) and found no regressions and also that the 2 mentioned use cases were fixed by this PR. I couldn't find any more glitches,