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

[semyon.sadetsky at oracle.com]

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

>
>
> On 6/6/19 9:11 AM, semyon.sadetsky at 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.sadetsky at 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.
>>>>>>
>>>>>
>>
>