Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Jayathirth Rao]

Changes are fine.

Thanks,
Jay

> On 11-Jun-2019, at 6:09 PM, Philip Race  wrote:
> 
> Hi,
> 
> I am still looking for a code review on this - needed today !
> 
> -phil.
> 
> 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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Sergey Bylokhov]

Looks fine.

On 11/06/2019 05:39, Philip Race wrote:

Hi,

I am still looking for a code review on this - needed today !

-phil.

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.



--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Mario Torre]

Hi Phil,

Unfortunately I'm not a reviewer on 12 so I won't be able to OK for
you, but the patch looks good to me. We had found a similar issue with
Freetype and also came to the same conclusion that we should have the
rendering mode to version 35 I think.

I agree "better" is subjective, but I think this patch should be in.

Cheers,
Mario

On Tue, Jun 11, 2019 at 2:41 PM Philip Race  wrote:
>
> Hi,
>
> I am still looking for a code review on this - needed today !
>
> -phil.
>
> 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.



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Philip Race]

Hi,

I am still looking for a code review on this - needed today !

-phil.

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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[semyon . sadetsky]

On 6/6/19 9:12 AM, Phil Race wrote:




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.

Why? The test is not hard.



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.

Then you need to remove the label and update evaluation accordingly.




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.

Can you argument your position?
For me it is a bug.



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.

I'm confused again, why it is not our regression?

--Semyon

-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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Phil Race]

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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[semyon . sadetsky]

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.



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?

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?

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.
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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Philip Race]

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.


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. 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. Nothing can be tested and asserted
to be right or wrong. And the algorithms used are outside of our control.
But there is still value in the change to see if more people are happy 
with the

alternative rendering.


-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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Semyon Sadetsky]

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?

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.


--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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Phil Race]

It *can* make a difference and in fact we have a regression test
that now passes with this fix which tests different rendering modes.
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.

-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.

Re: [OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[semyon . sadetsky]

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.

[OpenJDK 2D-Dev] RFR: 8217731: Font rendering and glyph spacing changed from jdk-8 to jdk-11

[Phil Race]

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.