From erik.joelsson at oracle.com  Thu Jan  2 07:57:07 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 2 Jan 2020 08:57:07 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> [15] Review Request: 8235975 Update
 copyright year to match last edit in jdk repository for 2014/15/16/17/18
In-Reply-To: <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com>
References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com>
 <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com>
Message-ID: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com>

Build files look good.

/Erik

On 2019-12-24 19:22, Sergey Bylokhov wrote:
> Hello.
>
> Here is an updated version:
> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
> ? Patch (2 Mb): 
> http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch
> ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/
>
> ?- "jdk.internal.vm.compiler" is removed from the patch.
> ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018"
>
> On 12/22/19 11:24 pm, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for JDK 15.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
>> Patch (2 Mb): 
>> http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch
>> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02
>>
>> I have updated the source code copyrights by the 
>> "update_copyright_year.sh"
>> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017
>> because of: "JDK-8187443: Forest Consolidation: Move files to unified 
>> layout"
>> which touched all files.
>>
>>
>
>

From Sergey.Bylokhov at oracle.com  Thu Jan  2 12:02:14 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 2 Jan 2020 15:02:14 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [15] Review Request: 8235975 Update
 copyright year to match last edit in jdk repository for 2014/15/16/17/18
In-Reply-To: <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com>
References: <1e7d0395-fc57-4d5b-9cfa-c33e0f6462d5@oracle.com>
 <3460a6f6-6178-cc45-5840-0f215eebc53f@oracle.com>
 <7b67e39d-752c-50a8-8e18-9a8f86bd641c@oracle.com>
Message-ID: <0caab700-28e3-16e7-db00-b698557443f0@oracle.com>

I guess it is too late to fix it, will need to update the files at the end of 2020.

On 1/2/20 10:57 am, Erik Joelsson wrote:
> Build files look good.
> 
> /Erik
> 
> On 2019-12-24 19:22, Sergey Bylokhov wrote:
>> Hello.
>>
>> Here is an updated version:
>> ? Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
>> ? Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.03/open.patch
>> ? Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.03/
>>
>> ?- "jdk.internal.vm.compiler" is removed from the patch.
>> ?- "Aes128CtsHmacSha2EType.java" is updated to "Copyright (c) 2018"
>>
>> On 12/22/19 11:24 pm, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for JDK 15.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8235975
>>> Patch (2 Mb): http://cr.openjdk.java.net/~serb/8235975/webrev.02/open.patch
>>> Fix: http://cr.openjdk.java.net/~serb/8235975/webrev.02
>>>
>>> I have updated the source code copyrights by the "update_copyright_year.sh"
>>> script for 2014/15/16/18/19 years, unfortunately, cannot run it for 2017
>>> because of: "JDK-8187443: Forest Consolidation: Move files to unified layout"
>>> which touched all files.
>>>
>>>
>>
>>


-- 
Best regards, Sergey.

From christoph.langer at sap.com  Mon Jan  6 22:32:52 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 6 Jan 2020 22:32:52 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when
 fontconfig.properties was used
In-Reply-To: <DB8PR02MB5547A0B57080BAA3E578C71D8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
References: <d741c0c4e6305a8f7abfbeaa675bd645@linux.vnet.ibm.com>
 <AM6PR02MB51924907C429846DEBE14DF98A9B0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com>
 <AM6PR02MB519284629C4998C1CB876F108A9A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <5D9CB3F8.9070205@oracle.com>
 <ffeb92a47867fc4358cd32234d023506@linux.vnet.ibm.com>
 <cd36eb93912d9ada00c6d98577421ac6@linux.vnet.ibm.com>
 <AM6PR02MB4801FEA742BC257853715D318A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <d59e8be7-30e4-fade-25ff-50b5175a40bc@oracle.com>
 <DB8PR02MB55474C1E88EE3AEF8B5720C88A530@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <4cd9707f-ad4e-57db-2d3d-3ed1757f95e9@oracle.com>
 <DB8PR02MB554775727D59605A49B1B5A88A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <bfb767ad-76f2-ea39-1e38-cea9657180dc@oracle.com>
 <DB8PR02MB55477062EB2C53F4384083208A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <dc830333-d0e3-f5e7-7ded-0b51accb692c@oracle.com>
 <DB8PR02MB5547A0B57080BAA3E578C71D8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
Message-ID: <AM6PR02MB4984D2CCCB463A11DEBCDD218A3C0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Phil,

now that the holiday season is over? where are we going with this? It ran through a lot of our testing in the last weeks and I?m quite convinced that the change is ok. I didn?t see regressions.

And as for the tracing modifications in src/java.desktop/share/classes/sun/font/TrueTypeFont.java, I still don?t get in which way they?d be problematic.

Please let me know what to do to bring this one forward ??

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 19. Dezember 2019 22:48
To: Phil Race <philip.race at oracle.com>; Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
Cc: 2d-dev at openjdk.java.net
Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

I still might not fully get it?

So, the call to AccessController.doPrivileged() with a PrivilegedExceptionAction might eventually yield a PrivilegedActionException which I catch and handle (as before the NPE). The only thing that differs now is that I don?t handle NPE any more. I was thinking that the only possible source of NPE was when raf is null. That can?t happen now any more because ?new RandomAccessFile? either delivers an Object or throws. But maybe a more defensive approach would be to still handle NPE in case it occurs for whatever other reason?

So, generally, I?m running this patch fine through all our platform testing. I agree that it should be pushed to client-dev and not rushed into 14. Maybe that would give enough test coverage and time to bake?

/Christoph

From: Phil Race <philip.race at oracle.com<mailto:philip.race at oracle.com>>
Sent: Donnerstag, 19. Dezember 2019 21:59
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com<mailto:takiguc at linux.vnet.ibm.com>>
Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

Here you are seeing the exception during initialisation but if the font is in use
we might get an exception handed to native code when it has not had to deal
with that. We should check that code and if it is ready to deal with pending
exceptions. Other JNI calls in native will fail if it is not and the exception will
ultimately propagate back to the original Java code. It all needs to be looked through for problems.

-phil.
On 12/19/19 12:39 PM, Langer, Christoph wrote:
I don?t understand what?s intriguing you with that code, please help me?

It was done like this before, e.g. the RandomAccessFile was opened in the privileged block. But before you?d only see a null reference coming out in case something went wrong. Now you?d have the FileNotFoundException at hand to be able to trace this detail? Are you concerned that this information could be leaked out of the Privileged block when it shouldn?t?

/Christoph

From: Phil Race <philip.race at oracle.com><mailto:philip.race at oracle.com>
Sent: Donnerstag, 19. Dezember 2019 21:04
To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>
Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

This makes me very nervous because it is up-called from native code.
I am not sure I would want this change in any release ...

