On Mon, 22 Feb 2021 20:02:30 GMT, Sergey Bylokhov <s...@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:  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
