<Swing Dev> RFR: 8160720: [TEST_BUG] javax/swing/SwingUtilities/TestBadBreak/TestBadBreak.java

[Alexey Ivanov]

On Mon, 22 Feb 2021 20:02:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Since I cannot see the clipping occurs with uiScale=1, the test has to adjust its special size, probably by measuring the text before setting the size.
> 
> I have retested it w/o the fix for JDK-8015085 on the 100% dpi system(w/o uscale option) and the test fails w/o the fix and passed with, so it verify something.

I have run a couple of tests on system with 100% scaling. The unmodified test passes there and it performs the test as intended:
![TestBadBreak at 100%](https://user-images.githubusercontent.com/70774172/108901738-2872cb00-7613-11eb-8574-595c3fc80765.png)

As you can see, the clipping occurs not at the last character, however, it's not required after all.

Yet I cannot explain why uiScale=1 produces different result on the system with 200% scaling. Off the top of my head, the minimum width of the window could be larger on HiDPI system.


> Need to check what goes wrong in the HiDPI case.

But the test fails in HiDPI case. If I use uiScale=2 on the system with 100%, the result is exactly the same as on the system with 200%. If you change the size of the frames manually, the combining case works as expected: as soon as the string does not fit in the width, it gets clipped, two characters “/ä” (or rather two glyphs) are replaced with “…”. But if you slowly change the width of the frame with precomposed character, three characters “3/ä” disappear; if you continue shrinking the frame, there's always a gap between the “…” and the edge of the frame. Yet in the other frame, another character gets clipped only when “…” touches the edge. (I used uiScale=4 for testing, it makes the font larger and it's easier to see the difference.)

So, this is a product bug.

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

PR: https://git.openjdk.java.net/jdk/pull/2502