317             try {

 318                 RandomAccessFile raf = AccessController.doPrivileged(

 319                     new PrivilegedExceptionAction<RandomAccessFile>() {

 320                         public RandomAccessFile run() throws FileNotFoundException {

 321                             return new RandomAccessFile(platName, "r");

-phil.

On 12/19/19 12:01 PM, Langer, Christoph wrote:

Hi Phil,



Type 1 fonts were available but got skipped.



/Christoph



-----Original Message-----

From: Phil Race <philip.race at oracle.com><mailto:philip.race at oracle.com>

Sent: Donnerstag, 19. Dezember 2019 20:58

To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; Ichiroh Takiguchi

<takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>

Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen

when fontconfig.properties was used



Hi,



If this can get reviewed, I intend to push this fix to JDK14.



Not for 14. This will take some time to review and test and is too risky at this

stage.



You say no TrueType fonts are installed, does that mean there are no

scaleable fonts at all,

or are there Type 1 fonts we are skipping over ?



-phil.







On 12/18/19 6:31 AM, Langer, Christoph wrote:

Hi,



sorry for the long time that it took me to come back to this item.



I eventually spent quite a significant amount of time analyzing what's going

wrong here. At least, I have a few AIX LPARs, where we would always

encounter this type of Exception:



Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:

class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont

(sun.font.CompositeFont and sun.font.PhysicalFont are in module

java.desktop of loader 'bootstrap')

         at

java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontMa

nager.java:1081)

         at

java.desktop/sun.font.SunFontManager.initialiseDeferredFont(SunFontMan

ager.java:960)

         at

java.desktop/sun.font.SunFontManager.findOtherDeferredFont(SunFontM

anager.java:898)

         at

java.desktop/sun.font.SunFontManager.findDeferredFont(SunFontManager

.java:914)

         at

java.desktop/sun.font.SunFontManager.findFont2D(SunFontManager.java:2

105)

         ...



The problem on our systems is triggered by two factors. First is that the

font configuration file contains paths to font files that don't exist. Secondly,

the system's fontconfig has no TrueType Fonts installed. Now, during loading

of fonts, it goes over these non-existing font files and tries to mark their

initialization in sun.font.SunFontManager::initialiseDeferredFont(String

fileNameKey) by adding the key into the initialisedFonts map. Since there is

no font handle available because the font couldn't be loaded but the map's

value must not be null, it wants to use the handle of the default physical

font. So, calling getDefaultPhysicalFont at this place triggers findFont2D and

then recursive calls into

initialiseDeferredFont/getDefaultPhysicalFont/findFont2D until a matching

default physical font was loaded. But it's quite indeterministic which font is

returned at what place in findFont2D when the recursion is unwinded, so this

ClassCastException occurs.



I propose to fix this by adding a "NULL FONT HANDLE" to use in

initialisedFonts for fonts that can?t be loaded. This will remove the recursion

during loading of fonts. And afterwards a default physical font can then still

be resolved, even if our font configuration contains less fonts (no true type

fonts).



In my change I also add small improvements to the exception cases when

trying to load non-existent true type fonts and to method

getDefaultPhysicalFont.



The test exercises font loading and it would demonstrate the issue without

the fix on several of our AIX systems.



Here is the webrev:

http://cr.openjdk.java.net/~clanger/webrevs/8221741.0/



@Ichiroh-san: Can you test this fix in your environment and let me know if

it fixes your issue?



I'll run a full platform test here at SAP, including JDK11.



If this can get reviewed, I intend to push this fix to JDK14.



Thanks & Best regards

Christoph



-----Original Message-----

From: Phil Race <philip.race at oracle.com><mailto:philip.race at oracle.com>

Sent: Mittwoch, 30. Oktober 2019 17:07

To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; Ichiroh Takiguchi

<takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com><mailto:arno.zeller at sap.com>

Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen

when fontconfig.properties was used



Yes probably best if this is reviewed and approved by someone who

has access to AIX. I have no idea if the XLFDs are even correct ...



-phil.



On 10/30/19 8:00 AM, Langer, Christoph wrote:

Hi Ichiroh,



I'm currently observing a test issue on one of our AIX boxes with that

patch

in place. Please give me some time to have a closer look...

Best regards

Christoph



-----Original Message-----

From: 2d-dev <2d-dev-bounces at openjdk.java.net><mailto:2d-dev-bounces at openjdk.java.net> On Behalf Of

Ichiroh

Takiguchi

Sent: Montag, 28. Oktober 2019 17:59

To: Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com><mailto:arno.zeller at sap.com>

Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException

happen

when fontconfig.properties was used



Hello Phil and other reviewers.



I appreciate if you give me your comment and suggestion.



Thanks,

Ichiroh Takiguchi



On 2019-10-15 20:33, Ichiroh Takiguchi wrote:

Hello Phil.



Sorry for bad response.



AIX is following case, but physical font is not defined by default.

If you have fonts installed and have a custom fontconfig.properties

file for AIX

which references those, then you should be able to get a default

font

from that

set of known existent physical fonts.

Please try following steps to emulate same kind this on linux (RHEL7).

1. Download DefaultFontTestA.java and fontconfig.properties files

     Please modify fontconfig.properties if c0419bt_.pfb is not in

/usr/share/X11/fonts/Type1 directory.



2. Compile and run with following options and environment variable.

      $ javac --add-exports java.desktop/sun.font=ALL-UNNAMED

DefaultFontTestA.java

      $ USE_J2D_FONTCONFIG=no java --add-opens

java.desktop/sun.font=ALL-UNNAMED

-Dsun.awt.fontconfigfontconfig.properties DefaultFontTestA

      defaultFontName=Dialog

      defaultFontFileName=/dialog.ttf

      Exception in thread "main" java.lang.ClassCastException: class

sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont

(sun.font.CompositeFont and sun.font.PhysicalFont are in module

java.desktop of loader 'bootstrap')

              at





java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontMa

nager.java:1081)

              at DefaultFontTestA.main(DefaultFontTestA.java:48)



         Font2D font2d =

              findFont2D(getDefaultFontFaceName(), Font.PLAIN,

NO_FALLBACK);

    Note:

      USE_J2D_FONTCONFIG is defined into

src/java.desktop/unix/native/common/awt/fontpath.c

      Dialog and /dialog.ttf are defined into

src/java.desktop/unix/classes/sun/awt/FcFontManager.java



getDefaultFontFaceName returns defaultFontName, it's "Dialog".

findFont2D() returns Dialog CompositeFont instead of physical font.

I think we cannot control return value for

physicalFonts.values().iterator();

"defaultPhysicalFont = ((CompositeFont) font2d).getSlotFont(0);" is

useful.



Please give me your comment.



Thanks,

Ichiroh Takiguchi



On 2019-10-09 01:06, Philip Race wrote:

I think this needs a little bit more explanation first.

Systems without fontconfig ... meaning without libfontconfig.

So does that mean you just can't find fonts or have none installed ?

If you have fonts installed and have a custom fontconfig.properties

file for AIX

which references those, then you should be able to get a default

font

from that

set of known existent physical fonts.



If you have neither .. then you have a system configuration problem

and without

a physical font installed avoiding an exception here isn't really

going to help you

get much further. Perhaps we should throw InternalError a bit

earlier.

I see no point in trying to survive ..



-phil





On 10/8/19, 12:35 AM, Langer, Christoph wrote:

Hi Ichiroh,



thanks for the update. It looks good to me. I'll run it through test

system tonight and let you know if we see issues by tomorrow.

Should

you not hear back from me, consider it as reviewed and tested ??



Thanks

Christoph



-----Original Message-----

From: Ichiroh Takiguchi<takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>

Sent: Montag, 7. Oktober 2019 19:16

To: Langer, Christoph<christoph.langer at sap.com><mailto:christoph.langer at sap.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Zeller,

Arno<arno.zeller at sap.com><mailto:arno.zeller at sap.com>

Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException

happen

when fontconfig.properties was used



Hello Christoph.



I appreciate your suggestion.

JTreg testcase could throw ClassCastException instead of

InvocationTargetException.

JTreg results were in JDK-8221741



Bug:    https://bugs.openjdk.java.net/browse/JDK-8221741

Change:

https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/

Could you review the fix ?



Thanks,

Ichiroh Takiguchi

IBM Japan, Ltd.



On 2019-10-07 22:53, Langer, Christoph wrote:

Hi Ichiroh,



this is great, thanks for doing this. We regularly see this and

just

stumbled over it the other day where the fontconfig of our test

user

was corrupted somehow.



As for the test, I would reduce the amount of reflection a little

bit.

It should not be necessary to access SunFontManager via

Class.forName,

you already exported it to the test via the @modules statement.

You

can probably use this coding (please try as I didn't test it??):



           SunFontManager sfm = SunFontManager.getInstance();

           Field defaultFontName_fid =

SunFontManager.class.getDeclaredField("defaultFontName");

           defaultFontName_fid.setAccessible(true);

           defaultFontName_fid.set(sfm, "Dialog");

           Method loadFonts_mid =

SunFontManager.class.getDeclaredMethod("loadFonts");

           loadFonts_mid.setAccessible(true);

           loadFonts_mid.invoke(sfm);

           PhysicalFont physicalFont = sfm.getDefaultPhysicalFont();

           System.out.println(physicalFont);



If you want, I can run your (updated) patch through our test

system.



Thanks

Christoph





-----Original Message-----

From: 2d-dev<2d-dev-bounces at openjdk.java.net><mailto:2d-dev-bounces at openjdk.java.net>  On Behalf

Of

Ichiroh

Takiguchi

Sent: Montag, 7. Oktober 2019 09:33

To: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>

Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException

happen

when

fontconfig.properties was used



Hello.



Could you review the fix ?



Bug:    https://bugs.openjdk.java.net/browse/JDK-8221741

Change:

https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/

JTreg testcase and results are including JDK-8221741 [1].



[1] https://bugs.openjdk.java.net/browse/JDK-8221741



Thanks,

Ichiroh Takiguchi

IBM Japan, Ltd.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200106/749ba267/attachment-0001.htm>

From linuxhippy at gmail.com  Thu Jan  9 08:51:36 2020
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 9 Jan 2020 09:51:36 +0100
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering huge
	lines"
Message-ID: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>

Hi,

Please review the fix for bug 8235904 "Infinite loop when rendering
huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/

The issue was caused by integer overflow during clipping: While the
original native code used int or long depending on the coordinate
range, the java-port unconditionally always used ints - which led to
the issue.
The code was ported to java back then to avoid JNI overhead.

A big thanks to Mario Torre for analyzing the issue in detail and
bringing it to my attention.

Thanks, Clemens

From djgredler at gmail.com  Fri Jan 10 04:48:02 2020
From: djgredler at gmail.com (Daniel Gredler)
Date: Thu, 9 Jan 2020 23:48:02 -0500
Subject: [OpenJDK 2D-Dev] Fixing JDK-8231556 and JDK-8214536
In-Reply-To: <CAPA+ug4UyKNd6DTLwO6n=Nftn6HAx8OC9_jHJSpds2sVHRjUdQ@mail.gmail.com>
References: <CAPA+ug4UyKNd6DTLwO6n=Nftn6HAx8OC9_jHJSpds2sVHRjUdQ@mail.gmail.com>
Message-ID: <CAPA+ug4xfDU=h-mX8=u4kxLJZKeX-5hEsEFyzD20z8ijdoX_ow@mail.gmail.com>

Hi Phil,

I see on JIRA that you had a look at the drawString / fractional metrics
issues [1] right before Christmas break. Is there anything I can do to
help? Test cases, documentation, follow-up investigation... just let me
know.

Take care,

Daniel

[1] https://bugs.openjdk.java.net/browse/JDK-8224109



On Wed, Nov 20, 2019 at 7:51 PM Daniel Gredler <djgredler at gmail.com> wrote:

> Hi all,
>
> I've run into both of these issues in JDK 11 and later:
>
> https://bugs.openjdk.java.net/browse/JDK-8231556 (Wrong font ligatures
> used when 2 versions of same font used)
> https://bugs.openjdk.java.net/browse/JDK-8214536 (Incorrect text
> rendering with fractional font metrics and transform; dupe of 8199537)
>
> Would either of these bugs be a good candidate for a project newcomer
> (like myself) to fix? I see they're both assigned to Phil Race... not sure
> if Phil has already started working on them or has any insights as to where
> to start digging?
>
> Thanks!
>
> Daniel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200109/3b905301/attachment.htm>

From neugens at redhat.com  Fri Jan 10 16:33:39 2020
From: neugens at redhat.com (Mario Torre)
Date: Fri, 10 Jan 2020 17:33:39 +0100
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
	huge lines"
In-Reply-To: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
Message-ID: <CAJwKKmbsWPPdUgQM=i-v2bv+A=d5fugarko9XLKaCvYO8EKAvw@mail.gmail.com>

Hi Clemens,

Thanks for the patch, the fix looks good to me. I'm not a reviewer
however so I can't approve the push...

Cheers,
Mario



On Thu, Jan 9, 2020 at 9:51 AM Clemens Eisserer <linuxhippy at gmail.com> wrote:
>
> Hi,
>
> Please review the fix for bug 8235904 "Infinite loop when rendering
> huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/
>
> The issue was caused by integer overflow during clipping: While the
> original native code used int or long depending on the coordinate
> range, the java-port unconditionally always used ints - which led to
> the issue.
> The code was ported to java back then to avoid JNI overhead.
>
> A big thanks to Mario Torre for analyzing the issue in detail and
> bringing it to my attention.
>
> Thanks, Clemens
>


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


From philip.race at oracle.com  Fri Jan 10 17:33:33 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 10 Jan 2020 09:33:33 -0800
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
 huge lines"
In-Reply-To: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
Message-ID: <5E18B56D.7060101@oracle.com>

Is there a regression test ?
I don't see a noreg- label.

-phil.

On 1/9/20, 12:51 AM, Clemens Eisserer wrote:
> Hi,
>
> Please review the fix for bug 8235904 "Infinite loop when rendering
> huge lines": http://cr.openjdk.java.net/~ceisserer/8235904/webrev.01/
>
> The issue was caused by integer overflow during clipping: While the
> original native code used int or long depending on the coordinate
> range, the java-port unconditionally always used ints - which led to
> the issue.
> The code was ported to java back then to avoid JNI overhead.
>
> A big thanks to Mario Torre for analyzing the issue in detail and
> bringing it to my attention.
>
> Thanks, Clemens

From philip.race at oracle.com  Fri Jan 10 21:33:18 2020
From: philip.race at oracle.com (Philip Race)
Date: Fri, 10 Jan 2020 13:33:18 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8224109: Text spaced incorrectly by
 drawString under rotation with fractional metrics
Message-ID: <5E18ED9E.6040708@oracle.com>


Bug: https://bugs.openjdk.java.net/browse/JDK-8224109
Webrev: http://cr.openjdk.java.net/~prr/8224109/

There have been at least a couple of reports on this problem which manifests
when using fractional metrics.

As noted in the bug eval
- we had the wrong sign for the y advance in this path
-  the wrong transform component was being used for the rotation.

The fix is quite small but creating a regression test  was a challenge
to be able to reliably tell where the rendering landed and if it
was the same for different APIs and that it goes in an "expected" direction.

I found one new bug 8236451with a laid out glyphvector which is
not fixed here because it is a harfbuzz code path problem.

Also we have known issues with AAT fonts and harfbuzz so  using
Courier New on mac.

Not to mention Macos Mojave wants to do AA text even when you
ask for B&W (bug open on that too) so it is really hard to verify in 
that case.

-phil.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200110/64b62ad4/attachment.htm>

From linuxhippy at gmail.com  Sat Jan 11 20:40:00 2020
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Sat, 11 Jan 2020 21:40:00 +0100
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
 huge lines"
In-Reply-To: <5E18B56D.7060101@oracle.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
 <5E18B56D.7060101@oracle.com>
Message-ID: <CAFvQSYR2hTZP9uuTgQdoc8VMO58L-RL7vLUZP4RBPt-ffk-TwA@mail.gmail.com>

Hi Phil,

> Is there a regression test ?
> I don't see a noreg- label.

Sorry I forgot to mention, the regression test is in the "main"
directory of the bugfix:
http://cr.openjdk.java.net/~ceisserer/8235904/

Thanks and best regards, Clemens

From Sergey.Bylokhov at oracle.com  Sun Jan 12 00:12:32 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 11 Jan 2020 16:12:32 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8224109: Text spaced incorrectly by
 drawString under rotation with fractional metrics
In-Reply-To: <5E18ED9E.6040708@oracle.com>
References: <5E18ED9E.6040708@oracle.com>
Message-ID: <1e5bd3b7-7e98-81f8-6854-07e982b82f01@oracle.com>

Look fine.

On 1/10/20 1:33 pm, Philip Race wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8224109
> Webrev: http://cr.openjdk.java.net/~prr/8224109/
> 
> There have been at least a couple of reports on this problem which manifests
> when using fractional metrics.
> 
> As noted in the bug eval
> - we had the wrong sign for the y advance in this path
> -? the wrong transform component was being used for the rotation.
> 
> The fix is quite small but creating a regression test? was a challenge
> to be able to reliably tell where the rendering landed and if it
> was the same for different APIs and that it goes in an "expected" direction.
> 
> I found one new bug 8236451with a laid out glyphvector which is
> not fixed here because it is a harfbuzz code path problem.
> 
> Also we have known issues with AAT fonts and harfbuzz so? using
> Courier New on mac.
> 
> Not to mention Macos Mojave wants to do AA text even when you
> ask for B&W (bug open on that too) so it is really hard to verify in that case.
> 
> -phil.
> 
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Sun Jan 12 19:54:28 2020
From: philip.race at oracle.com (Phil Race)
Date: Sun, 12 Jan 2020 11:54:28 -0800
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
	huge lines"
In-Reply-To: <CAFvQSYR2hTZP9uuTgQdoc8VMO58L-RL7vLUZP4RBPt-ffk-TwA@mail.gmail.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
 <5E18B56D.7060101@oracle.com>
 <CAFvQSYR2hTZP9uuTgQdoc8VMO58L-RL7vLUZP4RBPt-ffk-TwA@mail.gmail.com>
Message-ID: <A6C6EFEC-5D6D-46ED-9C72-9901F99FE054@oracle.com>

Hi Clemens,

That needs reworking in location as well as adding jtreg boiler plate and legal notice. Also there are code changes required to be a well behaved test. I need to sit in front of a headful Linux system to test those so I will have to follow up on this (hopefully) tomorrow.

-Phil.

> On Jan 11, 2020, at 12:40 PM, Clemens Eisserer <linuxhippy at gmail.com> wrote:
> 
> Hi Phil,
> 
>> Is there a regression test ?
>> I don't see a noreg- label.
> 
> Sorry I forgot to mention, the regression test is in the "main"
> directory of the bugfix:
> http://cr.openjdk.java.net/~ceisserer/8235904/
> 
> Thanks and best regards, Clemens


From dmitry.batrak at jetbrains.com  Mon Jan 13 09:25:15 2020
From: dmitry.batrak at jetbrains.com (Dmitry Batrak)
Date: Mon, 13 Jan 2020 12:25:15 +0300
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font rendering
 on Windows with subpixel antialiasing
Message-ID: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>

Hello,

I'd like to submit a patch for JDK-8236996. I'm not a Committer, so I'll
need someone to sponsor this change.

Issue:  https://bugs.openjdk.java.net/browse/JDK-8236996
Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/

The problem described in JDK-8236996 is from a group of issues (see also
e.g. JDK-8078382 and JDK-8192972), where JDK
uses one font to perform char-to-glyph conversion, but GDI, when asked to
render the glyph is picking a different font,
leading to completely random glyphs being rendered, as char-to-glyph
mapping obviously differs for different fonts.

Specific version of Roboto font, mentioned in JDK-8236996, is most probably
causing the issue because it's not following
the naming guidelines from OpenType specification (
https://docs.microsoft.com/en-us/typography/opentype/spec/name),
having more than 4 variants (regular, bold, italic and bold italic) with
the same 'Font Family name' (name ID = 1). So,
GDI gets confused and picks Roboto Black for rendering, when asked to
choose a regular font from Roboto family (Roboto
Black having weight of 400, just like Roboto Regular, probably adds to the
confusion).

But the reasoning, given above, about the issue cause is only a guess. GDI
is not an open-source subsystem, so we cannot
know for sure how it selects the font for rendering, and cannot implement
matching logic in JDK. Ideally, we'd want to
select the font by specifying its file path, but that's not possible with
GDI. Luckily, it allows us to query file data
for the selected font using GetFontData function
(
https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata),
which we can use to validate that the
selected font is the one we need.

The proposed solution is to check the file size of the font, selected by
GDI, before using it for rendering. If a mismatch
is detected, fallback to FreeType is performed. It can produce a somewhat
different glyph representation, but, at least,
the correct glyph will be rendered. For members of font collections, file
size for validation is calculated in a special
way, in accordance with GetFontData logic described in the documentation.
I've verified that it works for font collections
bundled with Windows 10.

As for performance impact, during testing I didn't observe average glyph
generation time increase of more than 15%.
Taking glyph caching into account, it shouldn't be that significant for
typical UI applications, I think. Performance
impact can be made even smaller - by performing the validation only once
per font, but, I believe, having a Java
application always render correct glyphs (even if fonts are added or
removed while application is running) is more
important.

Proposed patch doesn't add any tests, as reproducing the issue requires
installation of fonts. Existing automated
OpenJDK tests pass after the fix. Proposed approach has been used in
JetBrains Runtime without known issues for about 3
months in testing and for about 1 month in production.

Best regards,
Dmitry Batrak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200113/88db23d6/attachment.htm>

From philip.race at oracle.com  Mon Jan 13 20:08:06 2020
From: philip.race at oracle.com (Phil Race)
Date: Mon, 13 Jan 2020 12:08:06 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
Message-ID: <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>

So this is a workaround for a buggy font that doesn't play well with GDI ?

It does rely on the fonts always being different sizes which is highly 
likely if not guaranteed.
I suppose it is OK so long as we aren't getting any "false" positives.

What I mean is that almost no one will have these Roboto fonts 
installed, so the fix
is solving a problem they don't have, but if it is wrong in some way, 
then they could lose
GDI rendering of LCD glyphs and that could affect a lot of people.

So have you tested this with the full set of Windows 10 fonts - 
including Indic, CJK, etc? - to be sure
there are no cases where it fails for these or other spurious failures.

 > As for performance impact, during testing I didn't observe average 
glyph generation time increase of more than 15%.

Since you aren't retrieving the data, just asking what the size is, I'd 
expect it to be unmeasurable.

-phil.

On 1/13/20 1:25 AM, Dmitry Batrak wrote:
> Hello,
>
> I'd like to submit a patch for JDK-8236996. I'm not a Committer, so 
> I'll need someone to sponsor this change.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
> Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
>
> The problem described in JDK-8236996 is from a group of issues (see 
> also e.g. JDK-8078382 and JDK-8192972), where JDK
> uses one font to perform char-to-glyph conversion, but GDI, when asked 
> to render the glyph is picking a different font,
> leading to completely random glyphs being rendered, as char-to-glyph 
> mapping obviously differs for different fonts.
>
> Specific version of Roboto font, mentioned in JDK-8236996, is most 
> probably causing the issue because it's not following
> the naming guidelines from OpenType specification 
> (https://docs.microsoft.com/en-us/typography/opentype/spec/name),
> having more than 4 variants (regular, bold, italic and bold italic) 
> with the same 'Font Family name' (name ID = 1). So,
> GDI gets confused and picks Roboto Black for rendering, when asked to 
> choose a regular font from Roboto family (Roboto
> Black having weight of 400, just like Roboto Regular, probably adds to 
> the confusion).
>
> But the reasoning, given above, about the issue cause is only a guess. 
> GDI is not an open-source subsystem, so we cannot
> know for sure how it selects the font for rendering, and cannot 
> implement matching logic in JDK. Ideally, we'd want to
> select the font by specifying its file path, but that's not possible 
> with GDI. Luckily, it allows us to query file data
> for the selected font using GetFontData function
> (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata), 
> which we can use to validate that the
> selected font is the one we need.
>
> The proposed solution is to check the file size of the font, selected 
> by GDI, before using it for rendering. If a mismatch
> is detected, fallback to FreeType is performed. It can produce a 
> somewhat different glyph representation, but, at least,
> the correct glyph will be rendered. For members of font collections, 
> file size for validation is calculated in a special
> way, in accordance with GetFontData logic described in the 
> documentation. I've verified that it works for font collections
> bundled with Windows 10.
>
> As for performance impact, during testing I didn't observe average 
> glyph generation time increase of more than 15%.
> Taking glyph caching into account, it shouldn't be that significant 
> for typical UI applications, I think. Performance
> impact can be made even smaller - by performing the validation only 
> once per font, but, I believe, having a Java
> application always render correct glyphs (even if fonts are added or 
> removed while application is running) is more
> important.
>
> Proposed patch doesn't add any tests, as reproducing the issue 
> requires installation of fonts. Existing automated
> OpenJDK tests pass after the fix. Proposed approach has been used in 
> JetBrains Runtime without known issues for about 3
> months in testing and for about 1 month in production.
>
> Best regards,
> Dmitry Batrak


From dmitry.batrak at jetbrains.com  Tue Jan 14 16:14:53 2020
From: dmitry.batrak at jetbrains.com (Dmitry Batrak)
Date: Tue, 14 Jan 2020 19:14:53 +0300
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
Message-ID: <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>

> So this is a workaround for a buggy font that doesn't play well with GDI ?

This is a workaround for all cases (or the vast majority of them) of broken
rendering reported by our customers. The case with Roboto is just the one we
have steps to reproduce for. There can be other cases where GDI's logic is
not
matched by JDK. Even if all of them are caused by 'mis-constructed' fonts,
I'm
afraid, this will not be considered as a good excuse by our customers, as
only
Java applications have such problems with these fonts.

See JDK-8192972, still unsolved in OpenJDK, as an example of the problems
which
will be, at least partially, solved with this fix (correct glyphs will be
rendered, albeit using FreeType).

I did test the fix with fonts preinstalled in Windows 10. Fallback was
actually
triggered for one font (bold italic 'Segoe UI Semibold'), which is not a
'false'
positive, but actually a manifestation of another JDK bug from the same
family -
I've just raised https://bugs.openjdk.java.net/browse/JDK-8237085 for it.
That's
yet another example of an issue which will be (mostly) solved by the
proposed
fix.

Using file length as a 'checksum' certainly doesn't guarantee we choose the
right font, but the probability of error is very low, and this value seems
to be
the best candidate in our circumstances in terms of cost vs. benefit. Even
if
the validation mistreats a different font (having the same length) as a
correct
one, we'll not be in a worse position than before.

Of course, there's a certain risk that rendering for unaffected fonts might
change, but, given quite straightforward contract of GetFontData function, I
would consider it very low.

> Since you aren't retrieving the data, just asking what the size is, I'd
expect
> it to be unmeasurable.

Well, we don't know how GetFontData works exactly, but it does seem to add
some
overhead. On my Windows 10 machine OpenJDK with the proposed fix yields
about 7%
larger result for the following benchmark program. The reported value does
fluctuate from run to run, but the impact of the fix seems to be larger
than the
fluctuations.

--- Benchmark source code ----
import java.awt.*;
import java.awt.font.GlyphVector;
import java.awt.image.BufferedImage;

public class PerfTestOneFont {
    private static final Font FONT = new Font("Segoe UI", Font.PLAIN, 12);

    public static void main(String[] args) {
        FONT.getFamily(); // preload font

        BufferedImage image = new BufferedImage(1, 1,
BufferedImage.TYPE_INT_RGB);
        Graphics2D g = image.createGraphics();
        g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
                  RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
        int glyphCount = FONT.getNumGlyphs();
        long startTime = System.currentTimeMillis();
        for (int glyphCode = 0; glyphCode < glyphCount; glyphCode++) {
            GlyphVector gv =
FONT.createGlyphVector(g.getFontRenderContext(),
                                       new int[]{glyphCode});
            g.drawGlyphVector(gv, 0, 0);
        }
        long endTime = System.currentTimeMillis();
        g.dispose();
        System.out.println(endTime - startTime);
    }
}
------------------------------

Best regards,
Dmitry Batrak

On Mon, Jan 13, 2020 at 11:09 PM Phil Race <philip.race at oracle.com> wrote:

> So this is a workaround for a buggy font that doesn't play well with GDI ?
>
> It does rely on the fonts always being different sizes which is highly
> likely if not guaranteed.
> I suppose it is OK so long as we aren't getting any "false" positives.
>
> What I mean is that almost no one will have these Roboto fonts
> installed, so the fix
> is solving a problem they don't have, but if it is wrong in some way,
> then they could lose
> GDI rendering of LCD glyphs and that could affect a lot of people.
>
> So have you tested this with the full set of Windows 10 fonts -
> including Indic, CJK, etc  - to be sure
> there are no cases where it fails for these or other spurious failures.
>
>  > As for performance impact, during testing I didn't observe average
> glyph generation time increase of more than 15%.
>
> Since you aren't retrieving the data, just asking what the size is, I'd
> expect it to be unmeasurable.
>
> -phil.
>
> On 1/13/20 1:25 AM, Dmitry Batrak wrote:
> > Hello,
> >
> > I'd like to submit a patch for JDK-8236996. I'm not a Committer, so
> > I'll need someone to sponsor this change.
> >
> > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
> > Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
> >
> > The problem described in JDK-8236996 is from a group of issues (see
> > also e.g. JDK-8078382 and JDK-8192972), where JDK
> > uses one font to perform char-to-glyph conversion, but GDI, when asked
> > to render the glyph is picking a different font,
> > leading to completely random glyphs being rendered, as char-to-glyph
> > mapping obviously differs for different fonts.
> >
> > Specific version of Roboto font, mentioned in JDK-8236996, is most
> > probably causing the issue because it's not following
> > the naming guidelines from OpenType specification
> > (https://docs.microsoft.com/en-us/typography/opentype/spec/name),
> > having more than 4 variants (regular, bold, italic and bold italic)
> > with the same 'Font Family name' (name ID = 1). So,
> > GDI gets confused and picks Roboto Black for rendering, when asked to
> > choose a regular font from Roboto family (Roboto
> > Black having weight of 400, just like Roboto Regular, probably adds to
> > the confusion).
> >
> > But the reasoning, given above, about the issue cause is only a guess.
> > GDI is not an open-source subsystem, so we cannot
> > know for sure how it selects the font for rendering, and cannot
> > implement matching logic in JDK. Ideally, we'd want to
> > select the font by specifying its file path, but that's not possible
> > with GDI. Luckily, it allows us to query file data
> > for the selected font using GetFontData function
> > (
> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata),
>
> > which we can use to validate that the
> > selected font is the one we need.
> >
> > The proposed solution is to check the file size of the font, selected
> > by GDI, before using it for rendering. If a mismatch
> > is detected, fallback to FreeType is performed. It can produce a
> > somewhat different glyph representation, but, at least,
> > the correct glyph will be rendered. For members of font collections,
> > file size for validation is calculated in a special
> > way, in accordance with GetFontData logic described in the
> > documentation. I've verified that it works for font collections
> > bundled with Windows 10.
> >
> > As for performance impact, during testing I didn't observe average
> > glyph generation time increase of more than 15%.
> > Taking glyph caching into account, it shouldn't be that significant
> > for typical UI applications, I think. Performance
> > impact can be made even smaller - by performing the validation only
> > once per font, but, I believe, having a Java
> > application always render correct glyphs (even if fonts are added or
> > removed while application is running) is more
> > important.
> >
> > Proposed patch doesn't add any tests, as reproducing the issue
> > requires installation of fonts. Existing automated
> > OpenJDK tests pass after the fix. Proposed approach has been used in
> > JetBrains Runtime without known issues for about 3
> > months in testing and for about 1 month in production.
> >
> > Best regards,
> > Dmitry Batrak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200114/df50a76f/attachment.htm>

From philip.race at oracle.com  Tue Jan 14 17:57:51 2020
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 Jan 2020 09:57:51 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
 <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
Message-ID: <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>

Ok approved. Seems it is making a few things better if not ideal, but 
nothing worse.

-phil.

On 1/14/20 8:14 AM, Dmitry Batrak wrote:
> > So this is a workaround for a buggy font that doesn't play well with 
> GDI ?
>
> This is a workaround for all cases (or the vast majority of them) of 
> broken
> rendering reported by our customers. The case with Roboto is just the 
> one we
> have steps to reproduce for. There can be other cases where GDI's 
> logic is not
> matched by JDK. Even if all of them are caused by 'mis-constructed' 
> fonts, I'm
> afraid, this will not be considered as a good excuse by our customers, 
> as only
> Java applications have such problems with these fonts.
>
> See JDK-8192972, still unsolved in OpenJDK, as an example of the 
> problems which
> will be, at least partially, solved with this fix (correct glyphs will be
> rendered, albeit using FreeType).
>
> I did test the fix with fonts preinstalled in Windows 10. Fallback was 
> actually
> triggered for one font (bold italic 'Segoe UI Semibold'), which is not 
> a 'false'
> positive, but actually a manifestation of another JDK bug from the 
> same family -
> I've just raised https://bugs.openjdk.java.net/browse/JDK-8237085 for 
> it. That's
> yet another example of an issue which will be (mostly) solved by the 
> proposed
> fix.
>
> Using file length as a 'checksum' certainly doesn't guarantee we 
> choose the
> right font, but the probability of error is very low, and this value 
> seems to be
> the best candidate in our circumstances in terms of cost vs. benefit. 
> Even if
> the validation mistreats a different font (having the same length) as 
> a correct
> one, we'll not be in a worse position than before.
>
> Of course, there's a certain risk that rendering for unaffected fonts 
> might
> change, but, given quite straightforward contract of GetFontData 
> function, I
> would consider it very low.
>
> > Since you aren't retrieving the data, just asking what the size is, 
> I'd expect
> > it to be unmeasurable.
>
> Well, we don't know how GetFontData works exactly, but it does seem to 
> add some
> overhead. On my Windows 10 machine OpenJDK with the proposed fix 
> yields about 7%
> larger result for the following benchmark program. The reported value does
> fluctuate from run to run, but the impact of the fix seems to be 
> larger than the
> fluctuations.
>
> --- Benchmark source code ----
> import java.awt.*;
> import java.awt.font.GlyphVector;
> import java.awt.image.BufferedImage;
>
> public class PerfTestOneFont {
> ? ? private static final Font FONT = new Font("Segoe UI", Font.PLAIN, 12);
>
> ? ? public static void main(String[] args) {
> ? ? ? ? FONT.getFamily(); // preload font
>
> ? ? ? ? BufferedImage image = new BufferedImage(1, 1, 
> BufferedImage.TYPE_INT_RGB);
> ? ? ? ? Graphics2D g = image.createGraphics();
> g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
> ? ? ? ? int glyphCount = FONT.getNumGlyphs();
> ? ? ? ? long startTime = System.currentTimeMillis();
> ? ? ? ? for (int glyphCode = 0; glyphCode < glyphCount; glyphCode++) {
> ? ? ? ? ? ? GlyphVector gv = 
> FONT.createGlyphVector(g.getFontRenderContext(),
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?new int[]{glyphCode});
> ? ? ? ? ? ? g.drawGlyphVector(gv, 0, 0);
> ? ? ? ? }
> ? ? ? ? long endTime = System.currentTimeMillis();
> ? ? ? ? g.dispose();
> ? ? ? ? System.out.println(endTime - startTime);
> ? ? }
> }
> ------------------------------
>
> Best regards,
> Dmitry Batrak
>
> On Mon, Jan 13, 2020 at 11:09 PM Phil Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>     So this is a workaround for a buggy font that doesn't play well
>     with GDI ?
>
>     It does rely on the fonts always being different sizes which is
>     highly
>     likely if not guaranteed.
>     I suppose it is OK so long as we aren't getting any "false" positives.
>
>     What I mean is that almost no one will have these Roboto fonts
>     installed, so the fix
>     is solving a problem they don't have, but if it is wrong in some way,
>     then they could lose
>     GDI rendering of LCD glyphs and that could affect a lot of people.
>
>     So have you tested this with the full set of Windows 10 fonts -
>     including Indic, CJK, etc? - to be sure
>     there are no cases where it fails for these or other spurious
>     failures.
>
>     ?> As for performance impact, during testing I didn't observe average
>     glyph generation time increase of more than 15%.
>
>     Since you aren't retrieving the data, just asking what the size
>     is, I'd
>     expect it to be unmeasurable.
>
>     -phil.
>
>     On 1/13/20 1:25 AM, Dmitry Batrak wrote:
>     > Hello,
>     >
>     > I'd like to submit a patch for JDK-8236996. I'm not a Committer, so
>     > I'll need someone to sponsor this change.
>     >
>     > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
>     > Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
>     >
>     > The problem described in JDK-8236996 is from a group of issues (see
>     > also e.g. JDK-8078382 and JDK-8192972), where JDK
>     > uses one font to perform char-to-glyph conversion, but GDI, when
>     asked
>     > to render the glyph is picking a different font,
>     > leading to completely random glyphs being rendered, as
>     char-to-glyph
>     > mapping obviously differs for different fonts.
>     >
>     > Specific version of Roboto font, mentioned in JDK-8236996, is most
>     > probably causing the issue because it's not following
>     > the naming guidelines from OpenType specification
>     > (https://docs.microsoft.com/en-us/typography/opentype/spec/name),
>     > having more than 4 variants (regular, bold, italic and bold italic)
>     > with the same 'Font Family name' (name ID = 1). So,
>     > GDI gets confused and picks Roboto Black for rendering, when
>     asked to
>     > choose a regular font from Roboto family (Roboto
>     > Black having weight of 400, just like Roboto Regular, probably
>     adds to
>     > the confusion).
>     >
>     > But the reasoning, given above, about the issue cause is only a
>     guess.
>     > GDI is not an open-source subsystem, so we cannot
>     > know for sure how it selects the font for rendering, and cannot
>     > implement matching logic in JDK. Ideally, we'd want to
>     > select the font by specifying its file path, but that's not
>     possible
>     > with GDI. Luckily, it allows us to query file data
>     > for the selected font using GetFontData function
>     >
>     (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata),
>
>     > which we can use to validate that the
>     > selected font is the one we need.
>     >
>     > The proposed solution is to check the file size of the font,
>     selected
>     > by GDI, before using it for rendering. If a mismatch
>     > is detected, fallback to FreeType is performed. It can produce a
>     > somewhat different glyph representation, but, at least,
>     > the correct glyph will be rendered. For members of font
>     collections,
>     > file size for validation is calculated in a special
>     > way, in accordance with GetFontData logic described in the
>     > documentation. I've verified that it works for font collections
>     > bundled with Windows 10.
>     >
>     > As for performance impact, during testing I didn't observe average
>     > glyph generation time increase of more than 15%.
>     > Taking glyph caching into account, it shouldn't be that significant
>     > for typical UI applications, I think. Performance
>     > impact can be made even smaller - by performing the validation only
>     > once per font, but, I believe, having a Java
>     > application always render correct glyphs (even if fonts are
>     added or
>     > removed while application is running) is more
>     > important.
>     >
>     > Proposed patch doesn't add any tests, as reproducing the issue
>     > requires installation of fonts. Existing automated
>     > OpenJDK tests pass after the fix. Proposed approach has been
>     used in
>     > JetBrains Runtime without known issues for about 3
>     > months in testing and for about 1 month in production.
>     >
>     > Best regards,
>     > Dmitry Batrak
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200114/b3e5de4e/attachment-0001.htm>

From philip.race at oracle.com  Tue Jan 14 20:33:13 2020
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 Jan 2020 12:33:13 -0800
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
 huge lines"
In-Reply-To: <A6C6EFEC-5D6D-46ED-9C72-9901F99FE054@oracle.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
 <5E18B56D.7060101@oracle.com>
 <CAFvQSYR2hTZP9uuTgQdoc8VMO58L-RL7vLUZP4RBPt-ffk-TwA@mail.gmail.com>
 <A6C6EFEC-5D6D-46ED-9C72-9901F99FE054@oracle.com>
Message-ID: <36f2edda-5b13-cf27-96fc-7dceaaf022b9@oracle.com>

Here's your webrev with a jtreg compliant test added :
http://cr.openjdk.java.net/~prr/8235904/

I verified the test behaves properly under jtreg -
 ?before the fix jtreg kills it on time out
 ?after the fix it finishes quickly and successfully

Outside of jtreg it also exits properly although jtreg is the normal way 
to run it.

This is all +1 from me but I think someone else should sign off on this 
too since I
don't want to self-review the test.

-phil.

On 1/12/20 11:54 AM, Phil Race wrote:
> Hi Clemens,
>
> That needs reworking in location as well as adding jtreg boiler plate and legal notice. Also there are code changes required to be a well behaved test. I need to sit in front of a headful Linux system to test those so I will have to follow up on this (hopefully) tomorrow.
>
> -Phil.
>
>> On Jan 11, 2020, at 12:40 PM, Clemens Eisserer <linuxhippy at gmail.com> wrote:
>>
>> Hi Phil,
>>
>>> Is there a regression test ?
>>> I don't see a noreg- label.
>> Sorry I forgot to mention, the regression test is in the "main"
>> directory of the bugfix:
>> http://cr.openjdk.java.net/~ceisserer/8235904/
>>
>> Thanks and best regards, Clemens


From alexander.zuev at oracle.com  Tue Jan 14 21:56:01 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Tue, 14 Jan 2020 13:56:01 -0800
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
 huge lines"
In-Reply-To: <36f2edda-5b13-cf27-96fc-7dceaaf022b9@oracle.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
 <5E18B56D.7060101@oracle.com>
 <CAFvQSYR2hTZP9uuTgQdoc8VMO58L-RL7vLUZP4RBPt-ffk-TwA@mail.gmail.com>
 <A6C6EFEC-5D6D-46ED-9C72-9901F99FE054@oracle.com>
 <36f2edda-5b13-cf27-96fc-7dceaaf022b9@oracle.com>
Message-ID: <8e932ef8-c245-7962-d7a2-ff5cedaca8a5@oracle.com>

Hi Phil, Clemens,

 ? both code change and test looks fine to me.

/Alex

On 1/14/20 12:33, Phil Race wrote:
> Here's your webrev with a jtreg compliant test added :
> http://cr.openjdk.java.net/~prr/8235904/
>
> I verified the test behaves properly under jtreg -
> ?before the fix jtreg kills it on time out
> ?after the fix it finishes quickly and successfully
>
> Outside of jtreg it also exits properly although jtreg is the normal 
> way to run it.
>
> This is all +1 from me but I think someone else should sign off on 
> this too since I
> don't want to self-review the test.
>
> -phil.
>
> On 1/12/20 11:54 AM, Phil Race wrote:
>> Hi Clemens,
>>
>> That needs reworking in location as well as adding jtreg boiler plate 
>> and legal notice. Also there are code changes required to be a well 
>> behaved test. I need to sit in front of a headful Linux system to 
>> test those so I will have to follow up on this (hopefully) tomorrow.
>>
>> -Phil.
>>
>>> On Jan 11, 2020, at 12:40 PM, Clemens Eisserer 
>>> <linuxhippy at gmail.com> wrote:
>>>
>>> Hi Phil,
>>>
>>>> Is there a regression test ?
>>>> I don't see a noreg- label.
>>> Sorry I forgot to mention, the regression test is in the "main"
>>> directory of the bugfix:
>>> http://cr.openjdk.java.net/~ceisserer/8235904/
>>>
>>> Thanks and best regards, Clemens
>


From neugens.limasoftware at gmail.com  Wed Jan 15 01:09:06 2020
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 15 Jan 2020 02:09:06 +0100
Subject: [OpenJDK 2D-Dev] Fix for 8235904 "Infinite loop when rendering
 huge lines"
In-Reply-To: <8e932ef8-c245-7962-d7a2-ff5cedaca8a5@oracle.com>
References: <CAFvQSYQkThapbRLw0isbS6-vuhg3j0mCQzbY9=0ELSiXtp0Qxw@mail.gmail.com>
 <5E18B56D.7060101@oracle.com>
 <CAFvQSYR2hTZP9uuTgQdoc8VMO58L-RL7vLUZP4RBPt-ffk-TwA@mail.gmail.com>
 <A6C6EFEC-5D6D-46ED-9C72-9901F99FE054@oracle.com>
 <36f2edda-5b13-cf27-96fc-7dceaaf022b9@oracle.com>
 <8e932ef8-c245-7962-d7a2-ff5cedaca8a5@oracle.com>
Message-ID: <CAGUMyaRcuw-rxFvGZdi7h_WGchcAyHY7pGJGZH60VhwcesXv6w@mail.gmail.com>

Thanks!

Cheers,
Mario

On Tue 14. Jan 2020 at 22:58, Alexander Zuev <alexander.zuev at oracle.com>
wrote:

> Hi Phil, Clemens,
>
>    both code change and test looks fine to me.
>
> /Alex
>
> On 1/14/20 12:33, Phil Race wrote:
> > Here's your webrev with a jtreg compliant test added :
> > http://cr.openjdk.java.net/~prr/8235904/
> >
> > I verified the test behaves properly under jtreg -
> >  before the fix jtreg kills it on time out
> >  after the fix it finishes quickly and successfully
> >
> > Outside of jtreg it also exits properly although jtreg is the normal
> > way to run it.
> >
> > This is all +1 from me but I think someone else should sign off on
> > this too since I
> > don't want to self-review the test.
> >
> > -phil.
> >
> > On 1/12/20 11:54 AM, Phil Race wrote:
> >> Hi Clemens,
> >>
> >> That needs reworking in location as well as adding jtreg boiler plate
> >> and legal notice. Also there are code changes required to be a well
> >> behaved test. I need to sit in front of a headful Linux system to
> >> test those so I will have to follow up on this (hopefully) tomorrow.
> >>
> >> -Phil.
> >>
> >>> On Jan 11, 2020, at 12:40 PM, Clemens Eisserer
> >>> <linuxhippy at gmail.com> wrote:
> >>>
> >>> Hi Phil,
> >>>
> >>>> Is there a regression test ?
> >>>> I don't see a noreg- label.
> >>> Sorry I forgot to mention, the regression test is in the "main"
> >>> directory of the bugfix:
> >>> http://cr.openjdk.java.net/~ceisserer/8235904/
> >>>
> >>> Thanks and best regards, Clemens
> >
>
> --
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200115/bfcfa20e/attachment.htm>

From philip.race at oracle.com  Wed Jan 15 17:23:21 2020
From: philip.race at oracle.com (Phil Race)
Date: Wed, 15 Jan 2020 09:23:21 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8224109: Text spaced incorrectly by
 drawString under rotation with fractional metrics
In-Reply-To: <1e5bd3b7-7e98-81f8-6854-07e982b82f01@oracle.com>
References: <5E18ED9E.6040708@oracle.com>
 <1e5bd3b7-7e98-81f8-6854-07e982b82f01@oracle.com>
Message-ID: <f4bf4748-d65d-fa69-2f50-adf7417ae062@oracle.com>

Looking for a 2nd reviewer.

-phil.

On 1/11/20 4:12 PM, Sergey Bylokhov wrote:
> Look fine.
>
> On 1/10/20 1:33 pm, Philip Race wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224109
>> Webrev: http://cr.openjdk.java.net/~prr/8224109/
>>
>> There have been at least a couple of reports on this problem which 
>> manifests
>> when using fractional metrics.
>>
>> As noted in the bug eval
>> - we had the wrong sign for the y advance in this path
>> -? the wrong transform component was being used for the rotation.
>>
>> The fix is quite small but creating a regression test? was a challenge
>> to be able to reliably tell where the rendering landed and if it
>> was the same for different APIs and that it goes in an "expected" 
>> direction.
>>
>> I found one new bug 8236451with a laid out glyphvector which is
>> not fixed here because it is a harfbuzz code path problem.
>>
>> Also we have known issues with AAT fonts and harfbuzz so? using
>> Courier New on mac.
>>
>> Not to mention Macos Mojave wants to do AA text even when you
>> ask for B&W (bug open on that too) so it is really hard to verify in 
>> that case.
>>
>> -phil.
>>
>>
>
>


From alexander.zuev at oracle.com  Fri Jan 17 07:57:24 2020
From: alexander.zuev at oracle.com (Alexander Zuev)
Date: Thu, 16 Jan 2020 23:57:24 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8224109: Text spaced incorrectly by
 drawString under rotation with fractional metrics
In-Reply-To: <f4bf4748-d65d-fa69-2f50-adf7417ae062@oracle.com>
References: <5E18ED9E.6040708@oracle.com>
 <1e5bd3b7-7e98-81f8-6854-07e982b82f01@oracle.com>
 <f4bf4748-d65d-fa69-2f50-adf7417ae062@oracle.com>
Message-ID: <3809c7cd-795e-2fe9-e916-45a4f15295e8@oracle.com>

Looks fine to me.

/Alex

On 1/15/20 09:23, Phil Race wrote:
> Looking for a 2nd reviewer.
>
> -phil.
>
> On 1/11/20 4:12 PM, Sergey Bylokhov wrote:
>> Look fine.
>>
>> On 1/10/20 1:33 pm, Philip Race wrote:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8224109
>>> Webrev: http://cr.openjdk.java.net/~prr/8224109/
>>>
>>> There have been at least a couple of reports on this problem which 
>>> manifests
>>> when using fractional metrics.
>>>
>>> As noted in the bug eval
>>> - we had the wrong sign for the y advance in this path
>>> -? the wrong transform component was being used for the rotation.
>>>
>>> The fix is quite small but creating a regression test? was a challenge
>>> to be able to reliably tell where the rendering landed and if it
>>> was the same for different APIs and that it goes in an "expected" 
>>> direction.
>>>
>>> I found one new bug 8236451with a laid out glyphvector which is
>>> not fixed here because it is a harfbuzz code path problem.
>>>
>>> Also we have known issues with AAT fonts and harfbuzz so using
>>> Courier New on mac.
>>>
>>> Not to mention Macos Mojave wants to do AA text even when you
>>> ask for B&W (bug open on that too) so it is really hard to verify in 
>>> that case.
>>>
>>> -phil.
>>>
>>>
>>
>>
>


From dmitry.batrak at jetbrains.com  Mon Jan 20 08:14:44 2020
From: dmitry.batrak at jetbrains.com (Dmitry Batrak)
Date: Mon, 20 Jan 2020 11:14:44 +0300
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
 <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
 <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>
Message-ID: <CAET5FPuOwLDpKGE_Byr4QR+tHyo1QMXxQyg4YMuz-bBFcA5SXw@mail.gmail.com>

> Ok approved. Seems it is making a few things better if not ideal, but
nothing worse.

Thanks!
Anyone else volunteering to review?

Best regards,
Dmitry Batrak

On Tue, Jan 14, 2020 at 8:58 PM Phil Race <philip.race at oracle.com> wrote:

> Ok approved. Seems it is making a few things better if not ideal, but
> nothing worse.
>
> -phil.
>
> On 1/14/20 8:14 AM, Dmitry Batrak wrote:
>
> > So this is a workaround for a buggy font that doesn't play well with GDI
> ?
>
> This is a workaround for all cases (or the vast majority of them) of broken
> rendering reported by our customers. The case with Roboto is just the one
> we
> have steps to reproduce for. There can be other cases where GDI's logic is
> not
> matched by JDK. Even if all of them are caused by 'mis-constructed' fonts,
> I'm
> afraid, this will not be considered as a good excuse by our customers, as
> only
> Java applications have such problems with these fonts.
>
> See JDK-8192972, still unsolved in OpenJDK, as an example of the problems
> which
> will be, at least partially, solved with this fix (correct glyphs will be
> rendered, albeit using FreeType).
>
> I did test the fix with fonts preinstalled in Windows 10. Fallback was
> actually
> triggered for one font (bold italic 'Segoe UI Semibold'), which is not a
> 'false'
> positive, but actually a manifestation of another JDK bug from the same
> family -
> I've just raised https://bugs.openjdk.java.net/browse/JDK-8237085 for it.
> That's
> yet another example of an issue which will be (mostly) solved by the
> proposed
> fix.
>
> Using file length as a 'checksum' certainly doesn't guarantee we choose the
> right font, but the probability of error is very low, and this value seems
> to be
> the best candidate in our circumstances in terms of cost vs. benefit. Even
> if
> the validation mistreats a different font (having the same length) as a
> correct
> one, we'll not be in a worse position than before.
>
> Of course, there's a certain risk that rendering for unaffected fonts might
> change, but, given quite straightforward contract of GetFontData function,
> I
> would consider it very low.
>
> > Since you aren't retrieving the data, just asking what the size is, I'd
> expect
> > it to be unmeasurable.
>
> Well, we don't know how GetFontData works exactly, but it does seem to add
> some
> overhead. On my Windows 10 machine OpenJDK with the proposed fix yields
> about 7%
> larger result for the following benchmark program. The reported value does
> fluctuate from run to run, but the impact of the fix seems to be larger
> than the
> fluctuations.
>
> --- Benchmark source code ----
> import java.awt.*;
> import java.awt.font.GlyphVector;
> import java.awt.image.BufferedImage;
>
> public class PerfTestOneFont {
>     private static final Font FONT = new Font("Segoe UI", Font.PLAIN, 12);
>
>     public static void main(String[] args) {
>         FONT.getFamily(); // preload font
>
>         BufferedImage image = new BufferedImage(1, 1,
> BufferedImage.TYPE_INT_RGB);
>         Graphics2D g = image.createGraphics();
>         g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
>                   RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
>         int glyphCount = FONT.getNumGlyphs();
>         long startTime = System.currentTimeMillis();
>         for (int glyphCode = 0; glyphCode < glyphCount; glyphCode++) {
>             GlyphVector gv =
> FONT.createGlyphVector(g.getFontRenderContext(),
>                                        new int[]{glyphCode});
>             g.drawGlyphVector(gv, 0, 0);
>         }
>         long endTime = System.currentTimeMillis();
>         g.dispose();
>         System.out.println(endTime - startTime);
>     }
> }
> ------------------------------
>
> Best regards,
> Dmitry Batrak
>
> On Mon, Jan 13, 2020 at 11:09 PM Phil Race <philip.race at oracle.com> wrote:
>
>> So this is a workaround for a buggy font that doesn't play well with GDI ?
>>
>> It does rely on the fonts always being different sizes which is highly
>> likely if not guaranteed.
>> I suppose it is OK so long as we aren't getting any "false" positives.
>>
>> What I mean is that almost no one will have these Roboto fonts
>> installed, so the fix
>> is solving a problem they don't have, but if it is wrong in some way,
>> then they could lose
>> GDI rendering of LCD glyphs and that could affect a lot of people.
>>
>> So have you tested this with the full set of Windows 10 fonts -
>> including Indic, CJK, etc  - to be sure
>> there are no cases where it fails for these or other spurious failures.
>>
>>  > As for performance impact, during testing I didn't observe average
>> glyph generation time increase of more than 15%.
>>
>> Since you aren't retrieving the data, just asking what the size is, I'd
>> expect it to be unmeasurable.
>>
>> -phil.
>>
>> On 1/13/20 1:25 AM, Dmitry Batrak wrote:
>> > Hello,
>> >
>> > I'd like to submit a patch for JDK-8236996. I'm not a Committer, so
>> > I'll need someone to sponsor this change.
>> >
>> > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
>> > Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
>> >
>> > The problem described in JDK-8236996 is from a group of issues (see
>> > also e.g. JDK-8078382 and JDK-8192972), where JDK
>> > uses one font to perform char-to-glyph conversion, but GDI, when asked
>> > to render the glyph is picking a different font,
>> > leading to completely random glyphs being rendered, as char-to-glyph
>> > mapping obviously differs for different fonts.
>> >
>> > Specific version of Roboto font, mentioned in JDK-8236996, is most
>> > probably causing the issue because it's not following
>> > the naming guidelines from OpenType specification
>> > (https://docs.microsoft.com/en-us/typography/opentype/spec/name),
>> > having more than 4 variants (regular, bold, italic and bold italic)
>> > with the same 'Font Family name' (name ID = 1). So,
>> > GDI gets confused and picks Roboto Black for rendering, when asked to
>> > choose a regular font from Roboto family (Roboto
>> > Black having weight of 400, just like Roboto Regular, probably adds to
>> > the confusion).
>> >
>> > But the reasoning, given above, about the issue cause is only a guess.
>> > GDI is not an open-source subsystem, so we cannot
>> > know for sure how it selects the font for rendering, and cannot
>> > implement matching logic in JDK. Ideally, we'd want to
>> > select the font by specifying its file path, but that's not possible
>> > with GDI. Luckily, it allows us to query file data
>> > for the selected font using GetFontData function
>> > (
>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata),
>>
>> > which we can use to validate that the
>> > selected font is the one we need.
>> >
>> > The proposed solution is to check the file size of the font, selected
>> > by GDI, before using it for rendering. If a mismatch
>> > is detected, fallback to FreeType is performed. It can produce a
>> > somewhat different glyph representation, but, at least,
>> > the correct glyph will be rendered. For members of font collections,
>> > file size for validation is calculated in a special
>> > way, in accordance with GetFontData logic described in the
>> > documentation. I've verified that it works for font collections
>> > bundled with Windows 10.
>> >
>> > As for performance impact, during testing I didn't observe average
>> > glyph generation time increase of more than 15%.
>> > Taking glyph caching into account, it shouldn't be that significant
>> > for typical UI applications, I think. Performance
>> > impact can be made even smaller - by performing the validation only
>> > once per font, but, I believe, having a Java
>> > application always render correct glyphs (even if fonts are added or
>> > removed while application is running) is more
>> > important.
>> >
>> > Proposed patch doesn't add any tests, as reproducing the issue
>> > requires installation of fonts. Existing automated
>> > OpenJDK tests pass after the fix. Proposed approach has been used in
>> > JetBrains Runtime without known issues for about 3
>> > months in testing and for about 1 month in production.
>> >
>> > Best regards,
>> > Dmitry Batrak
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200120/82b2fb53/attachment.htm>

From Sergey.Bylokhov at oracle.com  Tue Jan 21 05:02:24 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 20 Jan 2020 21:02:24 -0800
Subject: [OpenJDK 2D-Dev] [15] Review Request: 5085520 Inconsistency in spec
 for RenderingHints.entrySet()
Message-ID: <c51258d5-32d6-f918-f344-ead7e5d67989@oracle.com>

Hello.
Please review the fix for JDK 15.

Bug: https://bugs.openjdk.java.net/browse/JDK-5085520
CSR: https://bugs.openjdk.java.net/browse/JDK-8237563
Fix: http://cr.openjdk.java.net/~serb/5085520/webrev.00

The java.awt.RenderingHints.entrySet() method description says
that the Set, returned by the method, can be changed and these
modifications will be reflected in the RenderingHints. However,
the last statement of the specification prohibits any
modifications of this Set.

In the fix "and vice-versa" part was removed.

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Jan 21 05:05:19 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 20 Jan 2020 21:05:19 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <CAET5FPuOwLDpKGE_Byr4QR+tHyo1QMXxQyg4YMuz-bBFcA5SXw@mail.gmail.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
 <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
 <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>
 <CAET5FPuOwLDpKGE_Byr4QR+tHyo1QMXxQyg4YMuz-bBFcA5SXw@mail.gmail.com>
Message-ID: <9e5957ca-d0f8-a0da-4c5c-8bdf38e7e08c@oracle.com>

Looks fine.
Thank you for contribution!

On 1/20/20 12:14 am, Dmitry Batrak wrote:
>  > Ok approved. Seems it is making a few things better if not ideal, but nothing worse.
> 
> Thanks!
> Anyone else volunteering to review?
> 
> Best regards,
> Dmitry Batrak
> 
> On Tue, Jan 14, 2020 at 8:58 PM Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
> 
>     Ok approved. Seems it is making a few things better if not ideal, but nothing worse.
> 
>     -phil.
> 
>     On 1/14/20 8:14 AM, Dmitry Batrak wrote:
>>     > So this is a workaround for a buggy font that doesn't play well with GDI ?
>>
>>     This is a workaround for all cases (or the vast majority of them) of broken
>>     rendering reported by our customers. The case with Roboto is just the one we
>>     have steps to reproduce for. There can be other cases where GDI's logic is not
>>     matched by JDK. Even if all of them are caused by 'mis-constructed' fonts, I'm
>>     afraid, this will not be considered as a good excuse by our customers, as only
>>     Java applications have such problems with these fonts.
>>
>>     See JDK-8192972, still unsolved in OpenJDK, as an example of the problems which
>>     will be, at least partially, solved with this fix (correct glyphs will be
>>     rendered, albeit using FreeType).
>>
>>     I did test the fix with fonts preinstalled in Windows 10. Fallback was actually
>>     triggered for one font (bold italic 'Segoe UI Semibold'), which is not a 'false'
>>     positive, but actually a manifestation of another JDK bug from the same family -
>>     I've just raised https://bugs.openjdk.java.net/browse/JDK-8237085 for it. That's
>>     yet another example of an issue which will be (mostly) solved by the proposed
>>     fix.
>>
>>     Using file length as a 'checksum' certainly doesn't guarantee we choose the
>>     right font, but the probability of error is very low, and this value seems to be
>>     the best candidate in our circumstances in terms of cost vs. benefit. Even if
>>     the validation mistreats a different font (having the same length) as a correct
>>     one, we'll not be in a worse position than before.
>>
>>     Of course, there's a certain risk that rendering for unaffected fonts might
>>     change, but, given quite straightforward contract of GetFontData function, I
>>     would consider it very low.
>>
>>     > Since you aren't retrieving the data, just asking what the size is, I'd expect
>>     > it to be unmeasurable.
>>
>>     Well, we don't know how GetFontData works exactly, but it does seem to add some
>>     overhead. On my Windows 10 machine OpenJDK with the proposed fix yields about 7%
>>     larger result for the following benchmark program. The reported value does
>>     fluctuate from run to run, but the impact of the fix seems to be larger than the
>>     fluctuations.
>>
>>     --- Benchmark source code ----
>>     import java.awt.*;
>>     import java.awt.font.GlyphVector;
>>     import java.awt.image.BufferedImage;
>>
>>     public class PerfTestOneFont {
>>     ? ? private static final Font FONT = new Font("Segoe UI", Font.PLAIN, 12);
>>
>>     ? ? public static void main(String[] args) {
>>     ? ? ? ? FONT.getFamily(); // preload font
>>
>>     ? ? ? ? BufferedImage image = new BufferedImage(1, 1, BufferedImage.TYPE_INT_RGB);
>>     ? ? ? ? Graphics2D g = image.createGraphics();
>>     g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
>>     RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
>>     ? ? ? ? int glyphCount = FONT.getNumGlyphs();
>>     ? ? ? ? long startTime = System.currentTimeMillis();
>>     ? ? ? ? for (int glyphCode = 0; glyphCode < glyphCount; glyphCode++) {
>>     ? ? ? ? ? ? GlyphVector gv = FONT.createGlyphVector(g.getFontRenderContext(),
>>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?new int[]{glyphCode});
>>     ? ? ? ? ? ? g.drawGlyphVector(gv, 0, 0);
>>     ? ? ? ? }
>>     ? ? ? ? long endTime = System.currentTimeMillis();
>>     ? ? ? ? g.dispose();
>>     ? ? ? ? System.out.println(endTime - startTime);
>>     ? ? }
>>     }
>>     ------------------------------
>>
>>     Best regards,
>>     Dmitry Batrak
>>
>>     On Mon, Jan 13, 2020 at 11:09 PM Phil Race <philip.race at oracle.com <mailto:philip.race at oracle.com>> wrote:
>>
>>         So this is a workaround for a buggy font that doesn't play well with GDI ?
>>
>>         It does rely on the fonts always being different sizes which is highly
>>         likely if not guaranteed.
>>         I suppose it is OK so long as we aren't getting any "false" positives.
>>
>>         What I mean is that almost no one will have these Roboto fonts
>>         installed, so the fix
>>         is solving a problem they don't have, but if it is wrong in some way,
>>         then they could lose
>>         GDI rendering of LCD glyphs and that could affect a lot of people.
>>
>>         So have you tested this with the full set of Windows 10 fonts -
>>         including Indic, CJK, etc? - to be sure
>>         there are no cases where it fails for these or other spurious failures.
>>
>>         ?> As for performance impact, during testing I didn't observe average
>>         glyph generation time increase of more than 15%.
>>
>>         Since you aren't retrieving the data, just asking what the size is, I'd
>>         expect it to be unmeasurable.
>>
>>         -phil.
>>
>>         On 1/13/20 1:25 AM, Dmitry Batrak wrote:
>>         > Hello,
>>         >
>>         > I'd like to submit a patch for JDK-8236996. I'm not a Committer, so
>>         > I'll need someone to sponsor this change.
>>         >
>>         > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
>>         > Webrev: http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
>>         >
>>         > The problem described in JDK-8236996 is from a group of issues (see
>>         > also e.g. JDK-8078382 and JDK-8192972), where JDK
>>         > uses one font to perform char-to-glyph conversion, but GDI, when asked
>>         > to render the glyph is picking a different font,
>>         > leading to completely random glyphs being rendered, as char-to-glyph
>>         > mapping obviously differs for different fonts.
>>         >
>>         > Specific version of Roboto font, mentioned in JDK-8236996, is most
>>         > probably causing the issue because it's not following
>>         > the naming guidelines from OpenType specification
>>         > (https://docs.microsoft.com/en-us/typography/opentype/spec/name),
>>         > having more than 4 variants (regular, bold, italic and bold italic)
>>         > with the same 'Font Family name' (name ID = 1). So,
>>         > GDI gets confused and picks Roboto Black for rendering, when asked to
>>         > choose a regular font from Roboto family (Roboto
>>         > Black having weight of 400, just like Roboto Regular, probably adds to
>>         > the confusion).
>>         >
>>         > But the reasoning, given above, about the issue cause is only a guess.
>>         > GDI is not an open-source subsystem, so we cannot
>>         > know for sure how it selects the font for rendering, and cannot
>>         > implement matching logic in JDK. Ideally, we'd want to
>>         > select the font by specifying its file path, but that's not possible
>>         > with GDI. Luckily, it allows us to query file data
>>         > for the selected font using GetFontData function
>>         > (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata),
>>         > which we can use to validate that the
>>         > selected font is the one we need.
>>         >
>>         > The proposed solution is to check the file size of the font, selected
>>         > by GDI, before using it for rendering. If a mismatch
>>         > is detected, fallback to FreeType is performed. It can produce a
>>         > somewhat different glyph representation, but, at least,
>>         > the correct glyph will be rendered. For members of font collections,
>>         > file size for validation is calculated in a special
>>         > way, in accordance with GetFontData logic described in the
>>         > documentation. I've verified that it works for font collections
>>         > bundled with Windows 10.
>>         >
>>         > As for performance impact, during testing I didn't observe average
>>         > glyph generation time increase of more than 15%.
>>         > Taking glyph caching into account, it shouldn't be that significant
>>         > for typical UI applications, I think. Performance
>>         > impact can be made even smaller - by performing the validation only
>>         > once per font, but, I believe, having a Java
>>         > application always render correct glyphs (even if fonts are added or
>>         > removed while application is running) is more
>>         > important.
>>         >
>>         > Proposed patch doesn't add any tests, as reproducing the issue
>>         > requires installation of fonts. Existing automated
>>         > OpenJDK tests pass after the fix. Proposed approach has been used in
>>         > JetBrains Runtime without known issues for about 3
>>         > months in testing and for about 1 month in production.
>>         >
>>         > Best regards,
>>         > Dmitry Batrak
>>
>>
> 
> 
> 


-- 
Best regards, Sergey.

From matthias.baesken at sap.com  Tue Jan 21 17:00:54 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 21 Jan 2020 17:00:54 +0000
Subject: [OpenJDK 2D-Dev] checking sscanf return code in awt_ImagingLib.c ?
Message-ID: <AM6PR02MB42004F9006D66F2ACBBB0505930D0@AM6PR02MB4200.eurprd02.prod.outlook.com>

Hello, I noticed that we miss a check of the sscanf return code in awt_ImagingLib.c  , should we add a check like we do at almost all other places of sscanf calls ?
(like the code below )

Thanks, Matthias


diff -r 3ca4a8016584 src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c
--- a/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c        Thu Jan 16 18:04:23 2020 +0100
+++ b/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c        Tue Jan 21 10:31:34 2020 +0100
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1997, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -1771,6 +1771,7 @@
JNIEXPORT jboolean JNICALL
Java_sun_awt_image_ImagingLib_init(JNIEnv *env, jclass thisClass) {
     char *start;
+    int srs = 0;
     if (getenv("IMLIB_DEBUG")) {
         start_timer = awt_setMlibStartTimer();
         stop_timer = awt_setMlibStopTimer();
@@ -1783,7 +1784,12 @@
         s_printIt = 1;
     }
     if ((start = getenv("IMLIB_START")) != NULL) {
-        sscanf(start, "%d", &s_startOff);
+        srs = sscanf(start, "%d", &s_startOff);
+        if (srs != 1) {
+            s_nomlib = 1;
+            fprintf(stderr, "Failure - reading from IMLIB_START failed.\n");
+            return JNI_FALSE;
+        }
     }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200121/f1ec6c0a/attachment.htm>

From philip.race at oracle.com  Wed Jan 22 17:13:58 2020
From: philip.race at oracle.com (Phil Race)
Date: Wed, 22 Jan 2020 09:13:58 -0800
Subject: [OpenJDK 2D-Dev] checking sscanf return code in
 awt_ImagingLib.c ?
In-Reply-To: <AM6PR02MB42004F9006D66F2ACBBB0505930D0@AM6PR02MB4200.eurprd02.prod.outlook.com>
References: <AM6PR02MB42004F9006D66F2ACBBB0505930D0@AM6PR02MB4200.eurprd02.prod.outlook.com>
Message-ID: <0e80161b-b575-c8c0-8c6d-e41e96f00055@oracle.com>

I don't see why we'd want to abandon loading the library rather than 
just ignoring the
match failure, just as if the variable was unspecified.

-phil.

On 1/21/20 9:00 AM, Baesken, Matthias wrote:
>
> Hello, I noticed that we miss a check of the sscanf return code in 
> awt_ImagingLib.c , should we add a check like we do at almost all 
> other places of sscanf calls ?
>
> (like the code below )
>
> Thanks, Matthias
>
> diff -r 3ca4a8016584 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c
>
> --- 
> a/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c 
> Thu Jan 16 18:04:23 2020 +0100
>
> +++ 
> b/src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c 
> Tue Jan 21 10:31:34 2020 +0100
>
> @@ -1,5 +1,5 @@
>
> /*
>
> - * Copyright (c) 1997, 2016, Oracle and/or its affiliates. All rights 
> reserved.
>
> + * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights 
> reserved.
>
> ? * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>
> ? *
>
> ? * This code is free software; you can redistribute it and/or modify it
>
> @@ -1771,6 +1771,7 @@
>
> JNIEXPORT jboolean JNICALL
>
> Java_sun_awt_image_ImagingLib_init(JNIEnv *env, jclass thisClass) {
>
> ???? char *start;
>
> +??? int srs = 0;
>
> ???? if (getenv("IMLIB_DEBUG")) {
>
> ???????? start_timer = awt_setMlibStartTimer();
>
> ???????? stop_timer = awt_setMlibStopTimer();
>
> @@ -1783,7 +1784,12 @@
>
> ???????? s_printIt = 1;
>
> ???? }
>
> ???? if ((start = getenv("IMLIB_START")) != NULL) {
>
> -??????? sscanf(start, "%d", &s_startOff);
>
> +??????? srs = sscanf(start, "%d", &s_startOff);
>
> +??????? if (srs != 1) {
>
> +??????????? s_nomlib = 1;
>
> + fprintf(stderr, "Failure - reading from IMLIB_START failed.\n");
>
> +??????????? return JNI_FALSE;
>
> +??????? }
>
> ???? }
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200122/0ac25d2f/attachment.htm>

From philip.race at oracle.com  Wed Jan 22 17:19:20 2020
From: philip.race at oracle.com (Phil Race)
Date: Wed, 22 Jan 2020 09:19:20 -0800
Subject: [OpenJDK 2D-Dev] [15] Review Request: 5085520 Inconsistency in
 spec for RenderingHints.entrySet()
In-Reply-To: <c51258d5-32d6-f918-f344-ead7e5d67989@oracle.com>
References: <c51258d5-32d6-f918-f344-ead7e5d67989@oracle.com>
Message-ID: <89ce28b6-82a0-0918-6f2f-8a9bb8022109@oracle.com>

Looks fine. You could have added that the Set is unmodifiable but it is 
not critical.

-phil.

On 1/20/20 9:02 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for JDK 15.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-5085520
> CSR: https://bugs.openjdk.java.net/browse/JDK-8237563
> Fix: http://cr.openjdk.java.net/~serb/5085520/webrev.00
>
> The java.awt.RenderingHints.entrySet() method description says
> that the Set, returned by the method, can be changed and these
> modifications will be reflected in the RenderingHints. However,
> the last statement of the specification prohibits any
> modifications of this Set.
>
> In the fix "and vice-versa" part was removed.
>


From Sergey.Bylokhov at oracle.com  Thu Jan 23 00:35:31 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 22 Jan 2020 16:35:31 -0800
Subject: [OpenJDK 2D-Dev] [15] Review Request: 8237746 Fixing compiler
 warnings in src/demo/share/jfc
Message-ID: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>

Hello.
Please review the fix for compiler warnings in the demo/jfc in JDK 15.

Bug: https://bugs.openjdk.java.net/browse/JDK-8237746
Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00

This fix contributed by the Marc Hoffmann:
https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html

Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs.

-- 
Best regards, Sergey.

From JAYATHIRTH.D.V at ORACLE.COM  Thu Jan 23 06:28:40 2020
From: JAYATHIRTH.D.V at ORACLE.COM (Jayathirth D v)
Date: Thu, 23 Jan 2020 11:58:40 +0530
Subject: [OpenJDK 2D-Dev] [15] Review Request: 5085520 Inconsistency in
 spec for RenderingHints.entrySet()
In-Reply-To: <89ce28b6-82a0-0918-6f2f-8a9bb8022109@oracle.com>
References: <c51258d5-32d6-f918-f344-ead7e5d67989@oracle.com>
 <89ce28b6-82a0-0918-6f2f-8a9bb8022109@oracle.com>
Message-ID: <99597A50-6A31-4F43-98FB-6E38F9C76B91@ORACLE.COM>

Change looks fine.

Thanks,
Jay

> On 22-Jan-2020, at 10:49 PM, Phil Race <philip.race at oracle.com> wrote:
> 
> Looks fine. You could have added that the Set is unmodifiable but it is not critical.
> 
> -phil.
> 
> On 1/20/20 9:02 PM, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for JDK 15.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-5085520
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8237563
>> Fix: http://cr.openjdk.java.net/~serb/5085520/webrev.00
>> 
>> The java.awt.RenderingHints.entrySet() method description says
>> that the Set, returned by the method, can be changed and these
>> modifications will be reflected in the RenderingHints. However,
>> the last statement of the specification prohibits any
>> modifications of this Set.
>> 
>> In the fix "and vice-versa" part was removed.
>> 
> 


From christoph.langer at sap.com  Fri Jan 24 08:52:18 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 24 Jan 2020 08:52:18 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when
 fontconfig.properties was used
In-Reply-To: <DB8PR02MB5547A0B57080BAA3E578C71D8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
References: <d741c0c4e6305a8f7abfbeaa675bd645@linux.vnet.ibm.com>
 <AM6PR02MB51924907C429846DEBE14DF98A9B0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com>
 <AM6PR02MB519284629C4998C1CB876F108A9A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <5D9CB3F8.9070205@oracle.com>
 <ffeb92a47867fc4358cd32234d023506@linux.vnet.ibm.com>
 <cd36eb93912d9ada00c6d98577421ac6@linux.vnet.ibm.com>
 <AM6PR02MB4801FEA742BC257853715D318A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <d59e8be7-30e4-fade-25ff-50b5175a40bc@oracle.com>
 <DB8PR02MB55474C1E88EE3AEF8B5720C88A530@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <4cd9707f-ad4e-57db-2d3d-3ed1757f95e9@oracle.com>
 <DB8PR02MB554775727D59605A49B1B5A88A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <bfb767ad-76f2-ea39-1e38-cea9657180dc@oracle.com>
 <DB8PR02MB55477062EB2C53F4384083208A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <dc830333-d0e3-f5e7-7ded-0b51accb692c@oracle.com>
 <DB8PR02MB5547A0B57080BAA3E578C71D8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57146C9A4F95019A03DEADCE8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Ping?

http://cr.openjdk.java.net/~clanger/webrevs/8221741.1/

May I submit this fix to jdk-client? Or what would you want me to change to get it accepted?

This is running for weeks now in our CI infra (on various systems and platforms) and showing no problems?

Thanks
Christoph

From: Langer, Christoph
Sent: Donnerstag, 19. Dezember 2019 22:48
To: Phil Race <philip.race at oracle.com>; Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com>
Cc: 2d-dev at openjdk.java.net
Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

I still might not fully get it?

So, the call to AccessController.doPrivileged() with a PrivilegedExceptionAction might eventually yield a PrivilegedActionException which I catch and handle (as before the NPE). The only thing that differs now is that I don?t handle NPE any more. I was thinking that the only possible source of NPE was when raf is null. That can?t happen now any more because ?new RandomAccessFile? either delivers an Object or throws. But maybe a more defensive approach would be to still handle NPE in case it occurs for whatever other reason?

So, generally, I?m running this patch fine through all our platform testing. I agree that it should be pushed to client-dev and not rushed into 14. Maybe that would give enough test coverage and time to bake?

/Christoph

From: Phil Race <philip.race at oracle.com<mailto:philip.race at oracle.com>>
Sent: Donnerstag, 19. Dezember 2019 21:59
To: Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>; Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com<mailto:takiguc at linux.vnet.ibm.com>>
Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

Here you are seeing the exception during initialisation but if the font is in use
we might get an exception handed to native code when it has not had to deal
with that. We should check that code and if it is ready to deal with pending
exceptions. Other JNI calls in native will fail if it is not and the exception will
ultimately propagate back to the original Java code. It all needs to be looked through for problems.

-phil.
On 12/19/19 12:39 PM, Langer, Christoph wrote:
I don?t understand what?s intriguing you with that code, please help me?

It was done like this before, e.g. the RandomAccessFile was opened in the privileged block. But before you?d only see a null reference coming out in case something went wrong. Now you?d have the FileNotFoundException at hand to be able to trace this detail? Are you concerned that this information could be leaked out of the Privileged block when it shouldn?t?

/Christoph

From: Phil Race <philip.race at oracle.com><mailto:philip.race at oracle.com>
Sent: Donnerstag, 19. Dezember 2019 21:04
To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>
Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

This makes me very nervous because it is up-called from native code.
I am not sure I would want this change in any release ...

317             try {

 318                 RandomAccessFile raf = AccessController.doPrivileged(

 319                     new PrivilegedExceptionAction<RandomAccessFile>() {

 320                         public RandomAccessFile run() throws FileNotFoundException {

 321                             return new RandomAccessFile(platName, "r");

-phil.

On 12/19/19 12:01 PM, Langer, Christoph wrote:

Hi Phil,



Type 1 fonts were available but got skipped.



/Christoph



-----Original Message-----

From: Phil Race <philip.race at oracle.com><mailto:philip.race at oracle.com>

Sent: Donnerstag, 19. Dezember 2019 20:58

To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; Ichiroh Takiguchi

<takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>

Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen

when fontconfig.properties was used



Hi,



If this can get reviewed, I intend to push this fix to JDK14.



Not for 14. This will take some time to review and test and is too risky at this

stage.



You say no TrueType fonts are installed, does that mean there are no

scaleable fonts at all,

or are there Type 1 fonts we are skipping over ?



-phil.







On 12/18/19 6:31 AM, Langer, Christoph wrote:

Hi,



sorry for the long time that it took me to come back to this item.



I eventually spent quite a significant amount of time analyzing what's going

wrong here. At least, I have a few AIX LPARs, where we would always

encounter this type of Exception:



Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException:

class sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont

(sun.font.CompositeFont and sun.font.PhysicalFont are in module

java.desktop of loader 'bootstrap')

         at

java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontMa

nager.java:1081)

         at

java.desktop/sun.font.SunFontManager.initialiseDeferredFont(SunFontMan

ager.java:960)

         at

java.desktop/sun.font.SunFontManager.findOtherDeferredFont(SunFontM

anager.java:898)

         at

java.desktop/sun.font.SunFontManager.findDeferredFont(SunFontManager

.java:914)

         at

java.desktop/sun.font.SunFontManager.findFont2D(SunFontManager.java:2

105)

         ...



The problem on our systems is triggered by two factors. First is that the

font configuration file contains paths to font files that don't exist. Secondly,

the system's fontconfig has no TrueType Fonts installed. Now, during loading

of fonts, it goes over these non-existing font files and tries to mark their

initialization in sun.font.SunFontManager::initialiseDeferredFont(String

fileNameKey) by adding the key into the initialisedFonts map. Since there is

no font handle available because the font couldn't be loaded but the map's

value must not be null, it wants to use the handle of the default physical

font. So, calling getDefaultPhysicalFont at this place triggers findFont2D and

then recursive calls into

initialiseDeferredFont/getDefaultPhysicalFont/findFont2D until a matching

default physical font was loaded. But it's quite indeterministic which font is

returned at what place in findFont2D when the recursion is unwinded, so this

ClassCastException occurs.



I propose to fix this by adding a "NULL FONT HANDLE" to use in

initialisedFonts for fonts that can?t be loaded. This will remove the recursion

during loading of fonts. And afterwards a default physical font can then still

be resolved, even if our font configuration contains less fonts (no true type

fonts).



In my change I also add small improvements to the exception cases when

trying to load non-existent true type fonts and to method

getDefaultPhysicalFont.



The test exercises font loading and it would demonstrate the issue without

the fix on several of our AIX systems.



Here is the webrev:

http://cr.openjdk.java.net/~clanger/webrevs/8221741.0/



@Ichiroh-san: Can you test this fix in your environment and let me know if

it fixes your issue?



I'll run a full platform test here at SAP, including JDK11.



If this can get reviewed, I intend to push this fix to JDK14.



Thanks & Best regards

Christoph



-----Original Message-----

From: Phil Race <philip.race at oracle.com><mailto:philip.race at oracle.com>

Sent: Mittwoch, 30. Oktober 2019 17:07

To: Langer, Christoph <christoph.langer at sap.com><mailto:christoph.langer at sap.com>; Ichiroh Takiguchi

<takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com><mailto:arno.zeller at sap.com>

Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen

when fontconfig.properties was used



Yes probably best if this is reviewed and approved by someone who

has access to AIX. I have no idea if the XLFDs are even correct ...



-phil.



On 10/30/19 8:00 AM, Langer, Christoph wrote:

Hi Ichiroh,



I'm currently observing a test issue on one of our AIX boxes with that

patch

in place. Please give me some time to have a closer look...

Best regards

Christoph



-----Original Message-----

From: 2d-dev <2d-dev-bounces at openjdk.java.net><mailto:2d-dev-bounces at openjdk.java.net> On Behalf Of

Ichiroh

Takiguchi

Sent: Montag, 28. Oktober 2019 17:59

To: Philip Race <philip.race at oracle.com><mailto:philip.race at oracle.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Zeller, Arno <arno.zeller at sap.com><mailto:arno.zeller at sap.com>

Subject: Re: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException

happen

when fontconfig.properties was used



Hello Phil and other reviewers.



I appreciate if you give me your comment and suggestion.



Thanks,

Ichiroh Takiguchi



On 2019-10-15 20:33, Ichiroh Takiguchi wrote:

Hello Phil.



Sorry for bad response.



AIX is following case, but physical font is not defined by default.

If you have fonts installed and have a custom fontconfig.properties

file for AIX

which references those, then you should be able to get a default

font

from that

set of known existent physical fonts.

Please try following steps to emulate same kind this on linux (RHEL7).

1. Download DefaultFontTestA.java and fontconfig.properties files

     Please modify fontconfig.properties if c0419bt_.pfb is not in

/usr/share/X11/fonts/Type1 directory.



2. Compile and run with following options and environment variable.

      $ javac --add-exports java.desktop/sun.font=ALL-UNNAMED

DefaultFontTestA.java

      $ USE_J2D_FONTCONFIG=no java --add-opens

java.desktop/sun.font=ALL-UNNAMED

-Dsun.awt.fontconfigfontconfig.properties DefaultFontTestA

      defaultFontName=Dialog

      defaultFontFileName=/dialog.ttf

      Exception in thread "main" java.lang.ClassCastException: class

sun.font.CompositeFont cannot be cast to class sun.font.PhysicalFont

(sun.font.CompositeFont and sun.font.PhysicalFont are in module

java.desktop of loader 'bootstrap')

              at





java.desktop/sun.font.SunFontManager.getDefaultPhysicalFont(SunFontMa

nager.java:1081)

              at DefaultFontTestA.main(DefaultFontTestA.java:48)



         Font2D font2d =

              findFont2D(getDefaultFontFaceName(), Font.PLAIN,

NO_FALLBACK);

    Note:

      USE_J2D_FONTCONFIG is defined into

src/java.desktop/unix/native/common/awt/fontpath.c

      Dialog and /dialog.ttf are defined into

src/java.desktop/unix/classes/sun/awt/FcFontManager.java



getDefaultFontFaceName returns defaultFontName, it's "Dialog".

findFont2D() returns Dialog CompositeFont instead of physical font.

I think we cannot control return value for

physicalFonts.values().iterator();

"defaultPhysicalFont = ((CompositeFont) font2d).getSlotFont(0);" is

useful.



Please give me your comment.



Thanks,

Ichiroh Takiguchi



On 2019-10-09 01:06, Philip Race wrote:

I think this needs a little bit more explanation first.

Systems without fontconfig ... meaning without libfontconfig.

So does that mean you just can't find fonts or have none installed ?

If you have fonts installed and have a custom fontconfig.properties

file for AIX

which references those, then you should be able to get a default

font

from that

set of known existent physical fonts.



If you have neither .. then you have a system configuration problem

and without

a physical font installed avoiding an exception here isn't really

going to help you

get much further. Perhaps we should throw InternalError a bit

earlier.

I see no point in trying to survive ..



-phil





On 10/8/19, 12:35 AM, Langer, Christoph wrote:

Hi Ichiroh,



thanks for the update. It looks good to me. I'll run it through test

system tonight and let you know if we see issues by tomorrow.

Should

you not hear back from me, consider it as reviewed and tested ??



Thanks

Christoph



-----Original Message-----

From: Ichiroh Takiguchi<takiguc at linux.vnet.ibm.com><mailto:takiguc at linux.vnet.ibm.com>

Sent: Montag, 7. Oktober 2019 19:16

To: Langer, Christoph<christoph.langer at sap.com><mailto:christoph.langer at sap.com>

Cc: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>; Zeller,

Arno<arno.zeller at sap.com><mailto:arno.zeller at sap.com>

Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException

happen

when fontconfig.properties was used



Hello Christoph.



I appreciate your suggestion.

JTreg testcase could throw ClassCastException instead of

InvocationTargetException.

JTreg results were in JDK-8221741



Bug:    https://bugs.openjdk.java.net/browse/JDK-8221741

Change:

https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.05/

Could you review the fix ?



Thanks,

Ichiroh Takiguchi

IBM Japan, Ltd.



On 2019-10-07 22:53, Langer, Christoph wrote:

Hi Ichiroh,



this is great, thanks for doing this. We regularly see this and

just

stumbled over it the other day where the fontconfig of our test

user

was corrupted somehow.



As for the test, I would reduce the amount of reflection a little

bit.

It should not be necessary to access SunFontManager via

Class.forName,

you already exported it to the test via the @modules statement.

You

can probably use this coding (please try as I didn't test it??):



           SunFontManager sfm = SunFontManager.getInstance();

           Field defaultFontName_fid =

SunFontManager.class.getDeclaredField("defaultFontName");

           defaultFontName_fid.setAccessible(true);

           defaultFontName_fid.set(sfm, "Dialog");

           Method loadFonts_mid =

SunFontManager.class.getDeclaredMethod("loadFonts");

           loadFonts_mid.setAccessible(true);

           loadFonts_mid.invoke(sfm);

           PhysicalFont physicalFont = sfm.getDefaultPhysicalFont();

           System.out.println(physicalFont);



If you want, I can run your (updated) patch through our test

system.



Thanks

Christoph





-----Original Message-----

From: 2d-dev<2d-dev-bounces at openjdk.java.net><mailto:2d-dev-bounces at openjdk.java.net>  On Behalf

Of

Ichiroh

Takiguchi

Sent: Montag, 7. Oktober 2019 09:33

To: 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>

Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException

happen

when

fontconfig.properties was used



Hello.



Could you review the fix ?



Bug:    https://bugs.openjdk.java.net/browse/JDK-8221741

Change:

https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.04/

JTreg testcase and results are including JDK-8221741 [1].



[1] https://bugs.openjdk.java.net/browse/JDK-8221741



Thanks,

Ichiroh Takiguchi

IBM Japan, Ltd.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200124/005baa7a/attachment-0001.htm>

From matthias.baesken at sap.com  Mon Jan 27 08:34:36 2020
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 27 Jan 2020 08:34:36 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when
 fontconfig.properties was used
In-Reply-To: <AM0PR02MB57143C85AD8D9385DD44DFF78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>
References: <d741c0c4e6305a8f7abfbeaa675bd645@linux.vnet.ibm.com>
 <AM6PR02MB51924907C429846DEBE14DF98A9B0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com>
 <AM6PR02MB519284629C4998C1CB876F108A9A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <5D9CB3F8.9070205@oracle.com>
 <ffeb92a47867fc4358cd32234d023506@linux.vnet.ibm.com>
 <cd36eb93912d9ada00c6d98577421ac6@linux.vnet.ibm.com>
 <AM6PR02MB4801FEA742BC257853715D318A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <d59e8be7-30e4-fade-25ff-50b5175a40bc@oracle.com>
 <DB8PR02MB55474C1E88EE3AEF8B5720C88A530@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <4cd9707f-ad4e-57db-2d3d-3ed1757f95e9@oracle.com>
 <DB8PR02MB554775727D59605A49B1B5A88A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <bfb767ad-76f2-ea39-1e38-cea9657180dc@oracle.com>
 <DB8PR02MB55477062EB2C53F4384083208A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <dc830333-d0e3-f5e7-7ded-0b51accb692c@oracle.com>
 <DB8PR02MB5547A0B57080BAA3E578C71D8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <AM0PR02MB57146C9A4F95019A03DEADCE8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57143C85AD8D9385DD44DFF78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB422790E5E831FCE7F8D5F90F930B0@AM0PR02MB4227.eurprd02.prod.outlook.com>

Hello Christoph, looks good to me .

Some minor nits :

SunFontManager.java


  *   Why did you add the initialization ?

954         PhysicalFont physicalFont = null;



  *   Copyright headers of the java files should be adjusted to 2020


Thanks, Matthias


From: Langer, Christoph
Sent: Freitag, 24. Januar 2020 09:52
To: Phil Race <philip.race at oracle.com<mailto:philip.race at oracle.com>>; 2d-dev at openjdk.java.net<mailto:2d-dev at openjdk.java.net>
Cc: Ichiroh Takiguchi <takiguc at linux.vnet.ibm.com<mailto:takiguc at linux.vnet.ibm.com>>
Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when fontconfig.properties was used

Ping?

http://cr.openjdk.java.net/~clanger/webrevs/8221741.1/

May I submit this fix to jdk-client? Or what would you want me to change to get it accepted?

This is running for weeks now in our CI infra (on various systems and platforms) and showing no problems?

Thanks
Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200127/bca121a0/attachment.htm>

From dmitry.batrak at jetbrains.com  Mon Jan 27 09:10:32 2020
From: dmitry.batrak at jetbrains.com (Dmitry Batrak)
Date: Mon, 27 Jan 2020 12:10:32 +0300
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <9e5957ca-d0f8-a0da-4c5c-8bdf38e7e08c@oracle.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
 <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
 <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>
 <CAET5FPuOwLDpKGE_Byr4QR+tHyo1QMXxQyg4YMuz-bBFcA5SXw@mail.gmail.com>
 <9e5957ca-d0f8-a0da-4c5c-8bdf38e7e08c@oracle.com>
Message-ID: <CAET5FPukbT9cPjBY9jRMrUvPCeSVnzO1Y=ti01M_mOxM09xzAA@mail.gmail.com>

Thanks!
Now that that change has two +1's, would anyone be able to push it?

Best regards,
Dmitry Batrak

On Tue, Jan 21, 2020 at 8:05 AM Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
wrote:

> Looks fine.
> Thank you for contribution!
>
> On 1/20/20 12:14 am, Dmitry Batrak wrote:
> >  > Ok approved. Seems it is making a few things better if not ideal, but
> nothing worse.
> >
> > Thanks!
> > Anyone else volunteering to review?
> >
> > Best regards,
> > Dmitry Batrak
> >
> > On Tue, Jan 14, 2020 at 8:58 PM Phil Race <philip.race at oracle.com
> <mailto:philip.race at oracle.com>> wrote:
> >
> >     Ok approved. Seems it is making a few things better if not ideal,
> but nothing worse.
> >
> >     -phil.
> >
> >     On 1/14/20 8:14 AM, Dmitry Batrak wrote:
> >>     > So this is a workaround for a buggy font that doesn't play well
> with GDI ?
> >>
> >>     This is a workaround for all cases (or the vast majority of them)
> of broken
> >>     rendering reported by our customers. The case with Roboto is just
> the one we
> >>     have steps to reproduce for. There can be other cases where GDI's
> logic is not
> >>     matched by JDK. Even if all of them are caused by 'mis-constructed'
> fonts, I'm
> >>     afraid, this will not be considered as a good excuse by our
> customers, as only
> >>     Java applications have such problems with these fonts.
> >>
> >>     See JDK-8192972, still unsolved in OpenJDK, as an example of the
> problems which
> >>     will be, at least partially, solved with this fix (correct glyphs
> will be
> >>     rendered, albeit using FreeType).
> >>
> >>     I did test the fix with fonts preinstalled in Windows 10. Fallback
> was actually
> >>     triggered for one font (bold italic 'Segoe UI Semibold'), which is
> not a 'false'
> >>     positive, but actually a manifestation of another JDK bug from the
> same family -
> >>     I've just raised https://bugs.openjdk.java.net/browse/JDK-8237085
> for it. That's
> >>     yet another example of an issue which will be (mostly) solved by
> the proposed
> >>     fix.
> >>
> >>     Using file length as a 'checksum' certainly doesn't guarantee we
> choose the
> >>     right font, but the probability of error is very low, and this
> value seems to be
> >>     the best candidate in our circumstances in terms of cost vs.
> benefit. Even if
> >>     the validation mistreats a different font (having the same length)
> as a correct
> >>     one, we'll not be in a worse position than before.
> >>
> >>     Of course, there's a certain risk that rendering for unaffected
> fonts might
> >>     change, but, given quite straightforward contract of GetFontData
> function, I
> >>     would consider it very low.
> >>
> >>     > Since you aren't retrieving the data, just asking what the size
> is, I'd expect
> >>     > it to be unmeasurable.
> >>
> >>     Well, we don't know how GetFontData works exactly, but it does seem
> to add some
> >>     overhead. On my Windows 10 machine OpenJDK with the proposed fix
> yields about 7%
> >>     larger result for the following benchmark program. The reported
> value does
> >>     fluctuate from run to run, but the impact of the fix seems to be
> larger than the
> >>     fluctuations.
> >>
> >>     --- Benchmark source code ----
> >>     import java.awt.*;
> >>     import java.awt.font.GlyphVector;
> >>     import java.awt.image.BufferedImage;
> >>
> >>     public class PerfTestOneFont {
> >>         private static final Font FONT = new Font("Segoe UI",
> Font.PLAIN, 12);
> >>
> >>         public static void main(String[] args) {
> >>             FONT.getFamily(); // preload font
> >>
> >>             BufferedImage image = new BufferedImage(1, 1,
> BufferedImage.TYPE_INT_RGB);
> >>             Graphics2D g = image.createGraphics();
> >>     g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
> >>     RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
> >>             int glyphCount = FONT.getNumGlyphs();
> >>             long startTime = System.currentTimeMillis();
> >>             for (int glyphCode = 0; glyphCode < glyphCount;
> glyphCode++) {
> >>                 GlyphVector gv =
> FONT.createGlyphVector(g.getFontRenderContext(),
> >>                                            new int[]{glyphCode});
> >>                 g.drawGlyphVector(gv, 0, 0);
> >>             }
> >>             long endTime = System.currentTimeMillis();
> >>             g.dispose();
> >>             System.out.println(endTime - startTime);
> >>         }
> >>     }
> >>     ------------------------------
> >>
> >>     Best regards,
> >>     Dmitry Batrak
> >>
> >>     On Mon, Jan 13, 2020 at 11:09 PM Phil Race <philip.race at oracle.com
> <mailto:philip.race at oracle.com>> wrote:
> >>
> >>         So this is a workaround for a buggy font that doesn't play well
> with GDI ?
> >>
> >>         It does rely on the fonts always being different sizes which is
> highly
> >>         likely if not guaranteed.
> >>         I suppose it is OK so long as we aren't getting any "false"
> positives.
> >>
> >>         What I mean is that almost no one will have these Roboto fonts
> >>         installed, so the fix
> >>         is solving a problem they don't have, but if it is wrong in
> some way,
> >>         then they could lose
> >>         GDI rendering of LCD glyphs and that could affect a lot of
> people.
> >>
> >>         So have you tested this with the full set of Windows 10 fonts -
> >>         including Indic, CJK, etc  - to be sure
> >>         there are no cases where it fails for these or other spurious
> failures.
> >>
> >>          > As for performance impact, during testing I didn't observe
> average
> >>         glyph generation time increase of more than 15%.
> >>
> >>         Since you aren't retrieving the data, just asking what the size
> is, I'd
> >>         expect it to be unmeasurable.
> >>
> >>         -phil.
> >>
> >>         On 1/13/20 1:25 AM, Dmitry Batrak wrote:
> >>         > Hello,
> >>         >
> >>         > I'd like to submit a patch for JDK-8236996. I'm not a
> Committer, so
> >>         > I'll need someone to sponsor this change.
> >>         >
> >>         > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
> >>         > Webrev:
> http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
> >>         >
> >>         > The problem described in JDK-8236996 is from a group of
> issues (see
> >>         > also e.g. JDK-8078382 and JDK-8192972), where JDK
> >>         > uses one font to perform char-to-glyph conversion, but GDI,
> when asked
> >>         > to render the glyph is picking a different font,
> >>         > leading to completely random glyphs being rendered, as
> char-to-glyph
> >>         > mapping obviously differs for different fonts.
> >>         >
> >>         > Specific version of Roboto font, mentioned in JDK-8236996, is
> most
> >>         > probably causing the issue because it's not following
> >>         > the naming guidelines from OpenType specification
> >>         > (
> https://docs.microsoft.com/en-us/typography/opentype/spec/name),
> >>         > having more than 4 variants (regular, bold, italic and bold
> italic)
> >>         > with the same 'Font Family name' (name ID = 1). So,
> >>         > GDI gets confused and picks Roboto Black for rendering, when
> asked to
> >>         > choose a regular font from Roboto family (Roboto
> >>         > Black having weight of 400, just like Roboto Regular,
> probably adds to
> >>         > the confusion).
> >>         >
> >>         > But the reasoning, given above, about the issue cause is only
> a guess.
> >>         > GDI is not an open-source subsystem, so we cannot
> >>         > know for sure how it selects the font for rendering, and
> cannot
> >>         > implement matching logic in JDK. Ideally, we'd want to
> >>         > select the font by specifying its file path, but that's not
> possible
> >>         > with GDI. Luckily, it allows us to query file data
> >>         > for the selected font using GetFontData function
> >>         > (
> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata
> ),
> >>         > which we can use to validate that the
> >>         > selected font is the one we need.
> >>         >
> >>         > The proposed solution is to check the file size of the font,
> selected
> >>         > by GDI, before using it for rendering. If a mismatch
> >>         > is detected, fallback to FreeType is performed. It can
> produce a
> >>         > somewhat different glyph representation, but, at least,
> >>         > the correct glyph will be rendered. For members of font
> collections,
> >>         > file size for validation is calculated in a special
> >>         > way, in accordance with GetFontData logic described in the
> >>         > documentation. I've verified that it works for font
> collections
> >>         > bundled with Windows 10.
> >>         >
> >>         > As for performance impact, during testing I didn't observe
> average
> >>         > glyph generation time increase of more than 15%.
> >>         > Taking glyph caching into account, it shouldn't be that
> significant
> >>         > for typical UI applications, I think. Performance
> >>         > impact can be made even smaller - by performing the
> validation only
> >>         > once per font, but, I believe, having a Java
> >>         > application always render correct glyphs (even if fonts are
> added or
> >>         > removed while application is running) is more
> >>         > important.
> >>         >
> >>         > Proposed patch doesn't add any tests, as reproducing the issue
> >>         > requires installation of fonts. Existing automated
> >>         > OpenJDK tests pass after the fix. Proposed approach has been
> used in
> >>         > JetBrains Runtime without known issues for about 3
> >>         > months in testing and for about 1 month in production.
> >>         >
> >>         > Best regards,
> >>         > Dmitry Batrak
> >>
> >>
> >
> >
> >
>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200127/3a0b64f1/attachment-0001.htm>

From philip.race at oracle.com  Mon Jan 27 17:46:00 2020
From: philip.race at oracle.com (Philip Race)
Date: Mon, 27 Jan 2020 09:46:00 -0800
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <CAET5FPukbT9cPjBY9jRMrUvPCeSVnzO1Y=ti01M_mOxM09xzAA@mail.gmail.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
 <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
 <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>
 <CAET5FPuOwLDpKGE_Byr4QR+tHyo1QMXxQyg4YMuz-bBFcA5SXw@mail.gmail.com>
 <9e5957ca-d0f8-a0da-4c5c-8bdf38e7e08c@oracle.com>
 <CAET5FPukbT9cPjBY9jRMrUvPCeSVnzO1Y=ti01M_mOxM09xzAA@mail.gmail.com>
Message-ID: <5E2F21D8.5060800@oracle.com>

I'll do this for you.

-phil.

On 1/27/20, 1:10 AM, Dmitry Batrak wrote:
> Thanks!
> Now that that change has two +1's, would anyone be able to push it?
>
> Best regards,
> Dmitry Batrak
>
> On Tue, Jan 21, 2020 at 8:05 AM Sergey Bylokhov 
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     Looks fine.
>     Thank you for contribution!
>
>     On 1/20/20 12:14 am, Dmitry Batrak wrote:
>     > > Ok approved. Seems it is making a few things better if not
>     ideal, but nothing worse.
>     >
>     > Thanks!
>     > Anyone else volunteering to review?
>     >
>     > Best regards,
>     > Dmitry Batrak
>     >
>     > On Tue, Jan 14, 2020 at 8:58 PM Phil Race
>     <philip.race at oracle.com <mailto:philip.race at oracle.com>
>     <mailto:philip.race at oracle.com <mailto:philip.race at oracle.com>>>
>     wrote:
>     >
>     >     Ok approved. Seems it is making a few things better if not
>     ideal, but nothing worse.
>     >
>     >     -phil.
>     >
>     >     On 1/14/20 8:14 AM, Dmitry Batrak wrote:
>     >> > So this is a workaround for a buggy font that doesn't play
>     well with GDI ?
>     >>
>     >>     This is a workaround for all cases (or the vast majority of
>     them) of broken
>     >>     rendering reported by our customers. The case with Roboto
>     is just the one we
>     >>     have steps to reproduce for. There can be other cases where
>     GDI's logic is not
>     >>     matched by JDK. Even if all of them are caused by
>     'mis-constructed' fonts, I'm
>     >>     afraid, this will not be considered as a good excuse by our
>     customers, as only
>     >>     Java applications have such problems with these fonts.
>     >>
>     >>     See JDK-8192972, still unsolved in OpenJDK, as an example
>     of the problems which
>     >>     will be, at least partially, solved with this fix (correct
>     glyphs will be
>     >>     rendered, albeit using FreeType).
>     >>
>     >>     I did test the fix with fonts preinstalled in Windows 10.
>     Fallback was actually
>     >>     triggered for one font (bold italic 'Segoe UI Semibold'),
>     which is not a 'false'
>     >>     positive, but actually a manifestation of another JDK bug
>     from the same family -
>     >>     I've just raised
>     https://bugs.openjdk.java.net/browse/JDK-8237085 for it. That's
>     >>     yet another example of an issue which will be (mostly)
>     solved by the proposed
>     >>     fix.
>     >>
>     >>     Using file length as a 'checksum' certainly doesn't
>     guarantee we choose the
>     >>     right font, but the probability of error is very low, and
>     this value seems to be
>     >>     the best candidate in our circumstances in terms of cost
>     vs. benefit. Even if
>     >>     the validation mistreats a different font (having the same
>     length) as a correct
>     >>     one, we'll not be in a worse position than before.
>     >>
>     >>     Of course, there's a certain risk that rendering for
>     unaffected fonts might
>     >>     change, but, given quite straightforward contract of
>     GetFontData function, I
>     >>     would consider it very low.
>     >>
>     >> > Since you aren't retrieving the data, just asking what the
>     size is, I'd expect
>     >> > it to be unmeasurable.
>     >>
>     >>     Well, we don't know how GetFontData works exactly, but it
>     does seem to add some
>     >>     overhead. On my Windows 10 machine OpenJDK with the
>     proposed fix yields about 7%
>     >>     larger result for the following benchmark program. The
>     reported value does
>     >>     fluctuate from run to run, but the impact of the fix seems
>     to be larger than the
>     >>     fluctuations.
>     >>
>     >>     --- Benchmark source code ----
>     >>     import java.awt.*;
>     >>     import java.awt.font.GlyphVector;
>     >>     import java.awt.image.BufferedImage;
>     >>
>     >>     public class PerfTestOneFont {
>     >>         private static final Font FONT = new Font("Segoe UI",
>     Font.PLAIN, 12);
>     >>
>     >>         public static void main(String[] args) {
>     >>             FONT.getFamily(); // preload font
>     >>
>     >>             BufferedImage image = new BufferedImage(1, 1,
>     BufferedImage.TYPE_INT_RGB);
>     >>             Graphics2D g = image.createGraphics();
>     >>     g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
>     >>     RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
>     >>             int glyphCount = FONT.getNumGlyphs();
>     >>             long startTime = System.currentTimeMillis();
>     >>             for (int glyphCode = 0; glyphCode < glyphCount;
>     glyphCode++) {
>     >>                 GlyphVector gv =
>     FONT.createGlyphVector(g.getFontRenderContext(),
>     >>                                            new int[]{glyphCode});
>     >>                 g.drawGlyphVector(gv, 0, 0);
>     >>             }
>     >>             long endTime = System.currentTimeMillis();
>     >>             g.dispose();
>     >>             System.out.println(endTime - startTime);
>     >>         }
>     >>     }
>     >>     ------------------------------
>     >>
>     >>     Best regards,
>     >>     Dmitry Batrak
>     >>
>     >>     On Mon, Jan 13, 2020 at 11:09 PM Phil Race
>     <philip.race at oracle.com <mailto:philip.race at oracle.com>
>     <mailto:philip.race at oracle.com <mailto:philip.race at oracle.com>>>
>     wrote:
>     >>
>     >>         So this is a workaround for a buggy font that doesn't
>     play well with GDI ?
>     >>
>     >>         It does rely on the fonts always being different sizes
>     which is highly
>     >>         likely if not guaranteed.
>     >>         I suppose it is OK so long as we aren't getting any
>     "false" positives.
>     >>
>     >>         What I mean is that almost no one will have these
>     Roboto fonts
>     >>         installed, so the fix
>     >>         is solving a problem they don't have, but if it is
>     wrong in some way,
>     >>         then they could lose
>     >>         GDI rendering of LCD glyphs and that could affect a lot
>     of people.
>     >>
>     >>         So have you tested this with the full set of Windows 10
>     fonts -
>     >>         including Indic, CJK, etc  - to be sure
>     >>         there are no cases where it fails for these or other
>     spurious failures.
>     >>
>     >> > As for performance impact, during testing I didn't observe
>     average
>     >>         glyph generation time increase of more than 15%.
>     >>
>     >>         Since you aren't retrieving the data, just asking what
>     the size is, I'd
>     >>         expect it to be unmeasurable.
>     >>
>     >>         -phil.
>     >>
>     >>         On 1/13/20 1:25 AM, Dmitry Batrak wrote:
>     >> > Hello,
>     >> >
>     >> > I'd like to submit a patch for JDK-8236996. I'm not a
>     Committer, so
>     >> > I'll need someone to sponsor this change.
>     >> >
>     >> > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
>     >> > Webrev:
>     http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
>     <http://cr.openjdk.java.net/%7Edbatrak/8236996/webrev.00/>
>     >> >
>     >> > The problem described in JDK-8236996 is from a group of
>     issues (see
>     >> > also e.g. JDK-8078382 and JDK-8192972), where JDK
>     >> > uses one font to perform char-to-glyph conversion, but GDI,
>     when asked
>     >> > to render the glyph is picking a different font,
>     >> > leading to completely random glyphs being rendered, as
>     char-to-glyph
>     >> > mapping obviously differs for different fonts.
>     >> >
>     >> > Specific version of Roboto font, mentioned in JDK-8236996, is
>     most
>     >> > probably causing the issue because it's not following
>     >> > the naming guidelines from OpenType specification
>     >> > (https://docs.microsoft.com/en-us/typography/opentype/spec/name),
>     >> > having more than 4 variants (regular, bold, italic and bold
>     italic)
>     >> > with the same 'Font Family name' (name ID = 1). So,
>     >> > GDI gets confused and picks Roboto Black for rendering, when
>     asked to
>     >> > choose a regular font from Roboto family (Roboto
>     >> > Black having weight of 400, just like Roboto Regular,
>     probably adds to
>     >> > the confusion).
>     >> >
>     >> > But the reasoning, given above, about the issue cause is only
>     a guess.
>     >> > GDI is not an open-source subsystem, so we cannot
>     >> > know for sure how it selects the font for rendering, and cannot
>     >> > implement matching logic in JDK. Ideally, we'd want to
>     >> > select the font by specifying its file path, but that's not
>     possible
>     >> > with GDI. Luckily, it allows us to query file data
>     >> > for the selected font using GetFontData function
>     >> >
>     (https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata),
>     >> > which we can use to validate that the
>     >> > selected font is the one we need.
>     >> >
>     >> > The proposed solution is to check the file size of the font,
>     selected
>     >> > by GDI, before using it for rendering. If a mismatch
>     >> > is detected, fallback to FreeType is performed. It can produce a
>     >> > somewhat different glyph representation, but, at least,
>     >> > the correct glyph will be rendered. For members of font
>     collections,
>     >> > file size for validation is calculated in a special
>     >> > way, in accordance with GetFontData logic described in the
>     >> > documentation. I've verified that it works for font collections
>     >> > bundled with Windows 10.
>     >> >
>     >> > As for performance impact, during testing I didn't observe
>     average
>     >> > glyph generation time increase of more than 15%.
>     >> > Taking glyph caching into account, it shouldn't be that
>     significant
>     >> > for typical UI applications, I think. Performance
>     >> > impact can be made even smaller - by performing the
>     validation only
>     >> > once per font, but, I believe, having a Java
>     >> > application always render correct glyphs (even if fonts are
>     added or
>     >> > removed while application is running) is more
>     >> > important.
>     >> >
>     >> > Proposed patch doesn't add any tests, as reproducing the issue
>     >> > requires installation of fonts. Existing automated
>     >> > OpenJDK tests pass after the fix. Proposed approach has been
>     used in
>     >> > JetBrains Runtime without known issues for about 3
>     >> > months in testing and for about 1 month in production.
>     >> >
>     >> > Best regards,
>     >> > Dmitry Batrak
>     >>
>     >>
>     >
>     >
>     >
>
>
>     -- 
>     Best regards, Sergey.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200127/ac1581fc/attachment-0001.htm>

From dmitry.batrak at jetbrains.com  Tue Jan 28 08:30:59 2020
From: dmitry.batrak at jetbrains.com (Dmitry Batrak)
Date: Tue, 28 Jan 2020 11:30:59 +0300
Subject: [OpenJDK 2D-Dev] [PATCH] 8236996: Incorrect Roboto font
 rendering on Windows with subpixel antialiasing
In-Reply-To: <5E2F21D8.5060800@oracle.com>
References: <CAET5FPszNEFtLnUzOH=BufHTSHOBoTZMLSndXCjyQkLM5f8=dg@mail.gmail.com>
 <6629e1a6-5c58-54f2-ad17-0250021a6292@oracle.com>
 <CAET5FPsWD=1ur6_ap7d0xsEW4o2O4HFARB4x-f9UVZWu0aP+cw@mail.gmail.com>
 <17d58fb1-c936-693b-f7ff-2bb5f18c172e@oracle.com>
 <CAET5FPuOwLDpKGE_Byr4QR+tHyo1QMXxQyg4YMuz-bBFcA5SXw@mail.gmail.com>
 <9e5957ca-d0f8-a0da-4c5c-8bdf38e7e08c@oracle.com>
 <CAET5FPukbT9cPjBY9jRMrUvPCeSVnzO1Y=ti01M_mOxM09xzAA@mail.gmail.com>
 <5E2F21D8.5060800@oracle.com>
Message-ID: <CAET5FPvxeVCx=o5++7_9cLQrFuit99XjEJNRFanERigTmDuA5Q@mail.gmail.com>

Thanks!

I also have a question about
https://bugs.openjdk.java.net/browse/JDK-8237085, which was assigned to me.
I'm not planning to work on it in the foreseeable future, beyond what was
already done in JDK-8236996.
What should I do with that ticket? Should I close that ticked as fixed,
mentioning that JDK-8236996 'mostly' fixes it? Should I remove myself from
the assignee field? Or should I just leave things as they are,
assuming that if someone will want to work on it, the issue will be
reassigned then?

Best regards,
Dmitry Batrak

On Mon, Jan 27, 2020 at 8:45 PM Philip Race <philip.race at oracle.com> wrote:

> I'll do this for you.
>
> -phil.
>
> On 1/27/20, 1:10 AM, Dmitry Batrak wrote:
>
> Thanks!
> Now that that change has two +1's, would anyone be able to push it?
>
> Best regards,
> Dmitry Batrak
>
> On Tue, Jan 21, 2020 at 8:05 AM Sergey Bylokhov <
> Sergey.Bylokhov at oracle.com> wrote:
>
>> Looks fine.
>> Thank you for contribution!
>>
>> On 1/20/20 12:14 am, Dmitry Batrak wrote:
>> >  > Ok approved. Seems it is making a few things better if not ideal,
>> but nothing worse.
>> >
>> > Thanks!
>> > Anyone else volunteering to review?
>> >
>> > Best regards,
>> > Dmitry Batrak
>> >
>> > On Tue, Jan 14, 2020 at 8:58 PM Phil Race <philip.race at oracle.com
>> <mailto:philip.race at oracle.com>> wrote:
>> >
>> >     Ok approved. Seems it is making a few things better if not ideal,
>> but nothing worse.
>> >
>> >     -phil.
>> >
>> >     On 1/14/20 8:14 AM, Dmitry Batrak wrote:
>> >>     > So this is a workaround for a buggy font that doesn't play well
>> with GDI ?
>> >>
>> >>     This is a workaround for all cases (or the vast majority of them)
>> of broken
>> >>     rendering reported by our customers. The case with Roboto is just
>> the one we
>> >>     have steps to reproduce for. There can be other cases where GDI's
>> logic is not
>> >>     matched by JDK. Even if all of them are caused by
>> 'mis-constructed' fonts, I'm
>> >>     afraid, this will not be considered as a good excuse by our
>> customers, as only
>> >>     Java applications have such problems with these fonts.
>> >>
>> >>     See JDK-8192972, still unsolved in OpenJDK, as an example of the
>> problems which
>> >>     will be, at least partially, solved with this fix (correct glyphs
>> will be
>> >>     rendered, albeit using FreeType).
>> >>
>> >>     I did test the fix with fonts preinstalled in Windows 10. Fallback
>> was actually
>> >>     triggered for one font (bold italic 'Segoe UI Semibold'), which is
>> not a 'false'
>> >>     positive, but actually a manifestation of another JDK bug from the
>> same family -
>> >>     I've just raised https://bugs.openjdk.java.net/browse/JDK-8237085
>> for it. That's
>> >>     yet another example of an issue which will be (mostly) solved by
>> the proposed
>> >>     fix.
>> >>
>> >>     Using file length as a 'checksum' certainly doesn't guarantee we
>> choose the
>> >>     right font, but the probability of error is very low, and this
>> value seems to be
>> >>     the best candidate in our circumstances in terms of cost vs.
>> benefit. Even if
>> >>     the validation mistreats a different font (having the same length)
>> as a correct
>> >>     one, we'll not be in a worse position than before.
>> >>
>> >>     Of course, there's a certain risk that rendering for unaffected
>> fonts might
>> >>     change, but, given quite straightforward contract of GetFontData
>> function, I
>> >>     would consider it very low.
>> >>
>> >>     > Since you aren't retrieving the data, just asking what the size
>> is, I'd expect
>> >>     > it to be unmeasurable.
>> >>
>> >>     Well, we don't know how GetFontData works exactly, but it does
>> seem to add some
>> >>     overhead. On my Windows 10 machine OpenJDK with the proposed fix
>> yields about 7%
>> >>     larger result for the following benchmark program. The reported
>> value does
>> >>     fluctuate from run to run, but the impact of the fix seems to be
>> larger than the
>> >>     fluctuations.
>> >>
>> >>     --- Benchmark source code ----
>> >>     import java.awt.*;
>> >>     import java.awt.font.GlyphVector;
>> >>     import java.awt.image.BufferedImage;
>> >>
>> >>     public class PerfTestOneFont {
>> >>         private static final Font FONT = new Font("Segoe UI",
>> Font.PLAIN, 12);
>> >>
>> >>         public static void main(String[] args) {
>> >>             FONT.getFamily(); // preload font
>> >>
>> >>             BufferedImage image = new BufferedImage(1, 1,
>> BufferedImage.TYPE_INT_RGB);
>> >>             Graphics2D g = image.createGraphics();
>> >>     g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING,
>> >>     RenderingHints.VALUE_TEXT_ANTIALIAS_LCD_HRGB);
>> >>             int glyphCount = FONT.getNumGlyphs();
>> >>             long startTime = System.currentTimeMillis();
>> >>             for (int glyphCode = 0; glyphCode < glyphCount;
>> glyphCode++) {
>> >>                 GlyphVector gv =
>> FONT.createGlyphVector(g.getFontRenderContext(),
>> >>                                            new int[]{glyphCode});
>> >>                 g.drawGlyphVector(gv, 0, 0);
>> >>             }
>> >>             long endTime = System.currentTimeMillis();
>> >>             g.dispose();
>> >>             System.out.println(endTime - startTime);
>> >>         }
>> >>     }
>> >>     ------------------------------
>> >>
>> >>     Best regards,
>> >>     Dmitry Batrak
>> >>
>> >>     On Mon, Jan 13, 2020 at 11:09 PM Phil Race <philip.race at oracle.com
>> <mailto:philip.race at oracle.com>> wrote:
>> >>
>> >>         So this is a workaround for a buggy font that doesn't play
>> well with GDI ?
>> >>
>> >>         It does rely on the fonts always being different sizes which
>> is highly
>> >>         likely if not guaranteed.
>> >>         I suppose it is OK so long as we aren't getting any "false"
>> positives.
>> >>
>> >>         What I mean is that almost no one will have these Roboto fonts
>> >>         installed, so the fix
>> >>         is solving a problem they don't have, but if it is wrong in
>> some way,
>> >>         then they could lose
>> >>         GDI rendering of LCD glyphs and that could affect a lot of
>> people.
>> >>
>> >>         So have you tested this with the full set of Windows 10 fonts -
>> >>         including Indic, CJK, etc  - to be sure
>> >>         there are no cases where it fails for these or other spurious
>> failures.
>> >>
>> >>          > As for performance impact, during testing I didn't observe
>> average
>> >>         glyph generation time increase of more than 15%.
>> >>
>> >>         Since you aren't retrieving the data, just asking what the
>> size is, I'd
>> >>         expect it to be unmeasurable.
>> >>
>> >>         -phil.
>> >>
>> >>         On 1/13/20 1:25 AM, Dmitry Batrak wrote:
>> >>         > Hello,
>> >>         >
>> >>         > I'd like to submit a patch for JDK-8236996. I'm not a
>> Committer, so
>> >>         > I'll need someone to sponsor this change.
>> >>         >
>> >>         > Issue: https://bugs.openjdk.java.net/browse/JDK-8236996
>> >>         > Webrev:
>> http://cr.openjdk.java.net/~dbatrak/8236996/webrev.00/
>> >>         >
>> >>         > The problem described in JDK-8236996 is from a group of
>> issues (see
>> >>         > also e.g. JDK-8078382 and JDK-8192972), where JDK
>> >>         > uses one font to perform char-to-glyph conversion, but GDI,
>> when asked
>> >>         > to render the glyph is picking a different font,
>> >>         > leading to completely random glyphs being rendered, as
>> char-to-glyph
>> >>         > mapping obviously differs for different fonts.
>> >>         >
>> >>         > Specific version of Roboto font, mentioned in JDK-8236996,
>> is most
>> >>         > probably causing the issue because it's not following
>> >>         > the naming guidelines from OpenType specification
>> >>         > (
>> https://docs.microsoft.com/en-us/typography/opentype/spec/name),
>> >>         > having more than 4 variants (regular, bold, italic and bold
>> italic)
>> >>         > with the same 'Font Family name' (name ID = 1). So,
>> >>         > GDI gets confused and picks Roboto Black for rendering, when
>> asked to
>> >>         > choose a regular font from Roboto family (Roboto
>> >>         > Black having weight of 400, just like Roboto Regular,
>> probably adds to
>> >>         > the confusion).
>> >>         >
>> >>         > But the reasoning, given above, about the issue cause is
>> only a guess.
>> >>         > GDI is not an open-source subsystem, so we cannot
>> >>         > know for sure how it selects the font for rendering, and
>> cannot
>> >>         > implement matching logic in JDK. Ideally, we'd want to
>> >>         > select the font by specifying its file path, but that's not
>> possible
>> >>         > with GDI. Luckily, it allows us to query file data
>> >>         > for the selected font using GetFontData function
>> >>         > (
>> https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getfontdata
>> ),
>> >>         > which we can use to validate that the
>> >>         > selected font is the one we need.
>> >>         >
>> >>         > The proposed solution is to check the file size of the font,
>> selected
>> >>         > by GDI, before using it for rendering. If a mismatch
>> >>         > is detected, fallback to FreeType is performed. It can
>> produce a
>> >>         > somewhat different glyph representation, but, at least,
>> >>         > the correct glyph will be rendered. For members of font
>> collections,
>> >>         > file size for validation is calculated in a special
>> >>         > way, in accordance with GetFontData logic described in the
>> >>         > documentation. I've verified that it works for font
>> collections
>> >>         > bundled with Windows 10.
>> >>         >
>> >>         > As for performance impact, during testing I didn't observe
>> average
>> >>         > glyph generation time increase of more than 15%.
>> >>         > Taking glyph caching into account, it shouldn't be that
>> significant
>> >>         > for typical UI applications, I think. Performance
>> >>         > impact can be made even smaller - by performing the
>> validation only
>> >>         > once per font, but, I believe, having a Java
>> >>         > application always render correct glyphs (even if fonts are
>> added or
>> >>         > removed while application is running) is more
>> >>         > important.
>> >>         >
>> >>         > Proposed patch doesn't add any tests, as reproducing the
>> issue
>> >>         > requires installation of fonts. Existing automated
>> >>         > OpenJDK tests pass after the fix. Proposed approach has been
>> used in
>> >>         > JetBrains Runtime without known issues for about 3
>> >>         > months in testing and for about 1 month in production.
>> >>         >
>> >>         > Best regards,
>> >>         > Dmitry Batrak
>> >>
>> >>
>> >
>> >
>> >
>>
>>
>> --
>> Best regards, Sergey.
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200128/7284ded1/attachment-0001.htm>

From christoph.langer at sap.com  Tue Jan 28 13:23:51 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 28 Jan 2020 13:23:51 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen when
 fontconfig.properties was used
In-Reply-To: <AM0PR02MB422790E5E831FCE7F8D5F90F930B0@AM0PR02MB4227.eurprd02.prod.outlook.com>
References: <d741c0c4e6305a8f7abfbeaa675bd645@linux.vnet.ibm.com>
 <AM6PR02MB51924907C429846DEBE14DF98A9B0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <6d0a564efe230c566d0259676e1cb49a@linux.vnet.ibm.com>
 <AM6PR02MB519284629C4998C1CB876F108A9A0@AM6PR02MB5192.eurprd02.prod.outlook.com>
 <5D9CB3F8.9070205@oracle.com>
 <ffeb92a47867fc4358cd32234d023506@linux.vnet.ibm.com>
 <cd36eb93912d9ada00c6d98577421ac6@linux.vnet.ibm.com>
 <AM6PR02MB4801FEA742BC257853715D318A600@AM6PR02MB4801.eurprd02.prod.outlook.com>
 <d59e8be7-30e4-fade-25ff-50b5175a40bc@oracle.com>
 <DB8PR02MB55474C1E88EE3AEF8B5720C88A530@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <4cd9707f-ad4e-57db-2d3d-3ed1757f95e9@oracle.com>
 <DB8PR02MB554775727D59605A49B1B5A88A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <bfb767ad-76f2-ea39-1e38-cea9657180dc@oracle.com>
 <DB8PR02MB55477062EB2C53F4384083208A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <dc830333-d0e3-f5e7-7ded-0b51accb692c@oracle.com>
 <DB8PR02MB5547A0B57080BAA3E578C71D8A520@DB8PR02MB5547.eurprd02.prod.outlook.com>
 <AM0PR02MB57146C9A4F95019A03DEADCE8A0E0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB57143C85AD8D9385DD44DFF78A0B0@AM0PR02MB5714.eurprd02.prod.outlook.com>
 <AM0PR02MB422790E5E831FCE7F8D5F90F930B0@AM0PR02MB4227.eurprd02.prod.outlook.com>
Message-ID: <AM0PR02MB57141586FD4FEC603645EF2B8A0A0@AM0PR02MB5714.eurprd02.prod.outlook.com>

Hi Matthias,

thanks for looking at this change.

> Some minor nits :
> 
> SunFontManager.java
> 
> - Why did you add the initialization ?
> 
> 954???????? PhysicalFont physicalFont = null;

This is required, because in line 981, physicalFont is returned. With my changes to line 976 it is not guaranteed any more that it will be initialized on each path of the code so javac would complain.

> 
> 
> - Copyright headers of the java files should be adjusted to 2020

I think since I've done all that work in the last year, I'll leave the copyright years as is  - unless I have to do further changes.


So, with your review I think I can push this to jdk-client. I'll do that soon unless somebody wants to object in the last minute.

Cheers
Christoph

> 
> Thanks, Matthias
> 
> 
> From: Langer, Christoph
> Sent: Freitag, 24. Januar 2020 09:52
> To: Phil Race <mailto:philip.race at oracle.com>; mailto:2d-
> dev at openjdk.java.net
> Cc: Ichiroh Takiguchi <mailto:takiguc at linux.vnet.ibm.com>
> Subject: RE: [OpenJDK 2D-Dev] RFR: 8221741 ClassCastException happen
> when fontconfig.properties was used
> 
> Ping?
> 
> http://cr.openjdk.java.net/~clanger/webrevs/8221741.1/
> 
> May I submit this fix to jdk-client? Or what would you want me to change to
> get it accepted?
> 
> This is running for weeks now in our CI infra (on various systems and
> platforms) and showing no problems?
> 
> Thanks
> Christoph

From Sergey.Bylokhov at oracle.com  Wed Jan 29 04:15:00 2020
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 28 Jan 2020 20:15:00 -0800
Subject: [OpenJDK 2D-Dev] [15] Review Request: 8238075 [OGL] Delete unused
	properties
Message-ID: <19076fe4-7414-6aac-e112-a4d9d3799136@oracle.com>

Hello.
Please review the small cleanup for JDK 15.

Bug: https://bugs.openjdk.java.net/browse/JDK-8238075
Fix: http://cr.openjdk.java.net/~serb/8238075/webrev.00

The OGL pipeline on macOS still used some properties:
  - CGLGraphicsConfig#kOpenGLSwapInterval is not useful since we moved to the CALayer
  - CGLGraphicsConfig#pixfmt never used
  - Initialization of CGLGraphicsConfig does not depend on displayID after JDK-8223158[1]

Also I simplified the native initialization logic of CGLGraphicsConfig.
Previously we create an array of parameters and passed them to the selector, also we
return result via the same array, in the fix selector was replaced by the simple "block"
passed to "ThreadUtilities performOnMainThreadWaiting"

[1] https://bugs.openjdk.java.net/browse/JDK-8223158

-- 
Best regards, Sergey.

From hoffmann at mountainminds.com  Thu Jan 23 08:54:46 2020
From: hoffmann at mountainminds.com (Marc Hoffmann)
Date: Thu, 23 Jan 2020 08:54:46 -0000
Subject: [OpenJDK 2D-Dev] [15] Review Request: 8237746 Fixing compiler
 warnings in src/demo/share/jfc
In-Reply-To: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
References: <c00a6a38-7e72-d395-fca1-24ce6245ad8a@oracle.com>
Message-ID: <C234EDBB-20AA-4921-9836-0F9F1F2AF4B5@mountainminds.com>

Hi Sergey,

thanks for sponsoring this patch!

I successfully applied the webrev patch on current JDK head (57807:7bae17e00566). The build runs without warnings on the demo code :)

But I noticed a minor glitch: I inserted a tab in src/demo/share/jfc/SwingSet2/DirectionPanel.java Line 97 where only spaces are used in the rest of the file. Probably this should be fixed before merge.

Regards,
-marc 





> On 23. Jan 2020, at 01:35, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> Please review the fix for compiler warnings in the demo/jfc in JDK 15.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8237746
> Fix: http://cr.openjdk.java.net/~serb/8237746/webrev.00
> 
> This fix contributed by the Marc Hoffmann:
> https://mail.openjdk.java.net/pipermail/swing-dev/2019-October/009846.html
> 
> Fixed warnings: raw types, deprecated APIs, deprecated Applet APIs.
> 
> -- 
> Best regards, Sergey.


From vtewar26 at in.ibm.com  Fri Jan 31 10:01:08 2020
From: vtewar26 at in.ibm.com (Vyom Tewari26)
Date: Fri, 31 Jan 2020 10:01:08 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8231352
 [Citrix/RDP]PrintServiceLookup.lookupDefaultPrintService() does not return
 configured default printer when redirected
Message-ID: <OF16294A3D.CEA676EC-ON00258500.0036FB30-00258500.0037093D@notes.na.collabserv.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200131/d5ee8ee2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: webrev.zip
Type: application/zip
Size: 88355 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20200131/d5ee8ee2/webrev-0001.zip>