[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] 8214481 is actually a regression?
From:       Mario Torre <neugens () redhat ! com>
Date:       2020-04-09 6:55:27
Message-ID: CAJwKKmZ6z1Nz8=FbK=AJ_GVN77gCjY0aktXZ7Z5Y7g-FZQSuDw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Apr 8, 2020 at 8:30 PM Philip Race <philip.race@oracle.com> wrote:
>
> I confess to not being 100% sure which one you thing is in some way
> "unexpected".
>
> I *think* you are complaining only about the large size rendering of
> cambria in 3.png
> BEFORE the fix and that it is equally blurry with or without the fix.

Hi Phil,

First of all, thanks for taking the time to explain both here and on
the bug report.

My surprise after this patch was that the fonts are blurry, while
before the patch they are crisp. I understand that we ask the renderer
to turn off snapping to grid, but my point was "why?" since it creates
"worse" results (the blurry rendering instead of the crisp and
readable one). However, after your explanation on the bug I went ahead
and modified the test case (attached to the bug for reference) and
realised why: it is more correct.

If you run the test case on a JDK 11 without the patch and a JDK15
with the patch it's obvious that in order to keep the fonts aligned
and "clear" with and without LCD smoothing we end up with letters
shifting to place in 11 (due to the snap to grid, they will find the
nearest "block", which also means this is not going to be a consistent
behaviour given the font size), while they keep most of the size
relationship in JDK 15 (the shifting is really still in place
obviously but the fonts are allowed to consume more space so it tends
to be less noticeable and generally they can keep more of the intended
proportion ratio intact).

I don't think this is a difference worth losing sleep over, but I tend
to agree that the blurry font is a side effect I can live with when it
provides a general more precise.

> BTW only 1.png shows JDK version so its not clear what was used to
> render each case.

Yes, because they all render the same, but for clarity they are in
order from the bottom to the top 8, 11, 11 patched.

Cheers,
Mario

--=20
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

[prev in list] [next in list] [prev in thread] [next in thread]