+1
--Semyon
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.
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
