<Swing Dev> [10] RFR JDK-8191428: Regression: Swing button label wrapping with hidpi

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Nov 21 01:19:06 UTC 2017

Hi, Prasanta.
Is it possible to create an automated test for this issue?
(I think that we were just lucky that Phil found this problem by the demo)

On 20/11/2017 03:26, Prasanta Sadhukhan wrote:
> Hi All,
> Bug: https://bugs.openjdk.java.net/browse/JDK-8191428
> It is seen that with
> 8172025: HiDPI with non-integer scale factor - SPANs in HTML are 
> rendered overlapping each other
> fix, the html text in button is rendered in different lines even though 
> it is specified as a one word.
> This is because with getSpan() returning float value (say 29.9996)
> FlowView.layoutRow() calculates "spanLeft" using getFlowSpan() method 
> which uses "int" calculation (so get 29]
> whereas "chunkSpan" got from GlyphView#getTabbedPane (using 
> GlyphPainter1.getSpan) gets "float" value [ie 29.9996]
> so this calculation (chunkSpan > spanLeft) is satisfied  [ex, 29.996 > 
> 29] and so it calls breakView() to break the text.
> In the proposed fix, I have reverted the getSpan() value to return "int" 
> so as to prevent this regression.
> This fix also does not cause any problem with 8172025 issue which 
> renders fine.
> webrev: 
> http://cr.openjdk.java.net/~psadhukhan/8191428/webrev-1stapproach/webrev.00/ 
> Another approach is to use "float" calculation for all "spans" 
> calculation but that will cause many changes, including changing 
> public/protected method signature
> which I believe is risky at this point of time for jdk10, as it might 
> potentially cause more regressions.
> Sneak peek of 2nd approach changes are:  [work in progress]
> http://cr.openjdk.java.net/~psadhukhan/8191428/webrev-2ndapproach/
> Regards
> Prasanta

Best regards, Sergey.

More information about the swing-dev mailing list