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

[Sergey Bylokhov]

Looks fine.

On 21/11/2017 01:51, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> I created the automated test testing the fact that if text is broken 
> into multiple lines, then button rendering the text will have its height 
> increased also.
> http://cr.openjdk.java.net/~psadhukhan/8191428/webrev-1stapproach/webrev.01/ 
> 
> 
> Regards
> Prasanta
> On 11/21/2017 6:49 AM, Sergey Bylokhov wrote:
>> 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.