You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Windows Hi-DPI] Progress icon is too big and clipped #706
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.
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.
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.
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.
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
Activity
tmssngr commentedon Jun 27, 2023
@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 commentedon Jun 27, 2023
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 commentedon Jun 27, 2023
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 commentedon Jun 28, 2023
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 commentedon Jun 29, 2023
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 commentedon Nov 21, 2025
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 commentedon Nov 21, 2025
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 commentedon Nov 21, 2025
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 commentedon Dec 4, 2025
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
Phillipus commentedon Dec 19, 2025
@akoch-yatta Thank-you. :-)