Scale the character with the IDE zoom level (fixes #11)

[victorrentea]

Fixes #11.

The problem

ProgressBarUi lays out everything through JBUIScale — the bar height (scale(20)), the corner radii, and even the character's own x/y offsets. The sprites themselves, however, were plain ImageIcons, and an ImageIcon always paints its raster at the natural size.

So the bar grows with the IDE zoom while Mario stays 15×21 forever. At a 150% zoom he covers roughly two thirds of the bar height; in presentation mode (which pushes the zoom higher still) he shrinks to a speck. The Koopa shell in the indeterminate bar has the same problem, and so do the progress bars inside modal dialogs, since they share this UI.

The fix

A small ScaledGifIcon that paints the GIF through the width/height overload of drawImage instead of the natural-size one:

• the animation keeps running — the raster is still a multi-frame Toolkit image driven by the ImageObserver, which is what a repaint-on-frame relies on;
• the size is resolved on every paint rather than cached, because the IDE zoom can be changed while the IDE is running;
• nearest-neighbour interpolation, so the sprites still look like pixel art once they are enlarged instead of turning into a smudge.

ProgressBarUi itself needed no change: its offsets were already scaled, so the characters line up with the bar again on their own.

Before / after

Determinate and indeterminate bars at a 150% IDE zoom on a HiDPI screen:

Before

After

Verification

I rendered the real paintDeterminate / paintIndeterminate off-screen against IntelliJ IDEA 2026.2, at several zoom levels:

IDE zoom	bar height	character	before	after
100%	20 px	Mario	15×21	15×21
150%	30 px	Mario	15×21	23×32
150%	30 px	Shell	16×16	24×24

At 100% zoom on a non-HiDPI screen the rendering is pixel-identical to the current behaviour, so this is not a restyling — only the zoomed cases change.

Notes

• I did not bump the version or touch <change-notes>, since those look like they belong to your release flow — happy to add them if you'd prefer them in the same PR.
• The @2x assets in src/main/resources are still unused. They are not needed for this fix: with nearest-neighbour scaling the 1× sprite upscales to exact pixel blocks whenever the total scale factor is an integer (e.g. 150% zoom × 2 for HiDPI = 3×), which is actually cleaner than resampling the pre-doubled @2x raster by 1.5. Worth a separate discussion if you want them put to use.

🤖 Generated with Claude Code