<Swing Dev>  RFR JDK-8191428: Regression: Swing button label wrapping with hidpi
semyon.sadetsky at oracle.com
Tue Nov 21 16:08:13 UTC 2017
On 11/21/2017 01:51 AM, 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.
> 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
>> 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.
>>> 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]
More information about the swing-dev