RFR: 8318577: Windows Look-and-Feel JProgressBarUI does not render correctly on 2x UI scale [v2]

[Alexey Ivanov]

On Wed, 22 Jan 2025 07:02:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> JProgressBar (StringPainted variant) does not render consistently on HiDPI displays (e.g. 200% Scale Factor) on Windows (using Windows Look-and-Feel) depending on the height at which JProgressBar is rendered, in which case the gap between progressbar and skin is different for different height as can be seen below
>> 
>> ![image](https://github.com/user-attachments/assets/5552ba7d-f747-4037-9db0-e1554f8b35d9)
>> 
>> Native windows progressbar renders without leaving any gap as can be seen here
>> 
>> ![image](https://github.com/user-attachments/assets/672a5810-1c44-4c22-aef2-93abde536bca)
>> 
>> so the padding is removed to render the progressbar similar to windows native and it is rendered properly
>> 
>> ![image](https://github.com/user-attachments/assets/ecb25140-8df2-47e2-bde5-925eb031bedb)
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   summary update

I don't think it's correct to compare the rendering of progress with visual styles enabled (XPStyle) and without them.

Currently, Windows doesn't allow switching to the classic theme that has no visual styles. The latest version of Windows which had the classic theme was Windows 7.

Your screenshot of a progress bar from the Copy progress dialog in Windows *uses visual styles*.

But you're modifying the rendering in the portion which renders progress bar without XP Style.

The reporter of the bug correctly identified the root cause: *it's rounding error* of the scaling applied — depending on the position of the progress bar as well as its width and height, the thickness of border can become inconsistent. There were quite a few bugs which addressed this problem. The solution used was to reset the scale transform and render all the pixels.

The subject of the bug says “2×” but the attached screenshot demonstrates the problem at 1.75×, according to the filename: `Capture_175scale.png`. The fractional scales are where this rounding errors occur the most, especially at 1.25 and 1.75.

Taking the above into account, I don't think the proposed fix resolves the problem completely. It removes the gap, I believe, it may still be possible to see inconsistencies around edges.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23227#issuecomment-2607873290