[Windows Hi-DPI] Progress icon is too big and clipped

[Phillipus]

Eclipse 4.28
Windows 11
Hi-DPI screen 200% scaling

When running an operation that uses Progress, the icon in the status bar (progress bar?) is rendered 2x too big and so we only see a quarter of it:

[tmssngr]

@Phillipus Have you already tried running Eclipse with swt.autoScale set to false? We do that for SmartGit and it solves a couple of problems.

[merks]

There's also this setting on the java executable (javaw.exe) that has an impact:

I make sure to change it to system rather than application so that Windows does the scaling and not SWT which does a horrible job.

[Phillipus]

I think this is a case that was missed when creating images at double-scale on Windows. I'll have to dig deeper but I think it used to work.

[Phillipus]

Further investigation shows that sometimes it does render at the correct size. One factor is whether the "Tip of the day" icon is showing in the bottom status bar or not. Sometimes the progress icon doesn't appear at all.

[Phillipus]

This is connected to another issue I see in Eclipse at 200% scaling.

Sometimes the icons used for files (Program icons) in the Package Explorer have a black background and sometimes they don't. If they don't have a black background the progress icon is rendered correctly.

See #185 and #715

[HeikoKlare]

I just noticed that I sometimes see this for other elements in the status bar as well, e.g.

So maybe this is a general layouting issue of the StatusLine in HiDPI setups. The shown progress icon is defined in ProgressAnimationItem.

[Phillipus]

In the case of the Progress icon it's 2x too big on HiDPI (and so clipped so we only see 1/4 of it), so I always thought it was either using the wrong icon size or rendering the wrong size.

[HeikoKlare]

Yes, the icon in the screenshots appears to have twice the width/height it should have. But the icons themselves all look correctly scaled (16x16 in their 100%/svg version and 32x32 in their 200% version). The image is only set at on a simple ToolItem, which is why this does not seem to be so specific to the progress case.

[arunjose696]

The issue happens because on Windows, when a toolbar is created without a size, Windows gives each button a default size of 24×22. Our icons are 16×16, so at 100% scaling everything looks fine as it wont be cut off.

On HiDPI screens, the images that get set later are bigger (e.g., 32×32). The toolbar and its buttons resize to fit the bigger image, but the parent (grid layout) doesn't relayout, so the space stays too small and the icon gets clipped.

This issue of parent not relayouting seems to come from the deferred layout call introduced in this commit:
eclipse-platform/eclipse.platform.ui@84b4e32 (which was added for performance reasons: https://bugs.eclipse.org/bugs/show_bug.cgi?id=528030).
Because of this deferred layout, the parent layout doesn't update after the images are set, until a setLayoutDeferred(false) happens which can occur on something like a DPI change.

A fix is to layout the parent of the toolbar. COnsidering perfromance we could just trigger a relayout only when the image size actually changes, e.g.: when the new image is larger or smaller than the old one, or when changing from null to image.
This matches what SWT already does for toolbars ie when a ToolItem's image size changes (or goes from null), the toolbar gets relayouted. So doing the same also for the tolbars parent makes sense to prevent it from being cut off. I have opened a PR with this fix