On 6/6/19 9:11 AM, semyon.sadet...@oracle.com wrote:
On 6/5/19 6:43 PM, Philip Race wrote:
On 6/5/19, 4:18 PM, Semyon Sadetsky wrote:
On 6/5/19 2:11 PM, Phil Race wrote:
It *can* make a difference and in fact we have a regression test
that now passes with this fix which tests different rendering modes.
Which test is it? Why you didn't mark it with the bug id?
See https://bugs.openjdk.java.net/browse/JDK-8199529
I only located this bug and verified this "resolves" it after sending
out the review
but it "resolves" it due to luck as much as anything definite, so I
don't think it is
required to link this as "solving" that.
Nice that you made this discovery. Though it was more or less obvious.
So, now you can remove jtreg-hard label from the bug and provide the
reg-test.
Again, no.
However that is not a direct test for this potential difference.
You cannot say that this change *must* make a difference, it
just does. Sometimes.
That's what we need to avoid regression again when fonts are
updated. Font appearance directly affects user experience.
Fortunately this happens not so often but we definitely need a test
that will indicate such changes before the bug is reported
externally like it recently happened. I thin everyone agrees that we
should not repeat this omission once again.
You misunderstand. There was no regression.
Then why is the bug marked as regression?
Not by me. But it is subjective.
There was a change in behaviour
which is completely allowable, and can happen all the time and is
sensitive to
so many things. So there was no omission.
Ok, then why do we need this fix?
To try to improve compatibility of rendering in 13 with what it was like
in 8.
No guarantees but people have reported they prefer it.
Nothing can be tested and asserted
to be right or wrong. And the algorithms used are outside of our
control.
Was it external change in Windows OS that caused the issue? If so, the
bug was incorrectly evaluated. Can you update JBS with the correct one.
No, it was the removal of T2K and the switch to freetype.
-phil.
But there is still value in the change to see if more people are
happy with the
alternative rendering.
--Semyon
-phil
--Semyon
-phil.
On 6/5/19 1:40 PM, semyon.sadet...@oracle.com wrote:
Can you clarify does the change affects font metrics?
I see that it is a sub-pixel difference for each single glyph but
if a long line of text can accumulate a notable difference the reg
test can be provided.
--Semyon
On 6/5/19 11:43 AM, Phil Race wrote:
bug: https://bugs.openjdk.java.net/browse/JDK-8217731
webrev: http://cr.openjdk.java.net/~prr/8217731/
This is intended to "help" but cannot completely cure, with
some of the rendering differences in JDK11 vs JDK 8.
In a typical Swing app on Windows using LCD rendering
it manifests as subtle adjustments in the spacing between glyphs.
There isn't an easy regression test for this, and it is subjective
as to how bad it was before and how much this improves it,
even if you were to accept that 8 is "better" .. and not just
different ..
-phil.
