Ok, looks fine.
On 2/12/20 7:10 am, Philip Race wrote:
Ignore the comment. I should have deleted that (and will before pushing).
Since we are adding padding on the left, to render the rightmost pixel
of the unpadded image, we need to extend the width by one pixel.
But the padding means that
Ignore the comment. I should have deleted that (and will before pushing).
Since we are adding padding on the left, to render the rightmost pixel
of the unpadded image, we need to extend the width by one pixel.
But the padding means that the image (as seen by the user)
is now being rendered one
Change looks good to me.
And we have good amount of time to notice any pixel accuracy issues.
Thanks,
Jay
> On 12-Feb-2020, at 9:45 AM, Philip Race wrote:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238942
> webrev: http://cr.openjdk.java.net/~prr/8238942/
>
> As discussed in the bug,
Hi, Phil.
Could you please clarify these lines, from the patch it
is unclear what they should do. "Why"
+ glyphInfo->topLeftX -= 1;
+ // WHY NOT ADD ?
+ glyphInfo->width += 1;
On 2/11/20 8:15 pm, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8238942
webrev:
Bug: https://bugs.openjdk.java.net/browse/JDK-8238942
webrev: http://cr.openjdk.java.net/~prr/8238942/
As discussed in the bug, we are missing padding in the code that takes
an LCD glyph from freetype and caches it in the 2D glyph cache.
This padding is used in subpixel positioning with
