Re: [OpenJDK 2D-Dev] Retiring this 2d-dev list on 30th September 2021

[Philip Race]

Reminder.

-phil

On 9/15/21 11:08 AM, Philip Race wrote:

As described below

-Phil.


 Forwarded Message 
Subject: 	Retiring 2d, awt, beans, sound and swing mailing lists on 
30th September 2021

Date:   Wed, 15 Sep 2021 11:05:09 -0700
From:   Philip Race 
To: client-libs-...@openjdk.java.net



Since :
1) The old client groups mailing lists were consolidated into 
client-libs-dev at openjdk dot java dot net [1],
including subscribing all subscribers to the old invividual lists to 
the new consolidated list, and

2) The skara github tooling has also migrated to that new list and
3) Folks are already using the new list for questions etc

Then :
I think it is time to plan the retirement of all the old lists :
2d-dev [2], awt-dev [3], beans-dev [4], sound-dev [5], and swing-dev [6]

Accordingly I propose that these five old lists become archived and 
read-only as of 12pm PDT 30th September 2021
and will ask the mail server adminstrators to plan to implement this 
at that time.


I will also forward this information to each of those individual lists.

-Phil Race
Client Libs Group Lead.

[1] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
[2] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
[3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
[4] https://mail.openjdk.java.net/mailman/listinfo/beans-dev
[5] https://mail.openjdk.java.net/mailman/listinfo/sound-dev
[6] https://mail.openjdk.java.net/mailman/listinfo/swing-dev

[OpenJDK 2D-Dev] Retiring this 2d-dev list on 30th September 2021

[Philip Race]

As described below

-Phil.


 Forwarded Message 
Subject: 	Retiring 2d, awt, beans, sound and swing mailing lists on 30th 
September 2021

Date:   Wed, 15 Sep 2021 11:05:09 -0700
From:   Philip Race 
To: client-libs-...@openjdk.java.net



Since :
1) The old client groups mailing lists were consolidated into 
client-libs-dev at openjdk dot java dot net [1],
including subscribing all subscribers to the old invividual lists to the 
new consolidated list, and

2) The skara github tooling has also migrated to that new list and
3) Folks are already using the new list for questions etc

Then :
I think it is time to plan the retirement of all the old lists :
2d-dev [2], awt-dev [3], beans-dev [4], sound-dev [5], and swing-dev [6]

Accordingly I propose that these five old lists become archived and 
read-only as of 12pm PDT 30th September 2021
and will ask the mail server adminstrators to plan to implement this at 
that time.


I will also forward this information to each of those individual lists.

-Phil Race
Client Libs Group Lead.

[1] https://mail.openjdk.java.net/mailman/listinfo/client-libs-dev
[2] https://mail.openjdk.java.net/mailman/listinfo/2d-dev
[3] https://mail.openjdk.java.net/mailman/listinfo/awt-dev
[4] https://mail.openjdk.java.net/mailman/listinfo/beans-dev
[5] https://mail.openjdk.java.net/mailman/listinfo/sound-dev
[6] https://mail.openjdk.java.net/mailman/listinfo/swing-dev

[OpenJDK 2D-Dev] Fwd: Project Wakefield announcement and welcome

[Philip Race]

FYI

 Forwarded Message 
Subject:Project Wakefield announcement and welcome
Date:   Wed, 1 Sep 2021 14:59:30 -0700
From:   Philip Race 
To: wakefield-...@openjdk.java.net



Hi all,

The project has been recorded in the OpenJDK census : 
https://openjdk.java.net/census#wakefield


The email list (to which I sent this)
https://mail.openjdk.java.net/mailman/listinfo/wakefield-dev
has been set up pre-populated with the initial committers.
If you are a committer who did not previously have an OpenJDK ID you 
should have received
an invitation to register. Don't ignore it - it will expire in 14 days 
from when it was sent.


We also have a web page https://openjdk.java.net/projects/wakefield/ 
<https://openjdk.java.net/projects/wakefield/> which is still just pro-forma

I'll add something more once we have it :-)

The wiki is also being set up : 
https://wiki.openjdk.java.net/display/wakefield 
<https://wiki.openjdk.java.net/display/wakefield>


Unlike the Project Page everyone who is a committer will be able to edit 
the wiki


The project repo has not yet been created but is expected to be created 
this week.

I will send a follow up on that once it is done.

I'll also inform the various client lists (forward please do NOT cross 
post !)  of the new mailing list


-phil.

[OpenJDK 2D-Dev] FYI: A CFD for a Wayland project has been posted to disc...@openjdk.java.net

[Philip Race]

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html

-phil.

Re: [OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

[Philip Race]

> I’ve only tried a couple of apps and only this test program has shown 
the problem.


Did you try to attach something ? the lists strip attachments.
Sent it directly to me and I'll see if I can add it to a bug report.

-phil.

On 5/6/21 2:50 PM, Alan Snyder wrote:



On May 6, 2021, at 1:45 PM, Philip Race  wrote:

Alan,

I am not sure this is a known issue. We'll need a lot more details.

I figured you would. :-)



What is your h+w and OS update ?

iMac 27 inch 2020 Radeon Pro 5500 XT 8 GB
11.3.1



Is this all windows in an app or just the first one ?

Definitely not just the first one, but not all of them, either.



Does it matter what the window content is ?

It might. The app is a test program that can create any of 30 different kinds 
of windows on demand.

So far, I’ve seen the problem in 11 kinds of windows but not in the others. No 
obvious pattern in the content.

The problem is most likely to happen the first time a given window is shown, 
but it can also happen on later instances of the same kind of window.
I just tried a new kind of window and it happened the first 3 times, but not 
the 4th, then about 50% of the time.
I tried creating a different window about 25 times, and it happened on #1, #4, 
and #25.


Any app or some specific app ?

I’ve only tried a couple of apps and only this test program has shown the 
problem.




-phil.


On 4/29/21 7:18 PM, Alan Snyder wrote:

I am seeing some unusual behavior (in b20) that I do not see using OpenGL (or 
using JDK 16).

Sometimes when I open a new window, the window appears blank (except for the 
title bar) for about two seconds before the content appears.

This behavior is not consistent. Opening another instance of the same window 
might be fast or slow. It happens with a variety of window classes.

In JDK16 and using OpenGL, the content always appears immediately.






On Apr 23, 2021, at 1:13 PM, Philip Race  wrote:

FYI to the wider community that may not subscribe to the client mailing lists, 
nor appreciate too much cross-posting.

-phil.


 Forwarded Message 
Subject:Heads up : JDK 17 b19 through b22 will use Metal instead of 
OpenGL for Java 2D rendering on macOS.
Date:   Fri, 23 Apr 2021 13:10:46 -0700
From:   Philip Race 
To: 2d-dev@openjdk.java.net <2d-dev@openjdk.java.net>
CC: lanai-...@openjdk.java.net, swing-...@openjdk.java.net 
, awt-...@openjdk.java.net 





Heads up to anyone who is testing JDK 17 for running apps on macOS.
Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched from 
using OpenGL
to using Apple's Metal API for Java 2D rendering. This should be invisible to 
applications.
We expect to revert this temporary switch in JDK 17 build 23,meaning b22 will 
be the last build with Metal as default.

See JEP 382 [2] for more information about how Metal is used by JDK.

If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see 
any rendering related problems
starting with JDK 17 b19, please do report them to us at either the usual bug 
submission channel [3],
or on the 2d-dev@openjdk.java.net OpenJDK mailing list [4]
Please be ready to provide us with a test case and screen shots.

You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which  
implicitly disables Metal -
to confirm that any problem you see is a Metal related rendering glitch.

I will also forward this email to jdk-...@openjdk.java.net

-Phil.

[1] https://jdk.java.net/17/
[2] https://openjdk.java.net/jeps/382 <https://openjdk.java.net/jeps/382>
[3] https://bugreport.java.com/bugreport/
[4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev

Re: [OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

[Philip Race]

Alan,

I am not sure this is a known issue. We'll need a lot more details.

What is your h+w and OS update ?
Is this all windows in an app or just the first one ?
Does it matter what the window content is ?
Any app or some specific app ?

-phil.


On 4/29/21 7:18 PM, Alan Snyder wrote:

I am seeing some unusual behavior (in b20) that I do not see using OpenGL (or 
using JDK 16).

Sometimes when I open a new window, the window appears blank (except for the 
title bar) for about two seconds before the content appears.

This behavior is not consistent. Opening another instance of the same window 
might be fast or slow. It happens with a variety of window classes.

In JDK16 and using OpenGL, the content always appears immediately.






On Apr 23, 2021, at 1:13 PM, Philip Race  wrote:

FYI to the wider community that may not subscribe to the client mailing lists, 
nor appreciate too much cross-posting.

-phil.


 Forwarded Message 
Subject:Heads up : JDK 17 b19 through b22 will use Metal instead of 
OpenGL for Java 2D rendering on macOS.
Date:   Fri, 23 Apr 2021 13:10:46 -0700
From:   Philip Race 
To: 2d-dev@openjdk.java.net <2d-dev@openjdk.java.net>
CC: lanai-...@openjdk.java.net, swing-...@openjdk.java.net 
, awt-...@openjdk.java.net 





Heads up to anyone who is testing JDK 17 for running apps on macOS.
Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched from 
using OpenGL
to using Apple's Metal API for Java 2D rendering. This should be invisible to 
applications.
We expect to revert this temporary switch in JDK 17 build 23,meaning b22 will 
be the last build with Metal as default.

See JEP 382 [2] for more information about how Metal is used by JDK.

If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see 
any rendering related problems
starting with JDK 17 b19, please do report them to us at either the usual bug 
submission channel [3],
or on the 2d-dev@openjdk.java.net OpenJDK mailing list [4]
Please be ready to provide us with a test case and screen shots.

You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which  
implicitly disables Metal -
to confirm that any problem you see is a Metal related rendering glitch.

I will also forward this email to jdk-...@openjdk.java.net

-Phil.

[1] https://jdk.java.net/17/
[2] https://openjdk.java.net/jeps/382 <https://openjdk.java.net/jeps/382>
[3] https://bugreport.java.com/bugreport/
[4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev

Re: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0

[Philip Race]

I built with gcc 10.3 https://bugs.openjdk.java.net/browse/JDK-8265373

I expect we can accommodate disabling one more warning to support more 
compilers.


-phil.

On 5/4/21 12:31 PM, Florian Weimer wrote:

* Phil Race:


Upgrade to harfbuzz 2.8

I believe this causes a build failure with GCC 8.3 (from Debian
buster):

* For target 
support_native_java.desktop_libfontmanager_hb-ot-shape-complex-use.o:
In file included from 
…/jdk/src/java.desktop/share/native/libharfbuzz/hb-ot-shape-complex-use.cc:33:
hb-ot-shape-complex-use-machine.rl: In instantiation of 'machine_index_t::machine_index_t(const machine_index_t&) [with Iter = 
hb_zip_iter_t, hb_filter_iter_t, 
hb_array_t >, find_syllables_use(hb_buffer_t*)::, const&, 0>, 
find_syllables_use(hb_buffer_t*)::)>, const&, 0> >]':
hb-ot-shape-complex-use-machine.rl:249:11:   required from here
hb-ot-shape-complex-use-machine.rl:194:9: error: base class 'struct hb_iter_with_fallback_t, 
hb_filter_iter_t, hb_array_t >, 
find_syllables_use(hb_buffer_t*)::, const&, 0>, find_syllables_use(hb_buffer_t*)::)>, const&, 0> > >, hb_pair_t > >' should be 
explicitly initialized in the copy constructor [-Werror=extra]
cc1plus: all warnings being treated as errors

[OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

[Philip Race]

Heads up to anyone who is testing JDK 17 for running apps on macOS.
Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched 
from using OpenGL
to using Apple's Metal API for Java 2D rendering. This should be 
invisible to applications.
We expect to revert this temporary switch in JDK 17 build 23,meaning b22 
will be the last build with Metal as default.


See JEP 382 [2] for more information about how Metal is used by JDK.

If you are running any kind of 2D / Swing/ AWT UI application on macOS, 
and see any rendering related problems
starting with JDK 17 b19, please do report them to us at either the 
usual bug submission channel [3],

or on the 2d-dev@openjdk.java.net OpenJDK mailing list [4]
Please be ready to provide us with a test case and screen shots.

You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which  
implicitly disables Metal -

to confirm that any problem you see is a Metal related rendering glitch.

I will also forward this email to jdk-...@openjdk.java.net

-Phil.

[1] https://jdk.java.net/17/
[2] https://openjdk.java.net/jeps/382 
[3] https://bugreport.java.com/bugreport/
[4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev

Re: [OpenJDK 2D-Dev] Image parsing spams stack traces to System.err

[Philip Race]

The real answer was a bug report at bugreport.java.com

But never mind - I've submitted 
https://bugs.openjdk.java.net/browse/JDK-8265603


FWIW I think the prints were there because the developer who added them
didn't expect them to be hit unless something went seriously wrong and 
wanted

it to be clear to whoever hit it. This case shows it is not so clear cut.

-phil.



On 4/20/21 1:38 PM, Brian Burkhalter wrote:

I think this post needs to go to 2d-dev (copied).


On Apr 20, 2021, at 9:58 AM, Lapo Luchini  wrote:

In both OpenJDK 8, 11 and 15 I verified that:

sun/awt/image/InputStreamImageSource.java

has "e.printStackTrace()" commands that might better be converted to 
java.util.logging in order to be able to configure/redirect them to the proper log file 
each application might decide to use.

A little bit of more details as reported here (where they suggested this was 
the proper place):
https://github.com/AdoptOpenJDK/openjdk-jdk11u/issues/21

cheers,

--
Lapo Luchini
l...@lapo.it

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

[Philip Race]

On 3/30/21 11:31 PM, mc36 wrote:


please find below, but, again, it's jre17~15, where everything seems fine.


Oh that's what you mean by the incomprehensible
" please dont! i got ~15 and the issue is gone!"

So it was some one-off problem with the build 14 from your distro.

I think this points to how important it is to first complain there and 
not here.


-phil.

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

[Philip Race]

PS also I'd be interested to know the output of
ldd /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so

It should resolve libharfbuzz.so in some system directory

I've double-checked the test build I did on Ubuntu 20.10 for JDK 17 b14 
and it works fine

finding libharfbuzz there.

So my current best guess is it is related to how your distro built it ..


-phil.



On 3/29/21 10:33 PM, Philip Race wrote:



On 3/29/21 8:14 PM, mc36 wrote:

hi,
please dont! i got ~15 and the issue is gone!


please don't do what ?


(but answering line by line, who knows)
thanks,
cs


Ok. So it looks like you are using some debian build of openjdk and it 
seems likely

it can't find the system libharfbuzz.so since that symbol is very basic.

If you use the one from https://jdk.java.net/17/ I expect it will work 
since it does

what the JDK 15 does that I suggested.

I can't tell what the JDK 16 you have does since I'd need to see an ls 
-l of your

/lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so

-phil.




On 3/29/21 6:41 PM, Philip Race wrote:

Moving this to the right list.

There's lots of missing information in your email.

1) I don't know what a debian sid is. Internet suggests it is some 
upstream dev version

Is this reproducible on any shipping distro ?

yesss, it is. https://www.debian.org/
the only difference that you replace stable to 
unstable/sid/experimental,depending how brave you're :)




2) Where exactly did you get the openjdk build 17 ? Was it from 
https://jdk.java.net/17/ or somewhere else ?

Please show the output of "java -version" to help confirm it.


sudo apt install openjdk-17-jre -- to get the latest build of them
at the moment i see the following version:

mc36@noti:~$ java -version
openjdk version "17-ea" 2021-09-14
OpenJDK Runtime Environment (build 17-ea+15-Debian-1)
OpenJDK 64-Bit Server VM (build 17-ea+15-Debian-1, mixed mode, sharing)
mc36@noti:~$



3) What does  "ls -l lib/libfontmanager.so" show ?


mc36@noti:~$ find /lib/ -name libfontmanager.so
/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libfontmanager.so
/lib/jvm/java-15-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-13-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-11-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-14-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
mc36@noti:~$ ls -lsa /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
56 -rw-r--r-- 1 root root 55960 Mar 25 10:31 
/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so

mc36@noti:~$


4) What was the JDK version you had immediately before this and 
where did you get that ?
i have all that is available in the distro, but it depends, my older 
installations have something from java6 times :)



5) Does either JDK 11u or JDK15u work in this respect on that system ?


yesss, right now, every installed jvm works perfectly, i olny saw the 
issue with 17~14
then, for a while i sudo update-alternatives --config java 'ed to 16, 
but when they bumped
to ~15, the i reverted to auto, that is 17, and the issue is 
completely gone, now all the

jvms i have works fine!

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

[Philip Race]

On 3/29/21 8:14 PM, mc36 wrote:

hi,
please dont! i got ~15 and the issue is gone!


please don't do what ?


(but answering line by line, who knows)
thanks,
cs


Ok. So it looks like you are using some debian build of openjdk and it 
seems likely

it can't find the system libharfbuzz.so since that symbol is very basic.

If you use the one from https://jdk.java.net/17/ I expect it will work 
since it does

what the JDK 15 does that I suggested.

I can't tell what the JDK 16 you have does since I'd need to see an ls 
-l of your

/lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so

-phil.




On 3/29/21 6:41 PM, Philip Race wrote:

Moving this to the right list.

There's lots of missing information in your email.

1) I don't know what a debian sid is. Internet suggests it is some 
upstream dev version

Is this reproducible on any shipping distro ?

yesss, it is. https://www.debian.org/
the only difference that you replace stable to 
unstable/sid/experimental,depending how brave you're :)




2) Where exactly did you get the openjdk build 17 ? Was it from 
https://jdk.java.net/17/ or somewhere else ?

Please show the output of "java -version" to help confirm it.


sudo apt install openjdk-17-jre -- to get the latest build of them
at the moment i see the following version:

mc36@noti:~$ java -version
openjdk version "17-ea" 2021-09-14
OpenJDK Runtime Environment (build 17-ea+15-Debian-1)
OpenJDK 64-Bit Server VM (build 17-ea+15-Debian-1, mixed mode, sharing)
mc36@noti:~$



3) What does  "ls -l lib/libfontmanager.so" show ?


mc36@noti:~$ find /lib/ -name libfontmanager.so
/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/libfontmanager.so
/lib/jvm/java-15-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-16-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-13-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-11-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-14-openjdk-amd64/lib/libfontmanager.so
/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
mc36@noti:~$ ls -lsa /lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so
56 -rw-r--r-- 1 root root 55960 Mar 25 10:31 
/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so

mc36@noti:~$


4) What was the JDK version you had immediately before this and where 
did you get that ?
i have all that is available in the distro, but it depends, my older 
installations have something from java6 times :)



5) Does either JDK 11u or JDK15u work in this respect on that system ?


yesss, right now, every installed jvm works perfectly, i olny saw the 
issue with 17~14
then, for a while i sudo update-alternatives --config java 'ed to 16, 
but when they bumped
to ~15, the i reverted to auto, that is 17, and the issue is 
completely gone, now all the

jvms i have works fine!

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

[Philip Race]

Moving this to the right list.

There's lots of missing information in your email.

1) I don't know what a debian sid is. Internet suggests it is some 
upstream dev version

Is this reproducible on any shipping distro ?

2) Where exactly did you get the openjdk build 17 ? Was it from 
https://jdk.java.net/17/ or somewhere else ?

Please show the output of "java -version" to help confirm it.

3) What does  "ls -l lib/libfontmanager.so" show ?

4) What was the JDK version you had immediately before this and where 
did you get that ?


5) Does either JDK 11u or JDK15u work in this respect on that system ?

-phil

On 3/19/21 6:03 AM, mc36 wrote:

hi,
just upgraded from openjdk17~11 to openjdk17~14 
(https://packages.debian.org/sid/main/openjdk-17-jdk) on my debian 
sid. i quickly noticed that something is wrong so i ended up with the 
below sample app.
i'm not a big c coder so all i was able to do is that i got the 
libharfbuzz sources 
(https://packages.debian.org/unstable/libharfbuzz-dev) and checked 
that i have that version and the function is there.

i would appreciate some idea what else should i try?
thanks,
csaba


mc36@noti:~$ cat a.java

import java.awt.Graphics2D;
import java.awt.image.BufferedImage;

public class a {

    public static void main(String[] args) throws Exception {
    BufferedImage img = new BufferedImage(100, 100, 
BufferedImage.TYPE_INT_RGB);

    Graphics2D g2d = img.createGraphics();
    }

}


mc36@noti:~$ javac a.java
mc36@noti:~$ java a
Exception in thread "main" java.lang.UnsatisfiedLinkError: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: 
/usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: undefined 
symbol: hb_font_destroy
    at java.base/jdk.internal.loader.NativeLibraries.load(Native 
Method)
    at 
java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:383)
    at 
java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:227)
    at 
java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:169)
    at 
java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:310)
    at 
java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:280)
    at 
java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2392)

    at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:808)
    at java.base/java.lang.System.loadLibrary(System.java:1893)
    at 
java.desktop/sun.font.FontManagerNativeLibrary$1.run(FontManagerNativeLibrary.java:57)
    at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
    at 
java.desktop/sun.font.FontManagerNativeLibrary.(FontManagerNativeLibrary.java:32)
    at 
java.desktop/sun.java2d.xr.XRSurfaceData.initXRSurfaceData(XRSurfaceData.java:104)
    at 
java.desktop/sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:122)
    at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
    at 
java.desktop/sun.awt.X11GraphicsEnvironment.(X11GraphicsEnvironment.java:59)
    at 
java.desktop/sun.awt.PlatformGraphicsInfo.createGE(PlatformGraphicsInfo.java:36)
    at 
java.desktop/java.awt.GraphicsEnvironment$LocalGE.createGE(GraphicsEnvironment.java:93)
    at 
java.desktop/java.awt.GraphicsEnvironment$LocalGE.(GraphicsEnvironment.java:84)
    at 
java.desktop/java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:106)
    at 
java.desktop/java.awt.image.BufferedImage.createGraphics(BufferedImage.java:1181)

    at a.main(a.java:9)
mc36@noti:~$

Re: [OpenJDK 2D-Dev] Clarification regarding PageFormat and Paper getImageable* functions orientation consideration

[Philip Race]

There's no bug here from what I am being shown.

>"PageFormat showing wrong printer margins in LANDSCAPE orientation” .

Really ? But I don't see anywhere the PageFormat is queried for this.
Instead the test case digs inside the PageFormat and retrieves the Paper 
and asks for *its* margins


I see a comment in the bug :
> All getImageable methodes javadoc say "This method takes into account 
the orientation of the page" but It's not true before printing.


The methods that say that, are the ones on PageFormat, not the ones on 
Paper. So wrong.



-phil

On 3/22/21 1:55 PM, Rajat Mahajan wrote:


Hi all,

*_Issue:_*

*__*

I am working on https://bugs.openjdk.java.net/browse/JDK-8203395 
  and this bug is 
about *“PageFormat showing wrong printer margins in LANDSCAPE 
orientation” .*


**

*Application code it trying to print in Landscape and Portrait but 
both show same margins:*


Margins default : 12,12,17,17

Margins OrientationRequested.LANDSCAPE : 12,12,17,17

**

*The code of the application uses Paper object for getting margins :*

PageFormat pf = printerJob.getPageFormat(aset);

   Paper paper = pf.getPaper();

   long paperTopMargin = Math.round(paper.getImageableY());
   long paperLeftMargin = Math.round(paper.getImageableX());
   long paperRightMargin = Math.round(paper.getWidth() - 
paper.getImageableWidth() - paperLeftMargin);
   long paperBottomMargin = Math.round(paper.getHeight() - 
paper.getImageableHeight() - paperTopMargin);


When I looked at the latest JDK code, PageFormat getImageable 
functions are taking into account Orientation and Paper getImageable 
functions are not , and hence we see the same output.


Using Page format object instead of Paper shows the correct output:

Margins default : 12,12,17,17

Margins OrientationRequested.LANDSCAPE : 17,17,12,12

*_Question:_*

My question is that should Paper getImageable* functions also need 
take into account orientation as per spec ?, or is the current 
behavior of them not considering orientation correct and why ?

[OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering pipeline for macOS) EA build 10 has been released

[Philip Race]

All,

We have prepared an EA 10 build of Project Lanai for JEP 382 [1] 
incorporating fixes to feed back during the ongoing code review [2]

EA 10 can be downloaded from https://jdk.java.net/lanai/.

Note the open issues and testing suggestions given there.

Please test with your apps and hardware and provide feedback via the 
lanai-...@openjdk.java.net mailing list.


-Phil

[1] https://openjdk.java.net/jeps/382
[2] https://mail.openjdk.java.net/pipermail/2d-dev/2021-February/011902.html

Re: [OpenJDK 2D-Dev] Thread safety of SunFontManager.platformFontMap

[Philip Race]

The map is not expected to be updated after it has been created so it 
should not need synchronized access.
There are a couple of exceptions where it is being updated when some 
file that
is supposed to be there can't be found - a scenario that apparently 
hasn't been

an issue in the 10 years this code has been in use.
So the removal is an optimisation that could be revisited.

-phil.

On 2/22/21 4:40 AM, Andrey Turbanov wrote:


Hello.
I recently found suspicious field (with SpotBugs help) in class 
SunFontManager:


    static HashMap platformFontMap;

This HashMap is accessed (read and write) in a method
sun.font.SunFontManager#findFontFromPlatformMap. As I see there is no
synchronization when this HashMap is accessed.
This method can be called from client code with this simple stack trace:

      at 
sun.font.SunFontManager.findFontFromPlatformMap(SunFontManager.java:1508)

      at sun.font.SunFontManager.findFont2D(SunFontManager.java:2069)
      at java.awt.Font.getFont2D(Font.java:500)
      at java.awt.Font.getPSName(Font.java:1416)

I wonder if this unsynchronized access is expected. Looks like it can
break things when accessed from multiple threads simultaneously.
Do I miss something? Is it done this way, because Font objects are
supposed to be accessed from a single thread only?

Andrey Turbanov

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

[Philip Race]

I have worked out how to pass this option to at least the jtreg tests 
for the lanai headful mach5 job,
so once this is fixed we can check it out in jtreg and get some level of 
confidence  that we are

checking all the important cases.
Note that we know some tests will fail just because it spits out a 
message that they will mis-parse but it is still worth doing.


Need to figure out the same for JCK ..

-phil.

On 2/11/21 3:12 PM, Phil Race wrote:

On Thu, 11 Feb 2021 21:04:16 GMT, Gerard Ziemski  wrote:


I guess you will only see this if `Metal API Validation Enabled`

Which actually begs a question of whether we tested with `Metal API Validation 
Enabled` ?

I submitted https://bugs.openjdk.java.net/browse/JDK-8261620 for this bug.
Could be that there are more such issues but since this crash occurs on start 
up I can't say what else there might be.

-

PR: https://git.openjdk.java.net/jdk/pull/2403

[OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering pipeline for macOS) FINAL planned EA build has been released

[Philip Race]

All,

The Lanai project has reached the stage where we are aiming to move the 
JEP [1]

to Proposed-To-Target [2] to JDK 17 very soon.

We have made one final planned EA release which includes all the latest 
fixes.


So please visit https://jdk.java.net/lanai/ and download the EA 9 build 
and test with your apps and hardware. and provide feedback via the 
lanai-...@openjdk.java.net mailing list.


-phil.

[1] https://openjdk.java.net/jeps/382

[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

[OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering pipeline for macOS) FINAL planned EA build has been released

[Philip Race]

All,

The Lanai project has reached the stage where we are aiming to move the 
JEP [1]

to Proposed-To-Target [2] to JDK 17 very soon.

We have made one final planned EA release which includes all the latest 
fixes.


So please visit https://jdk.java.net/lanai/ and download the EA 9 build 
and test with your apps and hardware. and provide feedback via the 
lanai-...@openjdk.java.net mailing list.


-phil.

[1] https://openjdk.java.net/jeps/382

[2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html

Re: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU

[Philip Race]

From the CSR ;

>This change also improves the startup performance, on my current new
> laptop mbp 16 + BigSur 11.1 the switching discrete/integrated causes 
unexpected delays up to 10 seconds.


This also has to be a bug. I thought it had gone away. Have we reported 
that to Apple ?

If not we should do so ASAP.

-phil.

On 12/23/20 5:04 PM, Sergey Bylokhov wrote:

On Wed, 9 Dec 2020 17:40:34 GMT, Victor Dyakov  wrote:


@kevinrushforth @prrace could you please review?

As we discussed yesterday, it is reviewed but not ready to be approved.
We are waiting for a reply from Apple.

@prrace
We are waiting for it for three months already. If it is possible then not sure 
why other applications did not found any possible ways to force one specific 
GPU. What we are wating for?

@mrserb @prrace  what is a back up plan in case we will not have a reply from 
Apple? (as we do not have it for 4! months). Definitely we need a plan B

CSR is filed: https://bugs.openjdk.java.net/browse/JDK-8258918

-

PR: https://git.openjdk.java.net/jdk/pull/1139

[OpenJDK 2D-Dev] EA8 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

[Philip Race]

The EA 8 build of Project Lanai [1] was posted today at 
https://jdk.java.net/lanai/


EA 8 Build 17-lanai+1-2 (2020/12/12)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of 
issues.


One particular request :
To anyone who has a mac still running 10.12 - we don't expect Metal to 
run (it requires at least 10.13
and maybe even later by the time it is final) but we would like 
confirmation that nothing in Metal

prevents OpenGL running on older releases.
Note there is currently a hotspot build bug unrelated to Lanai that 
prevents running on 10.10

and maybe 10.11 but 10.12 will be a useful data point.

EA 8 contains the following new bug fixes relative to EA 7

8257886: Build issue in macOS 10.14
8256683: Lanai: NetBeans IDE - AA Text rendering appears brighter 
compared to OpenGL

8242925: J2DDemo - Anti-Aliasing with Metal differs from OGL
8257618: Lanai: GradientPaint interpolates over stops limits
8257566: Lanai: System runs out of application memory while running the 
Unmanaged_BufferredImage_draw_NearestNeighbor test multiple times

8257441: Lanai: java/awt/image/VolatileImage/DrawHugeImageTest fails
8257442: Lanai: Create RenderPerf tests for SW to HW blits
8257413: Lanai - Use optimum sized temporary buffer while replacing 
texture region

8238285: Lanai: java/awt/image/DrawImage tests fail
8256576: DrawImage/BlitRotateClippedArea fails

-phil.

[OpenJDK 2D-Dev] EA7 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

[Philip Race]

The EA 7 build of Project Lanai [1] was posted today at 
https://jdk.java.net/lanai/



   EA 7 Build 16-lanai+3-278 (2020/11/17)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.

EA 7 contains the following new bug fixes relative to EA 6

# 8256331: Lanai: DrawImage/IncorrectAlphaSurface2SW fails 

# 8252954: Lanai : 
java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java fails 

# 8252951: Lanai : java/awt/Robot/NonEmptyErrorStream.java fails 

# 8251033: Background texture is not visible when Alpha Composite is 
enabled 
# 8238533: [Lanai] Support texture paint where source is transparent 

# 8248129: Swingmark numbers are not good for Nimbus LAF 

# 8255212: J2DDemo : Rectangle in Texture paint disappears if we enable AA 

# 8255149: Lanai: DrawImage/IncorrectAlphaConversionBicubic.java failure 

# 8244718: J2DDemo - AlphaComposite tab - output colors are different with 
AA & non-AA 
# 8254881: Commit commandbuffer after draw happens through JNI 

# 8254879: Implement JNI path for Draw Poly 

# 8254869: Refactor check_previous_op usage in Mask Fill 

# 8244845: Lanai : J2DDemo - Clipping - Two parallel lines do not appear 
with AA Rendering 
# 8242924: Selection is not correct in Paint.TextureAnim 

# 8253994: J2DDemo: Buttcap, SquareCap color is different in 
AlphaComposite mode 
# 8252726: Lanai: IDEA Editor Rendering OGL vs Metal 1:2 

# 8254176: Lanai: MTLTexturePool optimize lookup of expired textures 



-phil.

[1] https://wiki.openjdk.java.net/display/lanai/Main

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

[Philip Race]

So maybe the actual *usage* of C++11 features slows it down.

I found this :-
https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98

I really did not even think to measure the build time and I don't
think there's any JDK build parallelism in building a specific native 
library.

The build is parallel at a higher level but not at that lower level.

-phil

On 11/17/20, 10:00 AM, Florian Weimer wrote:

* Philip Race:


There is more code in the newer version but not 4 times as much !
Harfbuzz now requires c++11 features (-std=c++11)
Possibly the C++ compiler you are using (you don't mention platform) is
slower in this mode.

It's GCC 8 on Debian buster, which defaults to C++14.  And it's
possible to write slow-to-compile C++ in all language modes.

Is the Harfbuzz build parallelized?

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

[Philip Race]

There is more code in the newer version but not 4 times as much !
Harfbuzz now requires c++11 features (-std=c++11)
Possibly the C++ compiler you are using (you don't mention platform) is 
slower in this mode.


-phil.

On 11/17/20, 9:01 AM, Florian Weimer wrote:

* Phil Race:


This upgrades JDK to import the current 2.7.2 version of harfbuzz -
an OpenType text shaping library

https://bugs.openjdk.java.net/browse/JDK-8247872

This has passed building and headless and headful automated tests on
all platforms.

Is it just me, or does the new Harfbuzz build *significantly* slower?

It adds about 20 seconds to the build, compared to using the system
Harfbuzz, whereas before it was around 5 seconds.

[OpenJDK 2D-Dev] EA6 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

[Philip Race]

I am a bit slow in sending out the announcement, but
https://jdk.java.net/lanai/ is now hosting the EA 6 build of Lanai


   EA 6 Build 16-lanai+2-229 (2020/10/4)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.

EA 6 contains the following new bug fixes relative to EA 5

 * 8253931: Lanai: MTLTexturePool refactoring
   
 * 8253840: Lanai - MTLClip.beginShapeClip method uses a larger
   temporary buffer than needed
   
 * 8252790: Lanai: Refactor RenderPerfTest to run single test by name
   
 * 8253657: Lanai: Refactor MTLTexturePool - getTexture
   
 * 8251475: sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java fails with
   metal pipeline 
 * 8246194: Performance of Mix.Balls decreases when Rendering Quality
   option is Selected 
 * 8252796: Lanai: Shape clip test artifacts on MacBook Air 2020
   
 * 8252499: UI text of application with metal pipeline is lost when
   another application is launched with OpenGL pipeline
   
 * 8253301: Lanai: Memory leak in MTLContext code
   
 * 8253260: Fix whitespace errors in .m and .metal files in lanai repo
   
 * 8252795: Lanai: Refactor native implementation of MTLPaint
   
 * 8251023: Clipping of Image doesnt work when Alpha composite is
   enabled in J2DDemo 
 * 8252880: Image operations are not working with metal
   
 * 8252895: Black background in SwingSet2 in Nimbus LAF
   
 * 8252949: Shape clip should use identity transform for drawing clip
   spans 


-phil.

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

[Philip Race]

I guess the status is every one has been busy with transitioning to 
github [1]

This should be re-sent as a github PR to be considered further.
However I think that one way or another *you* need to provide the test.
Saying a customer tested it or vaguely hoping the community will help 
you out is just going

to delay this.

-phil.

[1] 
https://mail.openjdk.java.net/pipermail/jdk-dev/2020-September/004691.html


On 9/21/20, 10:40 PM, Vipin Mv1 wrote:

Hi,

May I ask for a status on this please.  


-Vipin Mv1/India/IBM wrote: -
To: Philip Race
From: Vipin Mv1/India/IBM
Date: 08/31/2020 05:52PM
Cc: 2d-dev@openjdk.java.net
Subject: Re: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing 
ignores printer tray

Hi Philip,

Thanks for the review comments. The testcase 
test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java seems to be 
intended to test only the MediaTray functionality. Also, it doesn't seems to 
have anything that is Linux specific.

Rather than having a new testcase wouldn't it be fine to have os.family == 
"mac" change alone to the existing one.?

Regarding the testing, the patch was already tested by our customer using a 
multi tray printer and was found to be working. Owing to WFH factor due to 
COVID19, multi tray printer is not accessible to us at this point of time.

May I request if the community can help us do further testing with the multi 
tray printer.

Thanks&  Regards
Vipin MV

-----Philip Race  wrote: -
To: Vipin Mv1
From: Philip Race
Date: 08/30/2020 10:02PM
Cc: 2d-dev@openjdk.java.net
Subject: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores 
printer tray

PS there is an existing manual regression test but it is currently
geared towards Linux and in fact is set to run only on Linux
test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java
So you still may find it easier to create a new test rather than modify
this one to avoid breaking what it tests.

-phil


On 8/29/20, 11:10 AM, Philip Race wrote:

PS, there's a test case in the bug. Seems like it could be used as the
basis for a manual regression test.

Make sure you use @requires printer  as well as adding the manual and
headful keywords
and next you'll have to check for an installed printer with multiple
trays

-phil

On 8/27/20, 11:36 AM, Philip Race wrote:

This looks reasonable but we need to test it first before approving it.

-phil.

On 8/27/20, 6:16 AM, Vipin Mv1 wrote:

Hi,

Please find below a patch for the following issue.

https://bugs.openjdk.java.net/browse/JDK-8234393


http://cr.openjdk.java.net/~aleonard/8234393/webrev.00

Thanks&   Regards
Vipin MV

[OpenJDK 2D-Dev] EA5 build of Project Lanai (Metal rendering pipeline for macOS) is now posted

[Philip Race]

After some technical hiccups which delayed it, 
https://jdk.java.net/lanai/ is now hosting the EA 5 build of Lanai



   EA 5 Build 16-lanai+1-129 (2020/9/7)


Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.


EA 5 contains the following new bug fixes relative to EA 4

# 8252845: Regressions in Sanity tests after JDK-8251032 

# 8252798: Cleanup LCD text rendering code 

# 8252386: Lanai: Implement RadialGradientPaint in shader 

# 8252706: Enable usage of rowBytesOffset for LCD non cache rendering 

# 8251032: Colors with texture background look different with Alpha Com... 

# 8252385: Lanai: Implement LinearGradient paint in shader 

# 8243547: Lanai - Netbeans IDE has BLACK background for the Toolbar and 
Statusbar 
# 8240164: Test 
java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java 
fails for metal 
# 8240074: Test 
java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java fails 
for metal 
# 8251027: DrawString with TexturePaint is corrupted 

# 8242920: Gradient Paint doesn't work with metal 

# 8252371: LCD text rendered with Metal pipeline is corrupted 

# 8252217: Crash in metal pipeline which running J2DBench test 

# 8252057: Crash in metal pipeline when dragging any Swing app to other... 

# 8251484: Performace drop in FlatBoxAA renderperf test for metal pipeline 

# 8251242: Tile based rendering results in artifacts in last column while 
using metal pipeline 
# 8249659: [Lanai] Crash while running RenderPerfTest with metal pipeli... 

# 8251167: Drawing polyline twice in XOR mode leaves out some traces on 
screen (only with uiScale=1.0) 




-phil.

Re: [OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

[Philip Race]

As per the notifiication last week, as of NOW there should be NO MORE 
pushes to the hg://openjdk.java.net/jdk/client forest.


---
So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to 
jdk/client should be

>> 9am PDT Tuesday 1st Sept 2020 <<
---

-phil.

On 8/28/20, 10:53 AM, Philip Race wrote:

All,

Contingent on Project Skara (ie mercurial ->git / githib) going active 
for the JDK project on schedule
on 5th September, we intend to retire the jdk/client repo/forest as 
part of this transition.


In other words, once mercurial is shut down and we move to git there 
will ONLY be the main JDK repo

and all client pushes will go there.

We will be making some internal testing changes which we hope will 
help us spot any breakages
that pushes cause in time to prevent them making their way directly 
into a promoted build but they
can't completely replace the manual testing we have been doing, so we 
will also be
dependent on folks to be extra diligent from now on and not assume 
there is a gatekeeper

who will spot their mistakes.

But we do need some time to "flush" any last changes in client to jdk 
before mercurial shuts down.


So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to 
jdk/client should be

>> 9am PDT Tuesday 1st Sept 2020 <<

Anything pushed after that time may be lost forever :-)

We'll also  further enforce this as of 9am PDT Wednesday 2nd Sept 2020 
by making the client repo
mercurial repo read-only. The 24 hours is to help the integrator/gate 
keeper - not for your late pushes,
For example if there's a breakage we need to back out before 
integrating we might need this.

So not even "doc" or "test" changes - nothing please !

You may reasonably ask why then Tue/Wed for this if skara is not 
transitioning until Sat 5th September ?
The answer is that in an unfortunate coincidence of timing we have a 
big lab move that begins around
9am PT Wed 2nd September, and all our testing capabilities will be 
off-line for several days.

So any test jobs submitted after sometime Tuesday won't have time
to complete, and the lab move won't be complete until after the skara 
transition.


Any outstanding reviews that don't make the cut-off will of course 
have to be resubmitted as github pull requests
and any approvals they may have accumulated will need to be 
re-approved. All of this is of course true for
folks pushing directly to the mercurial main JDK repo - it is not 
related to the client repo retirement.


-Phil

Re: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs'

[Philip Race]

Right we have started to be consistent using "Constructor for subclasses 
to call":


Also I prefer constructs over creates, even for the concrete classes, eg 
this :

+
+/**
+ * Creates an {@code ImageFilter}.
+ */
+public ImageFilter() {}
+

should be "Constructs an {@code ImageFilter}"

-phil.

On 8/28/20, 5:29 PM, Sergey Bylokhov wrote:

Hi, Conor.

Please use such spec for the protected constructor: "Constructor for 
subclasses to call":
https://cr.openjdk.java.net/~psadhukhan/8250850/webrev.1/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java.sdiff.html 



Actually the current text is also fine to me, but looks like many 
people use the text above as a description.


On 28.08.2020 01:28, Conor Cleary wrote:

Hello all,

Could someone please review my changes for JDK-8250855, 'Address 
reliance on default constructors in the Java 2D APIs'? This issue 
relates to JDK-8250639 '☂ Address reliance on default constructors in 
the java.desktop module'. The changes address the reliance on default 
constructors by adding in basic constructors in the following classes:


  * java.awt.Image
  * java.awt.PrintJob
  * java.awt.font.GlyphVector
  * java.awt.font.LayoutPath
  * java.awt.font.LineMetrics
  * java.awt.image.AbstractMultiResolutionImage
  * java.awt.image.BufferStrategy
  * java.awt.image.ImageFilter
  * java.awt.image.RGBImageFilter
  * java.awt.image.VolatileImage
  * javax.print.PrintServiceLookup
  * javax.print.ServiceUI
  * javax.print.ServiceUIFactory
  * javax.print.StreamPrintServiceFactory
  * javax.print.event.PrintJobAdapter

A key issue is the accompanying description for each of the added 
constructors and is probably the feedback I would value most as it 
has been a point of discussion previously. I have included a specdiff 
to easily view the changes observed in the api documentation. 
Currently drafting a CSR for these changes.


  * webrev: 
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/
  * specdiff: 
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html

  * bug: https://bugs.openjdk.java.net/browse/JDK-8250855

Best Regards,

-Conor

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

[Philip Race]

PS there is an existing manual regression test but it is currently 
geared towards Linux and in fact is set to run only on Linux

test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java
So you still may find it easier to create a new test rather than modify 
this one to avoid breaking what it tests.


-phil


On 8/29/20, 11:10 AM, Philip Race wrote:
PS, there's a test case in the bug. Seems like it could be used as the 
basis for a manual regression test.


Make sure you use @requires printer  as well as adding the manual and 
headful keywords
and next you'll have to check for an installed printer with multiple 
trays


-phil

On 8/27/20, 11:36 AM, Philip Race wrote:

This looks reasonable but we need to test it first before approving it.

-phil.

On 8/27/20, 6:16 AM, Vipin Mv1 wrote:

Hi,

Please find below a patch for the following issue.

https://bugs.openjdk.java.net/browse/JDK-8234393


http://cr.openjdk.java.net/~aleonard/8234393/webrev.00

Thanks&  Regards
Vipin MV

Re: [OpenJDK 2D-Dev] RFR: 8252070 Some platform-specific BLIT optimizations are not effective

[Philip Race]

I note that you change the signature of blitSurfaceData to private.
I think this is fine. Since it is only used in this class I imagine 
whatever reason

it was supposed it might need to be over-ridden has never arisen ..

But I still had to first go check that it isn't actually used elsewhere !

I'm not sure I get the comment about the intersection operation causing 
performance problems.
Are you referring to the cost of that intersection operation itself, or 
some downstream consequence ?


-phil

On 8/28/20, 6:26 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

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

Some of our code assumes that the native system(XRender, D3D, OGL) 
makes some

effective optimizations, but in some cases, we can do better.

One of the areas for improvements is direct blitting. If the source is 
much
bigger than the destination we should not try to copy the non-existent 
area

and could cut coordinates accordingly.

The actual change is:
 951 Rectangle dst =
 952 new Rectangle(dx, dy, w, 
h).intersection(dstData.getBounds());

 953 if (dst.isEmpty()) {
 972 // return
 975 }
 979 sx += dst.x - dx;
 980 sy += dst.y - dy;


See performance data and some additional comments:
https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864 

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

[Philip Race]

PS, there's a test case in the bug. Seems like it could be used as the 
basis for a manual regression test.


Make sure you use @requires printer  as well as adding the manual and 
headful keywords

and next you'll have to check for an installed printer with multiple trays

-phil

On 8/27/20, 11:36 AM, Philip Race wrote:

This looks reasonable but we need to test it first before approving it.

-phil.

On 8/27/20, 6:16 AM, Vipin Mv1 wrote:

Hi,

Please find below a patch for the following issue.

https://bugs.openjdk.java.net/browse/JDK-8234393


http://cr.openjdk.java.net/~aleonard/8234393/webrev.00

Thanks&  Regards
Vipin MV

[OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

[Philip Race]

All,

Contingent on Project Skara (ie mercurial ->git / githib) going active 
for the JDK project on schedule
on 5th September, we intend to retire the jdk/client repo/forest as part 
of this transition.


In other words, once mercurial is shut down and we move to git there 
will ONLY be the main JDK repo

and all client pushes will go there.

We will be making some internal testing changes which we hope will help 
us spot any breakages
that pushes cause in time to prevent them making their way directly into 
a promoted build but they
can't completely replace the manual testing we have been doing, so we 
will also be
dependent on folks to be extra diligent from now on and not assume there 
is a gatekeeper

who will spot their mistakes.

But we do need some time to "flush" any last changes in client to jdk 
before mercurial shuts down.


So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to 
jdk/client should be

>> 9am PDT Tuesday 1st Sept 2020 <<

Anything pushed after that time may be lost forever :-)

We'll also  further enforce this as of 9am PDT Wednesday 2nd Sept 2020 
by making the client repo
mercurial repo read-only. The 24 hours is to help the integrator/gate 
keeper - not for your late pushes,
For example if there's a breakage we need to back out before integrating 
we might need this.

So not even "doc" or "test" changes - nothing please !

You may reasonably ask why then Tue/Wed for this if skara is not 
transitioning until Sat 5th September ?
The answer is that in an unfortunate coincidence of timing we have a big 
lab move that begins around
9am PT Wed 2nd September, and all our testing capabilities will be 
off-line for several days.

So any test jobs submitted after sometime Tuesday won't have time
to complete, and the lab move won't be complete until after the skara 
transition.


Any outstanding reviews that don't make the cut-off will of course have 
to be resubmitted as github pull requests
and any approvals they may have accumulated will need to be re-approved. 
All of this is of course true for
folks pushing directly to the mercurial main JDK repo - it is not 
related to the client repo retirement.


-Phil

[OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11

[Philip Race]

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

Webrev : http://cr.openjdk.java.net/~prr/8245400/

A rotuine 3rd party library upgrade.

All platforms build  + all tests pass.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for libfontmanager

[Philip Race]

I left that alone on purpose. I have no way of testing it and whereas 
for the 32 bit
linux case I had an idea of what to fix, for xlc all I could find was it 
came in with
https://bugs.openjdk.java.net/browse/JDK-8154087 and I've no idea what 
the problems were.


SAP or IBM can look at it if they want as a separate fix.

-phil.

On 8/27/20, 12:45 PM, Sergey Bylokhov wrote:

Hi, Phil.

Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we 
will need a confirmation from the SAP gurus.


On 27.08.2020 12:39, Philip Race wrote:

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

This resolves the disabled compiler warnings in what is now quite a 
small fontmanager library.


I've built windows, mac and linux in our build system and run our 
full battery of automated tests and sanity checked manual.


A quick run down of how the warnings map to the changes

   DISABLED_WARNINGS_clang := sign-compare,

   DISABLED_WARNINGS_gcc := sign-compare unused-function 
int-to-pointer-cast,


Sign compare in both of the above are the reason for the majority of 
the changes in freetypeScaler.c

and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here 
https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or 
test that I was flying in the dark here

using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


   DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning 
C4244: '=': conversion from 'jlong' to 'long', possible loss of data


  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
warning C4146: unary minus operator applied to unsigned type, result 
still unsigned


./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error 
C2220: the following warning is treated as an error
[ 
./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): warning 
C4996: 'GetVersion': was declared deprecated


GetVersion isn't needed any more since we aren't likely to be running 
on anything older than XP !


-phil.

[OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for libfontmanager

[Philip Race]

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

This resolves the disabled compiler warnings in what is now quite a 
small fontmanager library.


I've built windows, mac and linux in our build system and run our full 
battery of automated tests and sanity checked manual.


A quick run down of how the warnings map to the changes

  DISABLED_WARNINGS_clang := sign-compare,

  DISABLED_WARNINGS_gcc := sign-compare unused-function int-to-pointer-cast,

Sign compare in both of the above are the reason for the majority of the 
changes in freetypeScaler.c
and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here 
https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or test that I 
was flying in the dark here
using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


  DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error 
C2220: the following warning is treated as an error
 ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning 
C4244: '=': conversion from 'jlong' to 'long', possible loss of data

 ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
error C2220: the following warning is treated as an error
 ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
warning C4146: unary minus operator applied to unsigned type, result still 
unsigned

./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error 
C2220: the following warning is treated as an error
[ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
warning C4996: 'GetVersion': was declared deprecated

GetVersion isn't needed any more since we aren't likely to be running on 
anything older than XP !

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

[Philip Race]

This looks reasonable but we need to test it first before approving it.

-phil.

On 8/27/20, 6:16 AM, Vipin Mv1 wrote:

Hi,

Please find below a patch for the following issue.

https://bugs.openjdk.java.net/browse/JDK-8234393


http://cr.openjdk.java.net/~aleonard/8234393/webrev.00

Thanks&  Regards
Vipin MV

Re: [OpenJDK 2D-Dev] RFR: 7183828 Invalid Image Variant when using anything other than BufferedImage

[Philip Race]

Can you please add an evaluation to the bug report explaining what you 
intend to do.
The submitter of that bug was clearly hoping that we'd support custom 
Image subclasses
and this fix just changes the behaviour from an IAE (or similar) to 
silently ignoring them.
I'm not sure what benefit there is there. It just means that people will 
be more puzzled

as to what is going on than before.

Also now we have more checks for specific known image types.
VolatileImage is an abstract class and I'm surprised that this is 
something this fix

considers OK for subclasses to extend. Does that really work ?

I think we should have just closed this out as WNF / not an issue.

-phil.

On 7/27/20, 10:14 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

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

Our DrawImage pipe, used as low-level machinery to draw the known type 
of images, supports only

three types of images:
 - ToolkitImage - implemented via ImageRepresentation.drawToBufImage()
 - VolatileImage/BufferedImage implemented via different types of "loops"

We have a type check for the ToolkitImage image only, otherwise, we 
assume that the image is
of type VolatileImage/BufferedImage, so if the user creates its own 
image and passes it to

this pipe he will get an exception.

After the fix, such custom images will be ignored by the DrawImage pipe.

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

[Philip Race]

On 8/25/20, 4:01 PM, Sergey Bylokhov wrote:


It is applied if the "automatic graphics switching" is enabled, if 
the user disables
this feature for the "power adapter" mode, then the discrete 
graphics will be always used.


That's a bit misleading
If I disable automatic graphics switching it is disabled for BOTH 
batter and power
and vice versa. In other words there is no way to express that 
battery power should fall back
to integrated and that you only want discrete when running on the 
adapter.


It is possible to do it manually, in the "power adapter" mode the user 
can disable
"automatic graphics switching", and enable it in the "battery" mode. 


What do you mean by "manually" ?

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

[Philip Race]

On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:

On 25.08.2020 05:43, Kevin Rushforth wrote:
Does this only apply when the MacBook is running on battery, or will 
this affect performance even when the laptop is plugged in? If the 
latter, I wonder what Apple's rationale is for including a discrete 
graphics card that isn't used most of the time.


Based on the numbers, I wonder if we should make this change ?


It is applied if the "automatic graphics switching" is enabled, if the 
user disables
this feature for the "power adapter" mode, then the discrete graphics 
will be always used.


That's a bit misleading
If I disable automatic graphics switching it is disabled for BOTH batter 
and power
and vice versa. In other words there is no way to express that battery 
power should fall back

to integrated and that you only want discrete when running on the adapter.

-phil





I guess by default they try to "maximize battery life":
https://support.apple.com/en-us/HT202043



-- Kevin


On 8/24/2020 11:27 PM, Sergey Bylokhov wrote:

On 24.08.2020 13:35, Philip Race wrote:


Is there any performance cost to doing this ? I'd expect so. Any 
estimate ?


Yes, performance is affected for sure:

 - SwingMark:
   OGL_Base: 14000
   OGL_Fix: 24000
   Metal: 18000

 - Here is a j2dbench for the common draw operations(new/old/metal):
   http://cr.openjdk.java.net/~serb/8251854/perf/results.txt

  Summary:
  OGL_base:
Number of tests:  24
Overall average:  4.556306150323041E8
Best spread:  0.16% variance
Worst spread: 4.68% variance
(Basis for results comparison)

  OGL_fix:
Number of tests:  24
Overall average:  1.0086929824044746E8
Best spread:  0.04% variance
Worst spread: 7.89% variance
Comparison to basis:
  Best result:  83.41% of basis
  Worst result: 15.73% of basis
  Number of wins:   0
  Number of ties:   0
  Number of losses: 24

  metal:
Number of tests:  24
Overall average:  8.841681616575797E7
Best spread:  0.08% variance
Worst spread: 5.64% variance
Comparison to basis:
  Best result:  248.11% of basis
  Worst result: 19.1% of basis
  Number of wins:   8
  Number of ties:   2
  Number of losses: 14
==

 - Here is a j2dbench for the common draw operations(newOGL vs metal 
only):

http://cr.openjdk.java.net/~serb/8251854/perf/newOGL_vs_Metal.txt
Summary:
  OGL_fix:
Number of tests:  24
Overall average:  2.5871177969681844E7
Best spread:  0.04% variance
Worst spread: 7.01% variance
(Basis for results comparison)

  metal:
Number of tests:  24
Overall average:  2.1896134898150157E7
Best spread:  0.04% variance
Worst spread: 1.98% variance
Comparison to basis:
  Best result:  488.31% of basis
  Worst result: 30.77% of basis
  Number of wins:   14
  Number of ties:   0
  Number of losses: 10

And there's then no way to explicitly request the discrete card on 
a 15/16" MBP.


  I have checked that the discrete card is enabled by the macOS:
  - if the full screen window is set
  - if the second monitor is connected
  Do not know any other ways to enable it.



Should we release note this ?


Yes, I think so.
Note that it does not affect the bundled applications only apps 
running via java launcher.

But some(most?) bundled java applications use this flag already.

Re: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux

[Philip Race]

This is fine but
1) I like to see the bug under which you fixed it in the @bug list.
2) I am not sure I see how all the various reasons for this test failing 
can be explained by this.


-phil.

On 8/25/20, 1:37 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

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

This the only test which was created to check different types of 
interpolation.
It checks the rendering to the VolatileImage and uses BufferedImage as 
a gold image.
But it does not take into account that rendering to the VolatileImage 
might be affected

by the HiDPI support.

[OpenJDK 2D-Dev] RFR: 8247867: Upgrade to freetype 2.10.2

[Philip Race]

bug: https://bugs.openjdk.java.net/browse/JDK-8247867
webrev: http://cr.openjdk.java.net/~prr/8247867/

Minor upgrade from 2.10.1 to 2.10.2
All the usual desktop tests pass.

the vast majority of the files are touched only with a one line 
2019->2020 copyright update

made by the freetype devs.

-phi

Re: [OpenJDK 2D-Dev] RFR: 8251469 Better cleanup for test/jdk/javax/imageio/SetOutput.java

[Philip Race]

+1

-phil

On 8/15/20, 8:48 PM, Sergey Bylokhov wrote:

Hello.
Please review the fix for jdk/client.

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

One more test which leaks the temp file, because it does not close the 
IOS stream.

Re: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager

[Philip Race]

One isn't strictly required, but the code in the file isn't used.

The other (hb-coretext.cc) needs to be excluded on other platforms 
besides macOS.


I think the build must actually strip the directory part and just look for
the filename part, else the build should have failed with the wrong path.

-phil.

On 8/11/20, 2:38 AM, Magnus Ihse Bursie wrote:



On 2020-08-10 22:47, Philip Race wrote:

bug: https://bugs.openjdk.java.net/browse/JDK-8251367
webrev: http://cr.openjdk.java.net/~prr/8251367/

When using something other than the java launcher (ie the jpackage 
launcher)

harfbuzz.dll is not found by windows dll loading.
So we need to load it explicitly else the Java class that loads 
fontmanager,dll

will fail to initialize.

At the same time, I'd like to fix a very minor inconsequential pair 
of typoes

that exclude from the build files by the wrong directory pathname.

Phil,

Is the exclude still needed, if the build worked fine without it..?

/Magnus


-phil.

[OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager

[Philip Race]

bug: https://bugs.openjdk.java.net/browse/JDK-8251367
webrev: http://cr.openjdk.java.net/~prr/8251367/

When using something other than the java launcher (ie the jpackage launcher)
harfbuzz.dll is not found by windows dll loading.
So we need to load it explicitly else the Java class that loads 
fontmanager,dll

will fail to initialize.

At the same time, I'd like to fix a very minor inconsequential pair of 
typoes

that exclude from the build files by the wrong directory pathname.

-phil.

[OpenJDK 2D-Dev] EA4 build of Project Lanai (Metal rendering pipeline for macOS) is now posted.

[Philip Race]

https://jdk.java.net/lanai/ is now hosting the EA 4 build of Lanai


   Build 16-lanai+1-51 (2020/8/3)


List of notable fixed bugs since EA 3

 * 8233226: Implement XOR Mode rendering option
   
 * 8247564: Lanai - SwingSet2 - Motif LF - UI controls border is
   incorrectly drawn with uiScale=1.0
   
 * 8244402: Lanai - Motif L - Non selected Radio button is barely
   rendered on non-retina display
   
 * 8248831: Lanai : SwingSet2Demo Input dialog is not proper for
   MetalLookAndFeel with default non-retina display
   
 * 8240221: XOR mode rendering option does not work with Texture paint
   and Gradient Paint 
 * 8247556: Lanai : J2DDemo - ImageOps demo - Few options are not
   working... 
 * 8247831: Clamp texture height to maxTextureSize(16384)
   
 * 8249174: Fix improper glyph cache initialization logic for text
   rende... 
 * 8243953: Optimize encoder creation/deletion logic for LCD text
   rendering 

-phil.

[OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh, .m, and .mm files

[Philip Race]

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

In advance of the move to Project Skara/git it is desirable to clean up 
whitespace in source files
that are not currently checked by jcheck so we can add these extensions 
to jcheck at that time.


The fix is therefore to remove tabs and trailing spaces.

The 3rd party harfbuzz library has .cc and .hh files but there are no 
current violations there

since I've cleaned those up when importing harfbuzz upgrades.

There is one JDK file that relates to those that inherited tabs that is 
fixed.


But almost all the fixes are in Objective C .m and .mm files.
JDK has no examples of .mm but JavaFX does so I was looking just to be sure.

And all but one of the .m violations are in the desktop module which is 
mainly because

that is where all but 5 of the Objective-C files are.

The only non-desktop violator is
./jdk.hotspot.agent/macosx/native/libsaproc/MacosxDebuggerLocal.m
and that is included in this webrev and why I've included 
serviceability-dev.


-phil.

Re: [OpenJDK 2D-Dev] [16] RFR JDK-8243674: Remove language tag length limit for iTXt chunk in PNGImageReader

[Philip Race]

+1

-phil.

On 7/30/20, 3:55 PM, Sergey Bylokhov wrote:

Hi, Jay.

The fix looks fine, but maybe we can to trigger added 
IIOException(remainingLen < 0) by the test?


On 29.07.2020 02:41, Jayathirth D v wrote:

Hello All,

Please review the following fix for JDK 16:

Bug : https://bugs.openjdk.java.net/browse/JDK-8243674
Webrev : http://cr.openjdk.java.net/~jdv/8243674/webrev.00/

Issue : We have language tag length limit of 80 for iTXt chunk in 
PNGImageReader which is not spec 
compliant(http://www.libpng.org/pub/png/spec/1.2/PNG-Chunks.html#C.iTXt). 
There should not be limit on length of language tag.
Solution : Remove language tag restriction of 80. In PNGImageWriter 
we don’t enforce any limit on language tag length.


Thanks,
Jay

Re: [OpenJDK 2D-Dev] RFR: 8250894 : Provide a configure option to build and run against the platform libharfbuzz

[Philip Race]

Done : http://cr.openjdk.java.net/~prr/8250894.1/

Although it makes the webrev noisier ..

-phil.

On 7/31/20, 11:48 AM, Erik Joelsson wrote:

Hello Phil,

Looks good. The only thing I would ask is that you indent everything 
in the else clause in Awt2dLibraries.gmk.


Thanks

/Erik

On 2020-07-31 10:58, Philip Race wrote:

bug: https://bugs.openjdk.java.net/browse/JDK-8250894
webrev : http://cr.openjdk.java.net/~prr/8250894/

Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated
out libharfbuzz from libfontmanager, it would be natural for distros
to want to link against the libharfbuzz that they distribute with the
platform, as is done for libfreetype. But there is no way to do it.

This fix adds a --with-harfbuzz=system configure option.
The valid values are system and bundled.
If specifying system it checks to see if you have the harfbuzz 
development package installed


Like similar options it is only useful on platforms that distribute
libharfbuzz, so there is no need to try to support windows and macOS 
for this option

and it will fast fail at configure time on those platforms.

I have verified this fix on Ubuntu 20.04 LTS.

-phil.

[OpenJDK 2D-Dev] RFR: 8250894 : Provide a configure option to build and run against the platform libharfbuzz

[Philip Race]

bug: https://bugs.openjdk.java.net/browse/JDK-8250894
webrev : http://cr.openjdk.java.net/~prr/8250894/

Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated
out libharfbuzz from libfontmanager, it would be natural for distros
to want to link against the libharfbuzz that they distribute with the
platform, as is done for libfreetype. But there is no way to do it.

This fix adds a --with-harfbuzz=system configure option.
The valid values are system and bundled.
If specifying system it checks to see if you have the harfbuzz 
development package installed


Like similar options it is only useful on platforms that distribute
libharfbuzz, so there is no need to try to support windows and macOS for 
this option

and it will fast fail at configure time on those platforms.

I have verified this fix on Ubuntu 20.04 LTS.

-phil.

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

Ok. Approved.

I assume no one found a way to provoke this without changing the Windows 
system locale

so we can't create a test.

-phil.

On 7/28/20, 10:40 PM, Yasumasa Suenaga wrote:

On 2020/07/29 11:27, Phil Race wrote:
Did you copy/paste my typo ? Looks like a . not a , in the string 
literal.


Fixed: http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.03/

Yasumasa



-Phil.

On Jul 28, 2020, at 6:52 PM, Yasumasa Suenaga 
 wrote:


Hi Phil, Sergey,

Sorry, I missed. null is WComponentPeer::pData, not defaultFont.
I removed the change for WFontPeer from new webrev.

  http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.02/

If you are ok this, I will push it to jdk/client.


Thanks,

Yasumasa



On 2020/07/29 10:21, Philip Race wrote:
The change in WFontConfiguration looks good but I have no idea
what the change in WComponentPeer is supposed to achieve.
"new Font()" won't fail. And the constructor is VERY lazy.
It sets fields and returns. That's all.
-phil.

On 7/28/20, 6:10 PM, Yasumasa Suenaga wrote:
On 2020/07/29 9:49, Philip Race wrote:



On 7/28/20, 5:35 PM, Yasumasa Suenaga wrote:

Hi Phil,

Thanks for explanation.

findFontWithCharset() does not have comments, so I cannot 
evaluate my proposal whether it breaks important behavior, but I 
almost agree with your change.


However...


sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything 
and we'll still crash.


then isn't it dangerous "Arial,ANSI_CHARSET" is set to fontName 
forced?


Nope, because the problem is that we may to return anything from 
this method (ie

return null instead). This is obviously not null so is fine.


Ok, so how about this change?

   http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.01/


Yasumasa



-phil.





if (fontName ==null) {
  if (fontDescriptors.length >0) {
return fontDescriptors[0].getNativeName();
  }else {
  fontName ="Arial,ANSI_CHARSET";
 }
}


The direct cause of the crash which I saw is 
WComponentPeer::defaultFont was null.
So I think we need to assertion to check 
WComponentPeer::defaultFont is not null as a safeguard.


How about this change?

```
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java 

--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java 
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java 
Wed Jul 29 09:32:00 2020 +0900

@@ -56,6 +56,7 @@
  import java.awt.image.VolatileImage;
  import java.awt.peer.ComponentPeer;
  import java.awt.peer.ContainerPeer;
+import java.util.Objects;

  import sun.awt.AWTAccessor;
  import sun.awt.PaintEventDispatcher;
@@ -579,7 +580,12 @@
  }

  // fallback default font object
-static final Font defaultFont = new Font(Font.DIALOG, 
Font.PLAIN, 12);

+static final Font defaultFont;
+
+static {
+defaultFont = new Font(Font.DIALOG, Font.PLAIN, 12);
+Objects.requireNonNull(defaultFont, "default font must 
not be null");

+}

  @Override
  public Graphics getGraphics() {
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java 

--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java 
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java 
Wed Jul 29 09:32:00 2020 +0900

@@ -157,9 +157,12 @@
  public String getTextComponentFontName(String familyName, 
int style) {
  FontDescriptor[] fontDescriptors = 
getFontDescriptors(familyName, style);
  String fontName = findFontWithCharset(fontDescriptors, 
textInputCharset);

-if (fontName == null) {
+if ((fontName == null) && 
!textInputCharset.equals("DEFAULT_CHARSET")) {
  fontName = findFontWithCharset(fontDescriptors, 
"DEFAULT_CHARSET");

  }
+if ((fontName == null) && (fontDescriptors.length > 0)) {
+fontName = fontDescriptors[0].getNativeName();
+}
      return fontName;
  }

```


Thanks,

Yasumasa


On 2020/07/28 23:43, Philip Race wrote:

1) You assume there is a font with ANSI_CHARSET in the list.
I thought I already tried to point out that if the entry looked 
like this


sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything 
and we'll still crash.


2) changing findFontWithCharset is still the wrong/more 
dangerous place to change this.

You may be uninintentionally changing behaviour.

My proposal won't break anything. It just finds a fall back 
when otherwise we'd crash.


I am not sure any of the CHARSET selections ma

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

The change in WFontConfiguration looks good but I have no idea
what the change in WComponentPeer is supposed to achieve.
"new Font()" won't fail. And the constructor is VERY lazy.
It sets fields and returns. That's all.

-phil.

On 7/28/20, 6:10 PM, Yasumasa Suenaga wrote:

On 2020/07/29 9:49, Philip Race wrote:



On 7/28/20, 5:35 PM, Yasumasa Suenaga wrote:

Hi Phil,

Thanks for explanation.

findFontWithCharset() does not have comments, so I cannot evaluate 
my proposal whether it breaks important behavior, but I almost agree 
with your change.


However...


sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything and 
we'll still crash.


then isn't it dangerous "Arial,ANSI_CHARSET" is set to fontName forced?


Nope, because the problem is that we may to return anything from this 
method (ie

return null instead). This is obviously not null so is fine.


Ok, so how about this change?

  http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.01/


Yasumasa



-phil.





if (fontName ==null) {
 if (fontDescriptors.length >0) {
   return fontDescriptors[0].getNativeName();
 }else {
 fontName ="Arial,ANSI_CHARSET";
}
}


The direct cause of the crash which I saw is 
WComponentPeer::defaultFont was null.
So I think we need to assertion to check WComponentPeer::defaultFont 
is not null as a safeguard.


How about this change?

```
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java
--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java 
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java 
Wed Jul 29 09:32:00 2020 +0900

@@ -56,6 +56,7 @@
 import java.awt.image.VolatileImage;
 import java.awt.peer.ComponentPeer;
 import java.awt.peer.ContainerPeer;
+import java.util.Objects;

 import sun.awt.AWTAccessor;
 import sun.awt.PaintEventDispatcher;
@@ -579,7 +580,12 @@
 }

 // fallback default font object
-static final Font defaultFont = new Font(Font.DIALOG, 
Font.PLAIN, 12);

+static final Font defaultFont;
+
+static {
+defaultFont = new Font(Font.DIALOG, Font.PLAIN, 12);
+Objects.requireNonNull(defaultFont, "default font must not 
be null");

+}

 @Override
 public Graphics getGraphics() {
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java 

--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java 
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java 
Wed Jul 29 09:32:00 2020 +0900

@@ -157,9 +157,12 @@
 public String getTextComponentFontName(String familyName, int 
style) {
 FontDescriptor[] fontDescriptors = 
getFontDescriptors(familyName, style);
 String fontName = findFontWithCharset(fontDescriptors, 
textInputCharset);

-if (fontName == null) {
+if ((fontName == null) && 
!textInputCharset.equals("DEFAULT_CHARSET")) {
 fontName = findFontWithCharset(fontDescriptors, 
"DEFAULT_CHARSET");

 }
+if ((fontName == null) && (fontDescriptors.length > 0)) {
+fontName = fontDescriptors[0].getNativeName();
+}
     return fontName;
 }

```


Thanks,

Yasumasa


On 2020/07/28 23:43, Philip Race wrote:

1) You assume there is a font with ANSI_CHARSET in the list.
I thought I already tried to point out that if the entry looked 
like this


sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything and 
we'll still crash.


2) changing findFontWithCharset is still the wrong/more dangerous 
place to change this.

You may be uninintentionally changing behaviour.

My proposal won't break anything. It just finds a fall back when 
otherwise we'd crash.


I am not sure any of the CHARSET selections matter any more when 
using a unicode locale.

It is mainly about selecting the most appropriate font.

And that isn't going to work with out more changes.

At the very least we have to augment these
 subsetCharsetMap.put("japanese", "SHIFTJIS_CHARSET");
 subsetEncodingMap.put("japanese", "windows-31j");

with *something like*

 subsetCharsetMap.put("ja_utf8", "DEFAULT_CHARSET");
 subsetEncodingMap.put("japanese-utf8", "utf-8");

and also update the fontconfig file to have
sequence.allfonts.UTF-8.ja=alphabetic,ja_utf8,dingbats,symbol

and lots of fontconfig change like adding
sequence.serif.japanese-utf8=alphabetic,ja_utf8,dingbats,symbol

I ha

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

On 7/28/20, 5:35 PM, Yasumasa Suenaga wrote:

Hi Phil,

Thanks for explanation.

findFontWithCharset() does not have comments, so I cannot evaluate my 
proposal whether it breaks important behavior, but I almost agree with 
your change.


However...


sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything and 
we'll still crash.


then isn't it dangerous "Arial,ANSI_CHARSET" is set to fontName forced?


Nope, because the problem is that we may to return anything from this 
method (ie

return null instead). This is obviously not null so is fine.

-phil.





if (fontName ==null) {
 if (fontDescriptors.length >0) {
   return fontDescriptors[0].getNativeName();
 }else {
 fontName ="Arial,ANSI_CHARSET";
}
}


The direct cause of the crash which I saw is 
WComponentPeer::defaultFont was null.
So I think we need to assertion to check WComponentPeer::defaultFont 
is not null as a safeguard.


How about this change?

```
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java
--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java  
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java  
Wed Jul 29 09:32:00 2020 +0900

@@ -56,6 +56,7 @@
 import java.awt.image.VolatileImage;
 import java.awt.peer.ComponentPeer;
 import java.awt.peer.ContainerPeer;
+import java.util.Objects;

 import sun.awt.AWTAccessor;
 import sun.awt.PaintEventDispatcher;
@@ -579,7 +580,12 @@
 }

 // fallback default font object
-static final Font defaultFont = new Font(Font.DIALOG, Font.PLAIN, 
12);

+static final Font defaultFont;
+
+static {
+defaultFont = new Font(Font.DIALOG, Font.PLAIN, 12);
+Objects.requireNonNull(defaultFont, "default font must not be 
null");

+}

 @Override
 public Graphics getGraphics() {
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java
--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java  
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java  
Wed Jul 29 09:32:00 2020 +0900

@@ -157,9 +157,12 @@
 public String getTextComponentFontName(String familyName, int 
style) {
 FontDescriptor[] fontDescriptors = 
getFontDescriptors(familyName, style);
 String fontName = findFontWithCharset(fontDescriptors, 
textInputCharset);

-if (fontName == null) {
+if ((fontName == null) && 
!textInputCharset.equals("DEFAULT_CHARSET")) {
 fontName = findFontWithCharset(fontDescriptors, 
"DEFAULT_CHARSET");

 }
+if ((fontName == null) && (fontDescriptors.length > 0)) {
+fontName = fontDescriptors[0].getNativeName();
+}
 return fontName;
 }

```


Thanks,

Yasumasa


On 2020/07/28 23:43, Philip Race wrote:

1) You assume there is a font with ANSI_CHARSET in the list.
I thought I already tried to point out that if the entry looked like 
this


sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything and 
we'll still crash.


2) changing findFontWithCharset is still the wrong/more dangerous 
place to change this.

You may be uninintentionally changing behaviour.

My proposal won't break anything. It just finds a fall back when 
otherwise we'd crash.


I am not sure any of the CHARSET selections matter any more when 
using a unicode locale.

It is mainly about selecting the most appropriate font.

And that isn't going to work with out more changes.

At the very least we have to augment these
 subsetCharsetMap.put("japanese", "SHIFTJIS_CHARSET");
 subsetEncodingMap.put("japanese", "windows-31j");

with *something like*

 subsetCharsetMap.put("ja_utf8", "DEFAULT_CHARSET");
 subsetEncodingMap.put("japanese-utf8", "utf-8");

and also update the fontconfig file to have
sequence.allfonts.UTF-8.ja=alphabetic,ja_utf8,dingbats,symbol

and lots of fontconfig change like adding
sequence.serif.japanese-utf8=alphabetic,ja_utf8,dingbats,symbol

I haven't thought that through to see if this is exactly right but it 
is what is really missing IMO.


However having done all of that it still doesn't change that
1) There is the possibility of  a crash if not done right
2) It isn't clear that it *really matters*.

And a rearchitecture of this file and the supporting code is beyond 
the scope of what we want to do today ...


-phil

On 7/28/20, 2:21 AM, Yasumasa Suenaga wrote:

Hi

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

1) You assume there is a font with ANSI_CHARSET in the list.
I thought I already tried to point out that if the entry looked like this

sequence.allfonts.UTF-8.ja=japanese,dingbats,symbol
instead of the current
sequence.allfonts.UTF-8.ja=alphabetic,japanese,dingbats,symbol

then I am not sure your fix in-line below will find anything and we'll 
still crash.


2) changing findFontWithCharset is still the wrong/more dangerous place 
to change this.

You may be uninintentionally changing behaviour.

My proposal won't break anything. It just finds a fall back when 
otherwise we'd crash.


I am not sure any of the CHARSET selections matter any more when using a 
unicode locale.

It is mainly about selecting the most appropriate font.

And that isn't going to work with out more changes.

At the very least we have to augment these
subsetCharsetMap.put("japanese", "SHIFTJIS_CHARSET");
subsetEncodingMap.put("japanese", "windows-31j");

with *something like*

subsetCharsetMap.put("ja_utf8", "DEFAULT_CHARSET");
subsetEncodingMap.put("japanese-utf8", "utf-8");

and also update the fontconfig file to have
sequence.allfonts.UTF-8.ja=alphabetic,ja_utf8,dingbats,symbol

and lots of fontconfig change like adding
sequence.serif.japanese-utf8=alphabetic,ja_utf8,dingbats,symbol

I haven't thought that through to see if this is exactly right but it is 
what is really missing IMO.


However having done all of that it still doesn't change that
1) There is the possibility of  a crash if not done right
2) It isn't clear that it *really matters*.

And a rearchitecture of this file and the supporting code is beyond the 
scope of what we want to do today ...


-phil

On 7/28/20, 2:21 AM, Yasumasa Suenaga wrote:

Hi Phil

Thank you so much for further investigation!
Your change works fine on my Windows which is set to Japanese locale.

However I wonder the meanings of "DEFAULT_CHARSET". It does not appear 
to be working, right?


To my understand, alphabetic font should be used if "DEFAULT_CHARSET" 
is chosen.

(So I think your change may be chosen "Arial,ANSI_CHARSET")

Thus I think we can fix as below:

```
diff -r 1a722ad6e23d 
src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java
--- 
a/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java  
Tue Jul 28 09:05:36 2020 +0200
+++ 
b/src/java.desktop/windows/classes/sun/awt/windows/WFontConfiguration.java  
Tue Jul 28 18:08:06 2020 +0900

@@ -165,6 +165,9 @@

 private String findFontWithCharset(FontDescriptor[] 
fontDescriptors, String charset) {

 String fontName = null;
+if (charset.equals("DEFAULT_CHARSET")) {
+charset = "ANSI_CHARSET";
+}
 for (int i = 0; i < fontDescriptors.length; i++) {
 String componentFontName = 
fontDescriptors[i].getNativeName();

 if (componentFontName.endsWith(charset)) {
```

The following code is pointless as you said, so I agree with you to 
remove it.



if (fontName ==null) {
 fontName = findFontWithCharset(fontDescriptors,"DEFAULT_CHARSET");
}



Thanks,

Yasumasa


On 2020/07/28 15:15, Philip Race wrote:

I do see some case when default is being returned.

subsetEncodingMap.put("alphabetic", "default");

which then needs an alphabetic font as part of the core script sequence.
Now looking at desc.isDefaultFont() && 
charset.equals("DEFAULT_CHARSET") Perhaps that could change the 
answer in some cases you don't intend. For these UTF 8 locales there 
is nothing in the fontconfig that identifies the right font. The "ja" 
in UTF-8.ja is not connected to "japanese" in the fontconfig file. 
Something like that may be the right fix but it would be a bigger 
change. I am not sure how much it matters either. There just needs to 
be a font. In the win9x days and when AWT was an "A" lib not using 
unicode maybe. Or maybe there's still some benefit to the right font 
for the language still being set as the text component font but it is 
not happening anyway in this case and your fix won't solve that. All 
roads lead to the latin/alphabetic font here. My thinking right now 
is to just make changes in getTextComponentFontNameso it always 
returns something but only after the current code fails.

So instead of your fix, just add this there :

if (fontName ==null) {
 if (fontDescriptors.length >0) {
   return fontDescriptors[0].getNativeName();
 }else {
 fontName ="Arial,ANSI_CHARSET";
}
}

Not very satisfactory but then we can remove the comment about maybe 
returning NULL. -phil.

On 7/27/2020 5:34 PM, Philip Race wrote:
This did start when we updated the fontconfiguration file but I 
think there was nothing wrong with the update
and I found it could happen wit

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

I do see some case when default is being returned.

subsetEncodingMap.put("alphabetic", "default");

which then needs an alphabetic font as part of the core script sequence.
Now looking at desc.isDefaultFont() && charset.equals("DEFAULT_CHARSET") 
Perhaps that could change the answer in some cases you don't intend. For 
these UTF 8 locales there is nothing in the fontconfig that identifies 
the right font. The "ja" in UTF-8.ja is not connected to "japanese" in 
the fontconfig file. Something like that may be the right fix but it 
would be a bigger change. I am not sure how much it matters either. 
There just needs to be a font. In the win9x days and when AWT was an "A" 
lib not using unicode maybe. Or maybe there's still some benefit to the 
right font for the language still being set as the text component font 
but it is not happening anyway in this case and your fix won't solve 
that. All roads lead to the latin/alphabetic font here. My thinking 
right now is to just make changes in getTextComponentFontNameso it 
always returns something but only after the current code fails.

So instead of your fix, just add this there :

if (fontName ==null) {
if (fontDescriptors.length >0) {
  return fontDescriptors[0].getNativeName();
}else {
fontName ="Arial,ANSI_CHARSET";
   }
}

Not very satisfactory but then we can remove the comment about maybe 
returning NULL. -phil.

On 7/27/2020 5:34 PM, Philip Race wrote:
This did start when we updated the fontconfiguration file but I think 
there was nothing wrong with the update
and I found it could happen with the previous  version if we just 
remove "devanagari" from this line in the OLD version.


sequence.allfonts.UTF-8.ja=alphabetic,japanese,devanagari,dingbats,symbol

Removing that mimics what happened in the new version and is the first 
piece of the puzzle.


I don't know why devanagari is even there. Possibly it is because that 
line was derived from this one :-

sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol
since hindi was the first UTF-8 locale that was supported and someone 
just edited it to create the JA entry.


But it indicates to me that this is quite fragile and could easily 
have crashed a long time ago if Devanagari were

not there as one of the "core fonts" for UTF-8.ja

Then in WFontConfiguration.initTables() a few things happen

first this
subsetCharsetMap.put("devanagari","DEFAULT_CHARSET");
subsetCharsetMap.put("japanese","SHIFTJIS_CHARSET");

[for devanagari JDK specifies the Mangal font.]

the subsetEncodinging map has this for Japanese
  subsetEncodingMap.put("japanese", "windows-31j");

then this for UTF-8 for textInputCharset
}else if ("UTF-8".equals(defaultEncoding)) {
 textInputCharset ="DEFAULT_CHARSET";

whereas for the old ms932/windows-31j code page we would have had this

}else if ("windows-31j".equals(defaultEncoding)) {
 textInputCharset ="SHIFTJIS_CHARSET";

it then calls makeAWTFontName("MS Gothic", "japanese");
which looks like this :

WFontConfiguration.makeAWTFontName(String platformFontName, String 
characterSubsetName) {
 String windowsCharset = subsetCharsetMap.get(characterSubsetName);
 if (windowsCharset ==null) {
 windowsCharset ="DEFAULT_CHARSET";
 }
 return platformFontName +"," + windowsCharset;
}

For "japanese", the result of
subsetCharsetMap.get(characterSubsetName);

will always be"SHIFTJIS_CHARSET"

So the method will return "MS Gothic,SHIFTJIS_CHARSET"
and this will get stored in the FontDescriptor

The other core entries for Japanese map to ANSI_CHARSET and SYMBOL_CHARSET.

When in the old fontconfig file  is called for "devanagari", it will return 
"Mangal,DEFAULT_CHARSET".

Without that, there is no DEFAULT_CHARSET mapped for any font in the core 
Japanese fonts.

This all becomes important when WFontConfiguration.getTextComponentFontName() 
is called from native code.

It has this line
String fontName = findFontWithCharset(fontDescriptors, textInputCharset);

from above we know that for UTF-8 :
 textInputCharset ="DEFAULT_CHARSET";

but as just noted above there are NO fonts tagged with that

So the look up fails. The code retries : -
if (fontName ==null) {
 fontName = findFontWithCharset(fontDescriptors,"DEFAULT_CHARSET");
}
  
but that was pointless since DEFAULT_CHARSET is what was already tried.


Now back to the windows-31j locale, there we had

 textInputCharset ="SHIFTJIS_CHARSET";

so that finds the match "MS Gothic,SHIFTJIS_CHARSET".

  getTextComponentFontName() has the comment "May return null." which is true, 
but not very helpful to the native caller, which bails out, l

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

This did start when we updated the fontconfiguration file but I think 
there was nothing wrong with the update
and I found it could happen with the previous  version if we just remove 
"devanagari" from this line in the OLD version.


sequence.allfonts.UTF-8.ja=alphabetic,japanese,devanagari,dingbats,symbol

Removing that mimics what happened in the new version and is the first 
piece of the puzzle.


I don't know why devanagari is even there. Possibly it is because that 
line was derived from this one :-

sequence.allfonts.UTF-8.hi=alphabetic/1252,devanagari,dingbats,symbol
since hindi was the first UTF-8 locale that was supported and someone 
just edited it to create the JA entry.


But it indicates to me that this is quite fragile and could easily have 
crashed a long time ago if Devanagari were

not there as one of the "core fonts" for UTF-8.ja

Then in WFontConfiguration.initTables() a few things happen

first this

subsetCharsetMap.put("devanagari","DEFAULT_CHARSET");
subsetCharsetMap.put("japanese","SHIFTJIS_CHARSET");

[for devanagari JDK specifies the Mangal font.]

the subsetEncodinging map has this for Japanese
 subsetEncodingMap.put("japanese", "windows-31j");

then this for UTF-8 for textInputCharset
}else if ("UTF-8".equals(defaultEncoding)) {
textInputCharset ="DEFAULT_CHARSET";

whereas for the old ms932/windows-31j code page we would have had this

}else if ("windows-31j".equals(defaultEncoding)) {
textInputCharset ="SHIFTJIS_CHARSET";

it then calls makeAWTFontName("MS Gothic", "japanese");
which looks like this :

WFontConfiguration.makeAWTFontName(String platformFontName, String 
characterSubsetName) {
String windowsCharset = subsetCharsetMap.get(characterSubsetName);
if (windowsCharset ==null) {
windowsCharset ="DEFAULT_CHARSET";
}
return platformFontName +"," + windowsCharset;
}

For "japanese", the result of
subsetCharsetMap.get(characterSubsetName);

will always be"SHIFTJIS_CHARSET"

So the method will return "MS Gothic,SHIFTJIS_CHARSET"
and this will get stored in the FontDescriptor

The other core entries for Japanese map to ANSI_CHARSET and SYMBOL_CHARSET.

When in the old fontconfig file  is called for "devanagari", it will return 
"Mangal,DEFAULT_CHARSET".

Without that, there is no DEFAULT_CHARSET mapped for any font in the core 
Japanese fonts.

This all becomes important when WFontConfiguration.getTextComponentFontName() 
is called from native code.

It has this line
String fontName = findFontWithCharset(fontDescriptors, textInputCharset);

from above we know that for UTF-8 :
textInputCharset ="DEFAULT_CHARSET";

but as just noted above there are NO fonts tagged with that

So the look up fails. The code retries : -
if (fontName ==null) {
fontName = findFontWithCharset(fontDescriptors,"DEFAULT_CHARSET");
}
 
but that was pointless since DEFAULT_CHARSET is what was already tried.


Now back to the windows-31j locale, there we had

textInputCharset ="SHIFTJIS_CHARSET";

so that finds the match "MS Gothic,SHIFTJIS_CHARSET".

 getTextComponentFontName() has the comment "May return null." which is true, 
but not very helpful to the native caller, which bails out, leaving the
native font structs uninitialised and ready to cause a crash.

That's the kind of analysis I was hoping for !

Now, the question is, is what you propose the right fix for this ?
But I am not sure it can even work.

931 descriptors[i] = new FontDescriptor(awtFontName, enc, 
exclusionRanges, encoding.equals("default")); seems like it will never 
pass true in my testing. Then the whole fix falls apart. Can you show 
some evidence ? -phil




On 7/27/2020 3:50 PM, Yasumasa Suenaga wrote:

Hi Phil,

I confirmed WFontConfiguration::findFontWithCharset cannot find if 
-Dfile.encoding=UTF-8 is passed.
I guess one of the cause is the definitions in 
make/data/fontconfig/windows.fontconfig.properties, but also 
DEFAULT_CHARSET does not work at this point.


If we do not pass -Dfile.encoding=UTF-8, `charset` in 
WFontConfiguration::findFontWithCharset is set to "windows-31j" and it 
can find out valid font when Windows is set to Japanese locale.


I can share minidump for further investigation. What should I do / share?


Thanks,

Yasumasa


On 2020/07/28 0:02, Philip Race wrote:

Hi,

You're avoiding a crash but I don't yet know what *exactly* caused 
the crash.
Some Java code not handling DEFAULT_CHARSET is obviously not the 
exact cause.
This just starts it and something bad presumably happens later in 
native code.


And I don't yet understand why (we think) this started happening when 
some

additional fonts were added to the file.

Knowing exactly what is wrong will help decide if this is the rig

Re: [OpenJDK 2D-Dev] RFR (XS) 8250605: Linux x86_32 builds fail after JDK-8249821

[Philip Race]

OK .. although I hope to come back in JDK 16 and eliminate all disabled 
warnings

from the now much smaller libfontmanager :
https://bugs.openjdk.java.net/browse/JDK-8074844

-phil.


On 7/27/20, 5:41 AM, Erik Joelsson wrote:

Looks good to me.

/Erik

On 2020-07-27 00:28, Aleksey Shipilev wrote:

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

I believe this happens because int-to-pointer-cast is now enabled for 
libfontmanager. Below is the
minimal fix, but I wonder if we should reinstate the disabled warning 
for clang (in the same manner)
and msvc (which warning code that one is?). Or we can wait for 
follow-up bug reports there...


Minimal fix:
   https://cr.openjdk.java.net/~shade/8250605/webrev.01/

Testing: Linux {x86_64, x86_32} builds; jdk-submit (running)

Re: [OpenJDK 2D-Dev] RFR JDK-8246742: ServiceUI.printDialog does not support properties dialog

[Philip Race]

+1

-phil.

On 7/26/20, 9:20 PM, Prasanta Sadhukhan wrote:


Hi Phil,

On 24-Jul-20 3:48 AM, Philip Race wrote:
So the bug is that directly calling ServiceUI.printDialog() was 
enabling a non-functional properties button on just the Windows 
platform and you are adding an extra condition to prevent that
without harming the goal of JDK-4673406 to have it enabled and 
functional when invoked by
java.awt.PrinterJob attached to a Windows printer. That is much more 
important than the

bug being fixed here so I'd like definite confirmation of that.
Yes, normal PrinterJob displaying native and cross-platform dialog 
works as before, showing Properties dialog when clicked on it on 
windows. It's only ServiceUI Dialog that disables Properties button 
when no PrinterJob is associated with it.
Also since it is an *extra* condition may I assume we do not enable 
this for a PrinterJob

on mac or linux - the functionality was windows only.


Yes, it does not work for mac/linux as we have the condition

btnProperties.setEnabled(uiFactory!=null&&   job !=null);

and uiFactory is null for mac/linux so the button is disabled for 
those platforms.


http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1637

I think the test should not fail if the button is enabled. It should 
fail only if

the button is enabled *and does nothing*.


OK. Modified webrev with test instructions updated

http://cr.openjdk.java.net/~psadhukhan/8246742/webrev.2/



-phil.

On 7/20/20, 8:15 AM, Prasanta Sadhukhan wrote:


Actually, I was a bit wrong in construing that the button should 
just be disabled for ServiceUI.printDialog if ServiceUIFactory is 
null & getUI(MAIN_ROLE...) is null.


The "properties" dialog is used for another use-case which is for 
cross-platform dialog also ie, when we have a printer job created 
using (in which case also getUI() will be null for windows)


PrintRequestAttributeSet pSet =newHashPrintRequestAttributeSet();
pSet.add(DialogTypeSelection.COMMON);
pj.printDialog(pSet);

And, as per JDK-4673406, it  is likely that supporting this 
/"properties" sheet will only be possible where there is already a 
job with which//
//to make the association. ie using 
java.awt.PrinterJob.printDialog(AttributeSet) and not for direct 
uses with javax.print.ServiceUI.printDialog(..)/"


So, ideally, we should be checking if we have a printer job in 
addition to ServiceUIFactory being not null to allow creation of 
association between printer properties and the printer job
so if a PrinterJob cross-platform printer-dialog is created, then we 
should support "Properties" dialog.
If we directly use javax.print.ServiceUI.printDialog(..), then in 
that case no printer job will be created, so properties dialog can 
be disabled for that use-case.


Modified webrev: 
http://cr.openjdk.java.net/~psadhukhan/8246742/webrev.1/


Regards
Prasanta
On 20-Jul-20 3:53 PM, Jayathirth D v wrote:

Hi Prasanta,

Is just checking for dialog is null fine or we also need to verify 
DocumentProptiesUI in our case? As done in else case when dialog is 
null at 
http://hg.openjdk.java.net/jdk/client/file/fabf11c3a8ca/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l801 ?


I also see that Win32ServiceUIFactory
.getUI() doesnt return null in some specific DocumentsPropertyUI at 
http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/windows/classes/sun/print/Win32PrintService.java#l1692 



Thanks,
Jay

On 17-Jul-2020, at 11:22 AM, Prasanta Sadhukhan 
<mailto:prasanta.sadhuk...@oracle.com>> wrote:


Hi Jay,

I am using the same methodology used to determine whether to show 
the properties dialog when button-clicked on it (which is not to 
show if dialog is null) as per


http://hg.openjdk.java.net/jdk/client/file/fabf11c3a8ca/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l793

So, if we cannot show the dialog using that mechanism, we can 
enable/disable the button itself beforehand using that check.


Regards
Prasanta.
On 16-Jul-20 9:26 PM, Jayathirth D v wrote:

Hi Prasanta,

I tested the fix in Mac and Windows and it works as mentioned.

In 
http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/windows/classes/sun/print/Win32PrintService.java#l1688 we 
are returning null when “role <= ServiceUIFactory.MAIN_UIROLE”. 
So it covers 3 roles “MAIN_UIROLE”, “ADMIN_UIROLE” and 
“ABOUT_UIROLE”.


In your webrev we are checking only for “MAIN_UIROLE”. 
Is creation of “JDIALOG_UI” restricted only to “MAIN_UIROLE”?


Thanks,
Jay

On 15-Jul-2020, at 6:27 PM, Prasanta Sadhukhan 
<mailto:prasanta.sadhuk...@oracle.com>> wrote:


Any reviewer for this?

On 09-Jul-20 1:10 PM, Prasanta Sadhukhan wrote:


Hi All,

Please review a fix for an issue where "Properties" button in 
ServiceUI.printDialog is enabled in windows but clicking it 
doesn't show any dialog.

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

[Philip Race]

Hi,

You're avoiding a crash but I don't yet know what *exactly* caused the 
crash.
Some Java code not handling DEFAULT_CHARSET is obviously not the exact 
cause.
This just starts it and something bad presumably happens later in native 
code.


And I don't yet understand why (we think) this started happening when some
additional fonts were added to the file.

Knowing exactly what is wrong will help decide if this is the right fix.

-phil

On 7/24/20, 5:59 AM, Yasumasa Suenaga wrote:

Hi Jay,

I share you hs_err log of this issue.
`chcp` on my console shows "932" (MS932). It is Japanese locale.

I can share you if you want to know.


Thanks,

Yasumasa


On 2020/07/24 20:59, Jayathirth D V wrote:

Hi Yasumasa,

I tried after changing the locale to Japanese but I don’t see the issue.

Also tried to reproduce the issue by enabling/disabling setting 
"Beta:Use Unicode UTF-8 for worldwide language support" in my locale 
setting.


@Others : Can somebody else try to reproduce this issue?

Thanks,
Jay

-Original Message-
From: Yasumasa Suenaga 
Sent: Thursday, July 23, 2020 5:41 PM
To: Jayathirth D v 
Cc: 2d-dev <2d-dev@openjdk.java.net>; awt-...@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible 
crashed with -Dfile.encoding=UTF-8


Hi Jay,

On 2020/07/23 19:09, Jayathirth D v wrote:

Hi,

I tried reproducing the issue in my Windows 10 machine with UTF-8 
encoding and test file mentioned in the bug, I don’t see any crash.

Am I missing something?


OS locale may be affecting.

My laptop has been set Japanese (CP932 / Windows-31J), so 
WFontConfiguration attempt to find Japanese font by default.
However WFontConfiguration cannot find out the font of 
"DEFAULT_CHARSET" when -Dfile.encoding=UTF-8 is passed.



Thanks,

Yasumasa



Also I think this should be in awt-dev so adding the mailing list.

Thanks,
Jay

On 20-Jul-2020, at 12:59 PM, Yasumasa Suenaga 
 wrote:


PING: could you review it?


JBS: https://bugs.openjdk.java.net/browse/JDK-8249215
webrev: 
http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/


Yasumasa

On 2020/07/11 17:39, Yasumasa Suenaga wrote:

Hi all,
Please review this change:
JBS: https://bugs.openjdk.java.net/browse/JDK-8249215
webrev: 
http://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.00/
I tried to run Sample.java in JDK-8236161 with 
-Dfile.encoding=UTF-8, but JVM crashed due to internal error on 
fastdebug VM. I saw same call stack with JDK-8236161 in hs_err log.
I investigated it, then I found out current implementation cannot 
handle default charset.
If charset is set to UTF-8, it would be handled as 
"DEFAULT_CHARSET" in WFontConfiguration::initTables. However it 
does not affect native font name, so we cannot find valid font.
This change has passed all tests on submit repo 
(mach5-one-ysuenaga-JDK-8249215-20200711-0655-12566039)

Thanks,
Yasumasa

Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins

[Philip Race]

This is fine. Approved.

-phil.

On 7/24/20, 3:08 AM, Kumar Abhishek wrote:


Hi Phil,

This bug was originally only for JPEG plugin though I have verified 
the changes for other plugins as well.


Do you want me to divide the change for different plugins and create 
separate bugs or the current approach is fine?


Please find the updated webrev with superfluous comments removed :

http://cr.openjdk.java.net/~jdv/8200281/webrev.01/ 
<http://cr.openjdk.java.net/%7Ejdv/8200281/webrev.01/>


Thanks,

Abhishek

*From:*Philip Race
*Sent:* Thursday, July 23, 2020 10:37 PM
*To:* Kumar Abhishek 
*Cc:* 2d-dev@openjdk.java.net
*Subject:* Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override 
annotations in ImageIO plugins




On 7/23/20, 5:20 AM, Kumar Abhishek wrote:

Hello, Please review this small change for JDK-16 .

  


This is a clean up task to verify and add missing annotations in ImageIO 
plugins


They are missing in part because most of these classes were added in 
1.4 and
annotations were introduced in 1.5. So I am not sure how much 
retrofitting we
should do along these lines. If applied widely it could just make 
backports painful

when patches will not apply.


  /** Overrides the method defined in the superclass. */
+@Override
  

The comment is now superflous so I suggest to remove it in the couple 
of places it is present.


-phil.

  


Verified and added annotations for all the Writer and Reader implementation 
under src/java.desktop/share/classes/com/sun/imageio/plugins/

  


Bug/webrev :

  


https://bugs.openjdk.java.net/browse/JDK-8200281

http://cr.openjdk.java.net/~jdv/8200281/webrev.00/  <http://cr.openjdk.java.net/%7Ejdv/8200281/webrev.00/>  

  

  


Thanks, Abhishek

Re: [OpenJDK 2D-Dev] RFR JDK-8246742: ServiceUI.printDialog does not support properties dialog

[Philip Race]

So the bug is that directly calling ServiceUI.printDialog() was enabling 
a non-functional properties button on just the Windows platform and you 
are adding an extra condition to prevent that
without harming the goal of JDK-4673406 to have it enabled and 
functional when invoked by
java.awt.PrinterJob attached to a Windows printer. That is much more 
important than the

bug being fixed here so I'd like definite confirmation of that.
Also since it is an *extra* condition may I assume we do not enable this 
for a PrinterJob

on mac or linux - the functionality was windows only.

I think the test should not fail if the button is enabled. It should 
fail only if

the button is enabled *and does nothing*.

-phil.

On 7/20/20, 8:15 AM, Prasanta Sadhukhan wrote:


Actually, I was a bit wrong in construing that the button should just 
be disabled for ServiceUI.printDialog if ServiceUIFactory is null & 
getUI(MAIN_ROLE...) is null.


The "properties" dialog is used for another use-case which is for 
cross-platform dialog also ie, when we have a printer job created 
using (in which case also getUI() will be null for windows)


PrintRequestAttributeSet pSet =newHashPrintRequestAttributeSet();
pSet.add(DialogTypeSelection.COMMON);
pj.printDialog(pSet);

And, as per JDK-4673406, it  is likely that supporting this 
/"properties" sheet will only be possible where there is already a job 
with which//
//to make the association. ie using 
java.awt.PrinterJob.printDialog(AttributeSet) and not for direct uses 
with javax.print.ServiceUI.printDialog(..)/"


So, ideally, we should be checking if we have a printer job in 
addition to ServiceUIFactory being not null to allow creation of 
association between printer properties and the printer job
so if a PrinterJob cross-platform printer-dialog is created, then we 
should support "Properties" dialog.
If we directly use javax.print.ServiceUI.printDialog(..), then in that 
case no printer job will be created, so properties dialog can be 
disabled for that use-case.


Modified webrev: http://cr.openjdk.java.net/~psadhukhan/8246742/webrev.1/

Regards
Prasanta
On 20-Jul-20 3:53 PM, Jayathirth D v wrote:

Hi Prasanta,

Is just checking for dialog is null fine or we also need to verify 
DocumentProptiesUI in our case? As done in else case when dialog is 
null at 
http://hg.openjdk.java.net/jdk/client/file/fabf11c3a8ca/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l801 ?


I also see that Win32ServiceUIFactory
.getUI() doesnt return null in some specific DocumentsPropertyUI at 
http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/windows/classes/sun/print/Win32PrintService.java#l1692 



Thanks,
Jay

On 17-Jul-2020, at 11:22 AM, Prasanta Sadhukhan 
> wrote:


Hi Jay,

I am using the same methodology used to determine whether to show 
the properties dialog when button-clicked on it (which is not to 
show if dialog is null) as per


http://hg.openjdk.java.net/jdk/client/file/fabf11c3a8ca/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l793

So, if we cannot show the dialog using that mechanism, we can 
enable/disable the button itself beforehand using that check.


Regards
Prasanta.
On 16-Jul-20 9:26 PM, Jayathirth D v wrote:

Hi Prasanta,

I tested the fix in Mac and Windows and it works as mentioned.

In 
http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/windows/classes/sun/print/Win32PrintService.java#l1688 we 
are returning null when “role <= ServiceUIFactory.MAIN_UIROLE”. So 
it covers 3 roles “MAIN_UIROLE”, “ADMIN_UIROLE” and “ABOUT_UIROLE”.


In your webrev we are checking only for “MAIN_UIROLE”. Is creation 
of “JDIALOG_UI” restricted only to “MAIN_UIROLE”?


Thanks,
Jay

On 15-Jul-2020, at 6:27 PM, Prasanta Sadhukhan 
> wrote:


Any reviewer for this?

On 09-Jul-20 1:10 PM, Prasanta Sadhukhan wrote:


Hi All,

Please review a fix for an issue where "Properties" button in 
ServiceUI.printDialog is enabled in windows but clicking it 
doesn't show any dialog.


According to JDK-4673406 
, the 
properties dialog isn't supported for direct uses with 
javax.print.ServiceUI.printDialog, so it makes sense to disable 
this properies button for this usecase.


This button is disabled in linux,mac already. This is because, as per

http://hg.openjdk.java.net/jdk/client/annotate/754ec520eb4a/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l964

the button is disabled if ServiceUIFactory is null and for 
linux/mac, it is null


http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1637
http://hg.openjdk.java.net/jdk/client/file/754ec520eb4a/src/java.desktop/share/classes/sun/print/PSStreamPrintService.java#l490 



but for windows, it created "Win32ServiceUIFactory" but it does 
not handle the properties dialog if "role" 

Re: [OpenJDK 2D-Dev] RFR: 8249821: Separate libharfbuzz from libfontmanager

[Philip Race]

Hi,

I noticed the indent problems at 434 & 436 myself once I looked at it as 
a webrev,
so I was already updating the fix with those but I've also fixed the 
rest you pointed out.

I've uploaded a new webrev with all of these resolved :-

http://cr.openjdk.java.net/~prr/8249821.1

-phil

On 7/21/20, 3:03 PM, Erik Joelsson wrote:

Hello Phil,

This looks pretty good, only some style nits.

Awt2dLibraries.gmk

428 and 466: These comments aren't relevant anymore now that harfbuzz 
is its own library.


434: Missed indent of 2

436: Too much indent (should be 2)

459-464: Too much indent

493-494: Too much indent

/Erik

On 2020-07-21 14:39, Philip Race wrote:

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

This fix breaks out libharfbuzz from libfontmanager.
As well as building I've done extensive testing on all platforms.

I have tweaked the disabled warnings so we don't have un-needed 
duplication

but it is not a goal of this fix to resolve them.
There's a bug (JDK-8074844) already filed to resolve them for 
fontmanager and

that should be easier to fix now.

-phil.

[OpenJDK 2D-Dev] RFR: 8249821: Separate libharfbuzz from libfontmanager

[Philip Race]

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

This fix breaks out libharfbuzz from libfontmanager.
As well as building I've done extensive testing on all platforms.

I have tweaked the disabled warnings so we don't have un-needed duplication
but it is not a goal of this fix to resolve them.
There's a bug (JDK-8074844) already filed to resolve them for 
fontmanager and

that should be easier to fix now.

-phil.

[OpenJDK 2D-Dev] RFR : 8249725 : testbug: ZeroWithStringBoundsTest.java needs update to copyright header.

[Philip Race]

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

The copyright header is missing "All Rights Reserved".
This causes a failure in validation builds so we need to fix ASAP.

diff
diff --git a/test/jdk/java/awt/FontClass/ZeroWidthStringBoundsTest.java 
b/test/jdk/java/awt/FontClass/ZeroWidthStringBoundsTest.java

--- a/test/jdk/java/awt/FontClass/ZeroWidthStringBoundsTest.java
+++ b/test/jdk/java/awt/FontClass/ZeroWidthStringBoundsTest.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2020, Oracle and/or its affiliates.
+ * Copyright (c) 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
@@ -23,7 +23,7 @@

 /*
  * @test
- * @bug 8245159
+ * @bug 8245159 8239725
  * @summary Ensure no exception getting bounds of an empty string when 
the font has

  * layout attributes.
  * @run main/othervm ZeroWidthStringBoundsTest

Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to FontUtilities.java

[Philip Race]

On 7/14/20, 8:43 AM, Langer, Christoph wrote:


This should probably also be pushed to the client repo.



That is not just "probably", it is a definite yes.

-phil.

Re: [OpenJDK 2D-Dev] Fwd: Re: RFR : 8248802: Add log helper methods to FontUtilities.java

[Philip Race]

That would I think also take care of some "technical debt" which
is on the to-do list since I want to remove all unnecessary usage
of java.base internals.

-phil.

On 7/14/20, 8:39 AM, Daniel Fuchs wrote:

Hi Christoph,

Sorry - I'm not on 2d-dev - so please include me in cc: if you
reply to this mail. Also my apologies if I don't have the full
context of this discussion.

> Unfortunately, PlatformLogger does not (yet?) offer public logging
> methods taking suppliers.

I would suggest using System.Logger directly instead.
PlatformLogger delegates to System.Logger behind the scene,
and System.Logger has APIs that take suppliers:

https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/System.Logger.html 



best regards

-- daniel

On 14/07/2020 16:03, Roger Riggs wrote:

 Forwarded Message 
Subject: Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper 
methods to FontUtilities.java

Date: Tue, 14 Jul 2020 14:22:50 +
From: Langer, Christoph 
To: Philip Race , Baesken, Matthias 

CC: Peter Hull , Jayathirth D v 
, 2d-dev@openjdk.java.net 
<2d-dev@openjdk.java.net>




Hi,

I guess it would make sense to offer logging methods that take a 
supplier as input. That way we could pass String concatenations as 
Lambdas that only evaluate when actually calling the logging.


Unfortunately, PlatformLogger does not (yet?) offer public logging 
methods taking suppliers. Those should, however, be easy to 
implement, leveraging already existing signatures of the logging 
Bridge such as here: 
https://github.com/openjdk/jdk/blob/195c45a0e11207e15c277e7671b2a82b8077c5fb/src/java.base/share/classes/sun/util/logging/PlatformLogger.java#L210


Furthermore, initialization of logging in FontUtilities looks a bit 
awkward. I think the if (debugFonts) in line 117 is unnecessary and 
the code of that block could be added to the block before (of line 
107: if (debugLevel != null && !debugLevel.equals("false"))). And you 
could also remove the following imports there (line 29ff):


import java.io.BufferedReader;

import java.io.File;

import java.io.FileInputStream;

import java.io.InputStreamReader;

Best regards

Christoph

Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to FontUtilities.java

[Philip Race]

That is a good question. I am not sure any more how we ended up with
the mixed usage but isLogging() seems appropriate to guard the call to log.

So maybe make them consistent for all cases that make sense.

If the end result of that is there is no other usage that calls debugFonts()
that might be something else to take a look if it is basically synonomous.

BTW I suppose you believe you have found all the cases in various packages
and platform folders and converted them ?
Or were there some cases you intentionally left alone ?

Not saying you missed any - just want to know what to expect when I go 
checking.


-phil.

On 7/10/20, 12:34 AM, Baesken, Matthias wrote:


Hi Phil, okay get  your point , thanks for clarification about  
avoiding  the string concatenation if FontUtilities.isLogging()  
returns false .


But I guess the  coding  guarded  by FontUtilities.debugFonts()   for 
example :


src/java.desktop/share/classes/sun/awt/FontConfiguration.java-85-
if (FontUtilities.debugFonts()) {


src/java.desktop/share/classes/sun/awt/FontConfiguration.java:86:
FontUtilities.getLogger()


src/java.desktop/share/classes/sun/awt/FontConfiguration.java-87-
.info("Creating standard Font Configuration");


would continue using  FontUtilities.debugFonts(),   correct ?

So this would change to :

src/java.desktop/share/classes/sun/awt/FontConfiguration.java-85-
if (FontUtilities.debugFonts()) {


src/java.desktop/share/classes/sun/awt/FontConfiguration.java:86:
FontUtilities.logInfo("Creating standard Font Configuration");


Best regards, Matthias

*From:*Philip Race 
*Sent:* Donnerstag, 9. Juli 2020 19:17
*To:* Baesken, Matthias 
*Cc:* Peter Hull ; Jayathirth D v 
; Langer, Christoph 
; 2d-dev@openjdk.java.net
*Subject:* Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods 
to FontUtilities.java



There is no harm in repeating isLogging() inside logWarning() but
I don't think it is sufficient.

What we mean is that in some cases the code looks now like this :-

http://cr.openjdk.java.net/~mbaesken/webrevs/8248802.0/src/java.desktop/share/classes/sun/font/FileFontStrike.java.udiff.html 
<http://cr.openjdk.java.net/%7Embaesken/webrevs/8248802.0/src/java.desktop/share/classes/sun/font/FileFontStrike.java.udiff.html>


-if (FontUtilities.isLogging()) {
-FontUtilities.getLogger().warning(
-"Failed to render glyph using GDI: code=" + glyphCode
+FontUtilities.logWarning("Failed to render glyph using GDI: code=" 
+ glyphCode
  + ", fontFamily=" + family + ", style=" + 
style
  + ", size=" + size);
-}


So all that string concatenation always happens, even if we don't log.

The code before probably wasn't 100% consistent but if updating it
then I suggest to make it 100% consistent to always check isLogging()
before calling logWarning().

I suggest to do it even in cases like this
http://cr.openjdk.java.net/~mbaesken/webrevs/8248802.0/src/java.desktop/share/classes/sun/font/CMap.java.udiff.html 
<http://cr.openjdk.java.net/%7Embaesken/webrevs/8248802.0/src/java.desktop/share/classes/sun/font/CMap.java.udiff.html>



+FontUtilities.logWarning("Cmap UVS subtable overflows 
buffer.");


where there is no concatenation work happening, just to establish a
consistent pattern.


-phil.

On 7/9/20, 8:07 AM, Baesken, Matthias wrote:

  


There always should be a call such as FontUtilities.isLogging() test

protecting doing unnecessary work.

  


Hi,  in my patch I always  call  isLogging()  in the new methods in

  



http://cr.openjdk.java.net/~mbaesken/webrevs/8248802.0/src/java.desktop/share/classes/sun/font/FontUtilities.java.frames.html
  
<http://cr.openjdk.java.net/%7Embaesken/webrevs/8248802.0/src/java.desktop/share/classes/sun/font/FontUtilities.java.frames.html>

  


So are you talking about other places in the coding ?

  


    Best regards, Matthias

  

  

  


-Original Message-

From: Philip Race  <mailto:philip.r...@oracle.com>  


Sent: Donnerstag, 9. Juli 2020 17:04

To: Peter Hull  <mailto:peterhul...@gmail.com>

Cc: Baesken, Matthias  <mailto:matthias.baes...@sap.com>; Jayathirth D 
v  <mailto:jayathirth@oracle.com>; Langer, 
Christoph  <mailto:christoph.lan...@sap.com>;2d-dev@openjdk.java.net  
<mailto:2d-dev@openjdk.java.net>

Subject: Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to 
FontUtilities.java

  


I agree.

  


There always should be a call such as FontUtilities.isLogging() test

protecting doing unnecessary work.

  

  


-phil.

  


On 7/9/20, 3:24 AM, Peter Hull wrote:

Proba

[OpenJDK 2D-Dev] EA3 build of Project Lanai (Metal rendering pipeline for macOS) is now posted.

[Philip Race]

https://jdk.java.net/lanai/ is now hosting the EA 3 build of Lanai

This is now JDK16 based since JDK 15 forked for stabilisation.


   Build 16-lanai+1-11 (2020/7/3)


new bugs fixed
#

8242950: Files which can't be selected has different color with metal 
than opengl in JFileChooser 

# 8247772: Lanai: Several jtreg tests fails with assertion 
validateTextureDimensions: 759: failed assertion 'MTLTextureDescriptor 
has width greater than maximum allowed size of 16384' 

# 8248301: Lanai - Change MTLStorageMode of MTLSurfaceData texture (render 
backbuffer) to private 


-phil

Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to FontUtilities.java

[Philip Race]

I agree.

There always should be a call such as FontUtilities.isLogging() test
protecting doing unnecessary work.


-phil.

On 7/9/20, 3:24 AM, Peter Hull wrote:

Probably not my place to comment, but, does it matter that it's doing
unnecessary work evaluating the argument to logWarning et al, in the
case where logging is not enabled? It only seems to be string
concatenation and maybe would be optimised out anyway, I don't know.
Peter

On Thu, 9 Jul 2020 at 08:32, Baesken, Matthias  wrote:

Thank‘s  for the review !

May I get a second  review ?





Best regards, Matthias







From: Jayathirth D v
Sent: Donnerstag, 9. Juli 2020 07:21
To: Baesken, Matthias
Cc: 2d-dev@openjdk.java.net
Subject: Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to 
FontUtilities.java



Looks good to me.



Thanks,

Jay



On 06-Jul-2020, at 12:43 PM, Baesken, Matthias  wrote:



Hello, please review this small change to font related logging .



We have a lot of font logging calls in java.desktop that look similar to this 
coding :

 if (FontUtilities.isLogging()) {
 FontUtilities.getLogger().info("Here comes my important info");
 }

This coding could be simplified by adding static log methods to 
FontUtilities.java



public static void logWarning(String s);

public static void logInfo(String s);

public static void logSevere(String s);



   doing the isLogging check + FontUtilities.getLogger(). …







Bug/webrev :



https://bugs.openjdk.java.net/browse/JDK-8248802



http://cr.openjdk.java.net/~mbaesken/webrevs/8248802.0/





Thanks, Matthias

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

For the record, Microsoft have no published a KB article acknowledging 
the problem:-


https://support.microsoft.com/en-us/help/4567569/gdi-apis-may-fail-when-large-pages-or-vad-spanning-is-used


-phil.



On 6/11/20, 9:12 PM, Jayathirth D v wrote:

+1.

Thanks,
Jay

On 12-Jun-2020, at 12:16 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:



one more update to the tests
cr.openjdk.java.net/~prr/8240654.2/ 
<http://cr.openjdk.java.net/%7Eprr/8240654.2/>


I added
@requires vm.gc.Z per the VM folks, ZGC needs Windows Server 2019 or 
the same vintage Window 10. if run on Windows Server 2016

ZGC errors out. This should prevent that. -phil.
On 6/11/2020 11:13 AM, Kevin Rushforth wrote:

+1

The updated LargeWindowPaintTest fails for me without the fix 
without my having to manually set uiScale. It passes with the fix.


Interestingly enough, I finally saw the problem that Jay reported 
with AlphaPrintTest: without the fix I initially get a blank (all 
white) window. If I resize it then it is drawn. With the fix 
everything is fine.


-- Kevin

On 6/11/2020 10:48 AM, Philip Race wrote:

Updated webrev here

http://cr.openjdk.java.net/~prr/8240654.1/index.html

The only changes are to the tests - to add -Dsun.java2d.uiScale=1 
to the onscreen test

and to add printer to the keys for the printing test.

It was pointed out by Stefan from the ZGC team that the changes in 
awt_TrayIcon.cpp and awt_Cursor.cpp
should not be needed because the GDI code in Create_BMP that 
ultimately consumes the data
has processed and copied it into memory allocated by 
CreateDIBSection before passing it to
CreateBitmap. I considered reverting those two files but decided to 
keep them because I
think I would like this fix anyway. We really don't need to lock 
down the VM in these cases.


-phil.


On 6/11/20, 9:55 AM, Philip Race wrote:
I have confirmed hit a different code path. It goes through 
generic 2D s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in 
sun/java2d/pipe/DrawImage.java ends up in

scaleSurfaceData which uses the loops in ScaledBlit.c.

It is a bit surprising to me since I'd expect us to be able to 
blit directly at device resolution.
Could we also be taking a performance hit here ? The D3D case 
doesn't not go through this loop.


However all that is outside the scope of this fix ... I think 
setting uiScale=1 in the test is all that needs to be done.


-phil.

On 6/11/2020 7:51 AM, Philip Race wrote:

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to 
see the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and 
without this property passes because you have
a hidpi setup. And to see the failure without the fix you needed 
the above property.
If so we could just be looking at a similar anomaly as I saw 
with printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing 
uiScale=1 does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger 
memory footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
<mailto:kevin.rushfo...@oracle.com>> wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you 
print before saying whether it passes or not. FWIW, I verified 
that the printing test on my system was hitting the fallback 
code with the patch, but it seemed to print correctly even 
without the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
<mailto:jayathirth@oracle.com>> wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame 
without any instructions and with fix it shows instructions 
for the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I 
click on Pass(Since I don’t have printer right now) 
it doesn’t pass/close the window. Only after I click on 
Print button and then close print dialog it allows me to 
click on Pass button.


Also how does these tests behave in our internal CI machines?

Thanks,
Jay

On 11-Jun-2020, at 2:18 AM

[OpenJDK 2D-Dev] RFR [JDK15] : 8244818 : Java2D Queue Flusher crash while moving application window to external monitor

[Philip Race]

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

Please review this fix for JDK 15 :

This crash was reported recently but we'd not been able to reproduce it 
until we used Xcode 11.3 to build,

in which case it became 100% reproducible.
The call that causes the crash, setting a scratch surface as NSView on 
the new current context,
is believed to be violating threading rules as it is not being done on 
the Appkit thread, hence the crash

however it also appears to be completely unnecessary.
Removing causes no problems that we can find. J2Demo, SwingSet, 
multimon, all headful automated

regression and JCK tests pass.  So the fix is just to remove the call.
There's no regression test since you need a multi-mon setup to see the 
crash and we've not seen
any other scenario causing a crash - dragging between monitors is the 
main reason this code gets entered.
I've seen it called when a new window or dialog is displayed but that 
doesn't cause a crash and

we have plenty of tests that open windows anyway :-)


-phil.

[OpenJDK 2D-Dev] EA2 build of Project Lanai (Metal rendering pipeline for macOS) is now posted.

[Philip Race]

Hi all,

https://jdk.java.net/lanai/ is now hosting the EA 2 build of Lanai


   Build 15-lanai+1-157 (2020/6/12)

EA 2 contains the following new bug fixes relative to EA 1.

 * 8247464: Memory Leak in MTLBlitLoops_CopyArea() method
   
 * 8247304: Use separate MTLCommandQueue for final blit and MTLDrawable
   
 * 8246495: Lanai: update AA clip info on GPU via compute shader
   
 * 8246454: Lanai: Create RenderPerf tests for rectangular and shape
   clips 
 * 8242952: fixed MTLBlitLoops::replaceTextureRegion (add correct
   offset 
 * 8242354: support for bufImgOps (RescaleOp, LookupOp, ConvolveOp)
   
 * 8246331: Lanai: do not update AA clip info in nonAA mode
   
 * 8246239: Revert JDK-8244193 as it causes performance regression
   

-phil

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Philip Race]

Kim,


Until it says in "the JDK" and not "in HotSpot" you have not addressed 
my main point.

Please rename the JEP.

-phil.

On 6/13/20, 8:48 PM, Kim Barrett wrote:

On Jun 10, 2020, at 2:26 AM, Kim Barrett  wrote:


On Jun 8, 2020, at 4:07 PM, Philip Race  wrote:
BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says

For Solaris: Add the -std=c++14 compiler option. .

So I am sure there is still some room to update the JEP :-)

Yeah, I have some updates to make.  I also need to do a bit of work on the 
feature lists.

I think the JEP updates are done now.

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

BitBlt is not on the list of affected APIs provided by Microsoft.
And it is the JDK blit loop that copies from the Java heap memory into a
Windows bitmap buffer, so I don't see it being affected.
The BitBlt to the windows surface then operates on that windows 
allocated buffer.


-phil.

On 6/11/20, 2:47 PM, Sergey Bylokhov wrote:

And if -Dsun.java2d.uiScale is set to "2" it will use the normal Blit.

It looks like the ScaledBlit uses "direct" access to the gdi surface.
ScaledBlit reads content of the GDIWindowSurfaceData in the 
GDIWinSD_GetRasInfo and write it back in the
GDIWinSD_Unlock via BitBlt. Not sure this code might be affected by 
this bug or not.


BTW I just realized that the test depends on the blit of Swing 
backbuffer to the window,

it does not force usage of "memory->GDI" blit by itself.

On 6/11/20 12:05 pm, Philip Race wrote:

You can see the difference here from turning on tracing :-

$ jdk-client/build/windows-x64/jdk/bin/java -Dsun.java2d.d3d=false 
-Dsun.java2d.uiScale=1.1 -Dsun.java2d.trace=log -XX:+UseZGC 
LargeWindowPaintTest


sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)

sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, 
SrcNoEa, AnyInt)

sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb)
java.awt.Rectangle[x=0,y=0,width=1746,height=925]


$ jdk-client/build/windows-x64/jdk/bin/java -Dsun.java2d.d3d=false 
-Dsun.java2d.uiScale=1 -Dsun.java2d.trace=log -XX:+UseZGC 
LargeWindowPaintTest


sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, "GDI")
java.awt.Rectangle[x=0,y=0,width=1920,height=1017]

-phil

On 6/11/2020 11:35 AM, Sergey Bylokhov wrote:

On 6/11/20 9:55 am, Philip Race wrote:
I have confirmed hit a different code path. It goes through generic 
2D s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in 
sun/java2d/pipe/DrawImage.java ends up in

scaleSurfaceData which uses the loops in ScaledBlit.c.


But as far as I understand we somehow should use gdiblits at the end,
because only these blits can draw something on the screen when GDI 
is enabled(or not???).

So it is unclear why the GDIBlitLoops are not used in the HiDPI mode.



It is a bit surprising to me since I'd expect us to be able to blit 
directly at device resolution.
Could we also be taking a performance hit here ? The D3D case 
doesn't not go through this loop.


However all that is outside the scope of this fix ... I think 
setting uiScale=1 in the test is all that needs to be done.


-phil.

On 6/11/2020 7:51 AM, Philip Race wrote:

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to 
see the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and 
without this property passes because you have
a hidpi setup. And to see the failure without the fix you needed 
the above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing 
uiScale=1 does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
<mailto:kevin.rushfo...@oracle.com>> wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you 
print before saying whether it passes or not. FWIW, I verified 
that the printing test on my s

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

You can see the difference here from turning on tracing :-

$ jdk-client/build/windows-x64/jdk/bin/java -Dsun.java2d.d3d=false 
-Dsun.java2d.uiScale=1.1 -Dsun.java2d.trace=log -XX:+UseZGC 
LargeWindowPaintTest


sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)

sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)
sun.java2d.loops.FillParallelogram::FillParallelogram(AnyColor, SrcNoEa, 
AnyInt)

sun.java2d.loops.ScaledBlit::ScaledBlit(IntRgb, SrcNoEa, IntRgb)
java.awt.Rectangle[x=0,y=0,width=1746,height=925]


$ jdk-client/build/windows-x64/jdk/bin/java -Dsun.java2d.d3d=false 
-Dsun.java2d.uiScale=1 -Dsun.java2d.trace=log -XX:+UseZGC 
LargeWindowPaintTest


sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.loops.FillRect::FillRect(AnyColor, SrcNoEa, AnyInt)
sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, "GDI")
java.awt.Rectangle[x=0,y=0,width=1920,height=1017]

-phil

On 6/11/2020 11:35 AM, Sergey Bylokhov wrote:

On 6/11/20 9:55 am, Philip Race wrote:
I have confirmed hit a different code path. It goes through generic 
2D s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in 
sun/java2d/pipe/DrawImage.java ends up in

scaleSurfaceData which uses the loops in ScaledBlit.c.


But as far as I understand we somehow should use gdiblits at the end,
because only these blits can draw something on the screen when GDI is 
enabled(or not???).

So it is unclear why the GDIBlitLoops are not used in the HiDPI mode.



It is a bit surprising to me since I'd expect us to be able to blit 
directly at device resolution.
Could we also be taking a performance hit here ? The D3D case doesn't 
not go through this loop.


However all that is outside the scope of this fix ... I think setting 
uiScale=1 in the test is all that needs to be done.


-phil.

On 6/11/2020 7:51 AM, Philip Race wrote:

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to 
see the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and 
without this property passes because you have
a hidpi setup. And to see the failure without the fix you needed 
the above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing uiScale=1 
does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> 
wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you print 
before saying whether it passes or not. FWIW, I verified that the 
printing test on my system was hitting the fallback code with the 
patch, but it seemed to print correctly even without the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
mailto:jayathirth@oracle.com>> 
wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame 
without any instructions and with fix it shows instructions for 
the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I 
click on Pass(Since I don’t have printer right now) it doesn’t 
pass/close the window. Only after I click on Print button and 
then close print dialog it allows me to click on Pass button.


Als

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

one more update to the tests
cr.openjdk.java.net/~prr/8240654.2/

I added
@requires vm.gc.Z per the VM folks, ZGC needs Windows Server 2019 or the 
same vintage Window 10. if run on Windows Server 2016

ZGC errors out. This should prevent that. -phil.
On 6/11/2020 11:13 AM, Kevin Rushforth wrote:

+1

The updated LargeWindowPaintTest fails for me without the fix without 
my having to manually set uiScale. It passes with the fix.


Interestingly enough, I finally saw the problem that Jay reported with 
AlphaPrintTest: without the fix I initially get a blank (all white) 
window. If I resize it then it is drawn. With the fix everything is fine.


-- Kevin

On 6/11/2020 10:48 AM, Philip Race wrote:

Updated webrev here

http://cr.openjdk.java.net/~prr/8240654.1/index.html

The only changes are to the tests - to add -Dsun.java2d.uiScale=1 to 
the onscreen test

and to add printer to the keys for the printing test.

It was pointed out by Stefan from the ZGC team that the changes in 
awt_TrayIcon.cpp and awt_Cursor.cpp
should not be needed because the GDI code in Create_BMP that 
ultimately consumes the data
has processed and copied it into memory allocated by CreateDIBSection 
before passing it to
CreateBitmap. I considered reverting those two files but decided to 
keep them because I
think I would like this fix anyway. We really don't need to lock down 
the VM in these cases.


-phil.


On 6/11/20, 9:55 AM, Philip Race wrote:
I have confirmed hit a different code path. It goes through generic 
2D s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in 
sun/java2d/pipe/DrawImage.java ends up in

scaleSurfaceData which uses the loops in ScaledBlit.c.

It is a bit surprising to me since I'd expect us to be able to blit 
directly at device resolution.
Could we also be taking a performance hit here ? The D3D case 
doesn't not go through this loop.


However all that is outside the scope of this fix ... I think 
setting uiScale=1 in the test is all that needs to be done.


-phil.

On 6/11/2020 7:51 AM, Philip Race wrote:

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to 
see the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and 
without this property passes because you have
a hidpi setup. And to see the failure without the fix you needed 
the above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing 
uiScale=1 does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> 
wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you print 
before saying whether it passes or not. FWIW, I verified that 
the printing test on my system was hitting the fallback code 
with the patch, but it seemed to print correctly even without 
the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
mailto:jayathirth@oracle.com>> 
wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame 
without any instructions and with fix it shows instructions 
for the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I 
click on Pass(Since I don’t have printer right now) it doesn’t 
pass/close the window. Only after I click on Print button and 
then close print dialog it allows me to click on Pass button.


Also how does these tests behave in our internal CI machines?

Thanks,
Jay

On 11-Jun-2020, at 2:18 AM, Philip Race 
mailto:philip.r...@oracle.com>> wrote:


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

This is for JDK 15 so review ASAP please since RDP 1 and the 
test cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds 
for a Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/33

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

Updated webrev here

http://cr.openjdk.java.net/~prr/8240654.1/index.html

The only changes are to the tests - to add -Dsun.java2d.uiScale=1 to the 
onscreen test

and to add printer to the keys for the printing test.

It was pointed out by Stefan from the ZGC team that the changes in 
awt_TrayIcon.cpp and awt_Cursor.cpp
should not be needed because the GDI code in Create_BMP that ultimately 
consumes the data
has processed and copied it into memory allocated by CreateDIBSection 
before passing it to
CreateBitmap. I considered reverting those two files but decided to keep 
them because I
think I would like this fix anyway. We really don't need to lock down 
the VM in these cases.


-phil.


On 6/11/20, 9:55 AM, Philip Race wrote:
I have confirmed hit a different code path. It goes through generic 2D 
s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in 
sun/java2d/pipe/DrawImage.java ends up in

scaleSurfaceData which uses the loops in ScaledBlit.c.

It is a bit surprising to me since I'd expect us to be able to blit 
directly at device resolution.
Could we also be taking a performance hit here ? The D3D case doesn't 
not go through this loop.


However all that is outside the scope of this fix ... I think setting 
uiScale=1 in the test is all that needs to be done.


-phil.

On 6/11/2020 7:51 AM, Philip Race wrote:

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see 
the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and 
without this property passes because you have
a hidpi setup. And to see the failure without the fix you needed the 
above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing uiScale=1 
does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> 
wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you print 
before saying whether it passes or not. FWIW, I verified that the 
printing test on my system was hitting the fallback code with the 
patch, but it seemed to print correctly even without the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
mailto:jayathirth@oracle.com>> 
wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame 
without any instructions and with fix it shows instructions for 
the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I 
click on Pass(Since I don’t have printer right now) it doesn’t 
pass/close the window. Only after I click on Print button and 
then close print dialog it allows me to click on Pass button.


Also how does these tests behave in our internal CI machines?

Thanks,
Jay

On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:


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

This is for JDK 15 so review ASAP please since RDP 1 and the 
test cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds 
for a Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first 
the technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 
2Mb chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a 
failure code (ie fail!)
This typically occurs when Java heap memory is used for a Java 
image and then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap 
allocated memory is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the 
window is of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, 
bec

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

I have confirmed hit a different code path. It goes through generic 2D 
s/w loops in this case.
ie we don't use GDIBlitLoops at all. The code in 
sun/java2d/pipe/DrawImage.java ends up in

scaleSurfaceData which uses the loops in ScaledBlit.c.

It is a bit surprising to me since I'd expect us to be able to blit 
directly at device resolution.
Could we also be taking a performance hit here ? The D3D case doesn't 
not go through this loop.


However all that is outside the scope of this fix ... I think setting 
uiScale=1 in the test is all that needs to be done.


-phil.

On 6/11/2020 7:51 AM, Philip Race wrote:

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see 
the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and without 
this property passes because you have
a hidpi setup. And to see the failure without the fix you needed the 
above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing uiScale=1 
does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you print 
before saying whether it passes or not. FWIW, I verified that the 
printing test on my system was hitting the fallback code with the 
patch, but it seemed to print correctly even without the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
mailto:jayathirth@oracle.com>> wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame without 
any instructions and with fix it shows instructions for the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I 
click on Pass(Since I don’t have printer right now) it doesn’t 
pass/close the window. Only after I click on Print button and 
then close print dialog it allows me to click on Pass button.


Also how does these tests behave in our internal CI machines?

Thanks,
Jay

On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:


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

This is for JDK 15 so review ASAP please since RDP 1 and the 
test cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds 
for a Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first 
the technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 
2Mb chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a 
failure code (ie fail!)
This typically occurs when Java heap memory is used for a Java 
image and then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap 
allocated memory is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the 
window is of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, 
because the D3D pipeline doesn't
call the affected method but if you have an Intel chip as do 90% 
(?) of laptops you will see it.
There are also several other places we found that are affected. 
Printing is the other one
somewhat easy to trigger. The others : custom cursors and tray 
icons are less common.
The painful thing here is that there is no definitive list (a 
list of the known ones is below) of
affected Windows GDI APIs and we are just hunting around our 
code trying to see where it

might be side-swiped by this bug.

The basic approach in these workarounds is that for cases where 
performance does not matter we now copy
and for cases where performance does matter or larger amounts of 
memory is involved we check if
the ret

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

Blitting a full screen window for me (slightly under 1920x1080) is a 
little under 3 ms.


With no need to copy / retry it is a just around 1 ms which I am not 
sure whether to trust completely.

On another machine with a finer grained timer it was > 1 ms.

-phil.

On 6/10/2020 6:50 PM, Sergey Bylokhov wrote:

+1

Just curious about what performance degradation we will have in the 
worst case.


On 6/10/20 3:57 pm, Kevin Rushforth wrote:

+1

Code changes look good.

I verified that the bug happens on my Windows 10 laptop with 
SwingSet2 and with the LargeWindowPaintTest without the patch, and 
everything looks good with the patch.


-- Kevin


On 6/10/2020 1:48 PM, Philip Race wrote:

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

This is for JDK 15 so review ASAP please since RDP 1 and the test 
cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds for a 
Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first the 
technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 2Mb 
chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a failure 
code (ie fail!)
This typically occurs when Java heap memory is used for a Java image 
and then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap allocated 
memory is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the window 
is of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, 
because the D3D pipeline doesn't
call the affected method but if you have an Intel chip as do 90% (?) 
of laptops you will see it.
There are also several other places we found that are affected. 
Printing is the other one
somewhat easy to trigger. The others : custom cursors and tray icons 
are less common.
The painful thing here is that there is no definitive list (a list 
of the known ones is below) of
affected Windows GDI APIs and we are just hunting around our code 
trying to see where it

might be side-swiped by this bug.

The basic approach in these workarounds is that for cases where 
performance does not matter we now copy
and for cases where performance does matter or larger amounts of 
memory is involved we check if
the return value of the GDI function indicates failure and then 
re-try with a copy of the heap memory.
Unless GDI was randomly failing already (unlikely) this should be a 
no-risk solution in the high profile cases.
We have done performance measurements on the important screen case 
and the failures
happen fast so the penalty is then in the re-try which is only if 
ZGC is enabled.
Always copying the memory is slower (and memcpy is the slow 
operation) than an alternative approach
that "knows" about the memory allocation of ZGC but this coupling 
and the complexity seem like they aren't
worth it since I haven't seen any visible performance consequence. 
That can be revisited
some day if need be, but for now we have correctness which is the 
key as well as sufficient performance.


I've created an automated test for the most important on-screen case.
Also a manual printing test case which invokes ZGC is provided since 
there we also only
conditionally copy. In the other cases we now always copy so 
existing test cases should over those.


There is some clean up in this fix - one completely unused (provably 
so because it was #if'd out)
JNI method in awt_PrintJob.cpp is removed since it had code that 
looked like it needed a workaround,

which would be somewhat of a waste of effort.

the doPrintBand code and its callee bitsToDevice has code I think we 
can remove too since
I don't see how it ever gets executed (the top down case for 
browserPrint == true) but
I think I'll save that for a P4 follow-on since it does nothing that 
would be affected by this

Windows bug.

One oddity is the in the printing case I observed that some times 
the rendering is performed
even if an error code is returned. I don't know why, but in code we 
can't tell that it was actually
rendered and in any case there is no harm in repeating the call with 
copied memory.


We are right before the JDK15 stabilisation fork and this fix needs 
to go there and will
but the webrev is against jdk/client simply because jdk15 does not 
exist yet !


Please test and review ASAP.

About the bug:
Microsoft has acknowleged the bug and will publish a knowledge base 
article about it
but a fix may show up only in a future version of Windows. Not, it 
seems, any time soon.
Below is a list of potentially affected GDI APIs. Per microsoft 
whether it actually manifests in

any specific case depends on "branching"

https://docs.microsoft.com/en-us/previous-versions/windows/desk

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

Or, maybe we hit a different code path. I'll check that.
uiScale=1 is the way to ensure we hit this code path.

-phil.

On 6/11/20, 7:44 AM, Philip Race wrote:

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see 
the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and without 
this property passes because you have
a hidpi setup. And to see the failure without the fix you needed the 
above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing uiScale=1 
does the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you print 
before saying whether it passes or not. FWIW, I verified that the 
printing test on my system was hitting the fallback code with the 
patch, but it seemed to print correctly even without the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
mailto:jayathirth@oracle.com>> wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame without 
any instructions and with fix it shows instructions for the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I click 
on Pass(Since I don’t have printer right now) it doesn’t 
pass/close the window. Only after I click on Print button and then 
close print dialog it allows me to click on Pass button.


Also how does these tests behave in our internal CI machines?

Thanks,
Jay

On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:


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

This is for JDK 15 so review ASAP please since RDP 1 and the test 
cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds for 
a Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first 
the technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 
2Mb chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a 
failure code (ie fail!)
This typically occurs when Java heap memory is used for a Java 
image and then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap allocated 
memory is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the 
window is of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, 
because the D3D pipeline doesn't
call the affected method but if you have an Intel chip as do 90% 
(?) of laptops you will see it.
There are also several other places we found that are affected. 
Printing is the other one
somewhat easy to trigger. The others : custom cursors and tray 
icons are less common.
The painful thing here is that there is no definitive list (a 
list of the known ones is below) of
affected Windows GDI APIs and we are just hunting around our code 
trying to see where it

might be side-swiped by this bug.

The basic approach in these workarounds is that for cases where 
performance does not matter we now copy
and for cases where performance does matter or larger amounts of 
memory is involved we check if
the return value of the GDI function indicates failure and then 
re-try with a copy of the heap memory.
Unless GDI was randomly failing already (unlikely) this should be 
a no-risk solution in the high profile cases.
We have done performance measurements on the important screen 
case and the failures
happen fast so the penalty is then in the re-try which is only if 
ZGC is enabled.
Always copying the memory is slower (and memcpy is the slow 
operation) than an alternative approach
that "knows" about the memory allocation of ZGC but this coupling 
and the complexity seem like they aren't
worth it since I ha

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

Can I get clarification here.

> I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see 
the failure with LargeWindowPaintTest.


So you both mean a JDK 15 promoted build without this fix and without 
this property passes because you have
a hidpi setup. And to see the failure without the fix you needed the 
above property.
If so we could just be looking at a similar anomaly as I saw with 
printing which uses a very large

image - it reported failure but actually worked !

Also - for both of you - with the fix and without forcing uiScale=1 does 
the test pass ?


-phil.

On 6/11/20, 7:10 AM, Jayathirth D v wrote:

Yes my machine was at 150% scaling.

If I force uiScale = 1, I see that:
LargeWindowPaintTest fails without patch and passes with patch.
AlphaPrintTest shows instructions without patch also.

@Phil : I think its better if we test at uiScale=1(larger memory 
footprint). Please clarify.


Thanks,
Jay

On 11-Jun-2020, at 5:53 PM, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Do you have a Hi-DPI machine? I do, and had to run with 
"-Dsun.java2d.uiScale=1" in order to see the failure with 
LargeWindowPaintTest.


For AlphaPrintTest, the test deliberately ensures that you print 
before saying whether it passes or not. FWIW, I verified that the 
printing test on my system was hitting the fallback code with the 
patch, but it seemed to print correctly even without the patch.


-- Kevin


On 6/11/2020 1:58 AM, Jayathirth D v wrote:

Typo : I tried tested -> I tried testing

On 11-Jun-2020, at 2:27 PM, Jayathirth D v 
mailto:jayathirth@oracle.com>> wrote:


Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel 
integrated UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame without 
any instructions and with fix it shows instructions for the test.

Is this expected behaviour?

AlphaPrintTest.java with fix when it shows instructions if I click 
on Pass(Since I don’t have printer right now) it doesn’t pass/close 
the window. Only after I click on Print button and then close print 
dialog it allows me to click on Pass button.


Also how does these tests behave in our internal CI machines?

Thanks,
Jay

On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:


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

This is for JDK 15 so review ASAP please since RDP 1 and the test 
cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds for 
a Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first the 
technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 
2Mb chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a failure 
code (ie fail!)
This typically occurs when Java heap memory is used for a Java 
image and then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap allocated 
memory is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the 
window is of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, 
because the D3D pipeline doesn't
call the affected method but if you have an Intel chip as do 90% 
(?) of laptops you will see it.
There are also several other places we found that are affected. 
Printing is the other one
somewhat easy to trigger. The others : custom cursors and tray 
icons are less common.
The painful thing here is that there is no definitive list (a list 
of the known ones is below) of
affected Windows GDI APIs and we are just hunting around our code 
trying to see where it

might be side-swiped by this bug.

The basic approach in these workarounds is that for cases where 
performance does not matter we now copy
and for cases where performance does matter or larger amounts of 
memory is involved we check if
the return value of the GDI function indicates failure and then 
re-try with a copy of the heap memory.
Unless GDI was randomly failing already (unlikely) this should be 
a no-risk solution in the high profile cases.
We have done performance measurements on the important screen case 
and the failures
happen fast so the penalty is then in the re-try which is only if 
ZGC is enabled.
Always copying the memory is slower (and memcpy is the slow 
operation) than an alternative approach
that "knows" about the memory allocation of ZGC but this coupling 
and the complexity seem like they aren't
worth it since I haven't seen any visible performance consequence. 
That can be revisited
some day if need be, but for now we have correctness which is the 
key as well as sufficient p

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

On 6/11/20, 1:57 AM, Jayathirth D v wrote:

Hi Phil,

I tried tested the fix in my Windows 10 machine with Intel integrated 
UHD Graphics 620.


LargeWindowPaintTest.java passes with/without fix in my machine.
AlphaPrintTest.java without fix just opens up blank frame without any 
instructions and with fix it shows instructions for the test.

Is this expected behaviour?


I guess this is a conseqeuence of the on-screen bug ! Which in contrast 
to the LargeWindowPaintTest affects you.


Without the fix the window is too big and you have an intel chip so you 
are going through the GDI path.


AlphaPrintTest.java with fix when it shows instructions if I click on 
Pass(Since I don’t have printer right now) it doesn’t pass/close the 
window. Only after I click on Print button and then close print dialog 
it allows me to click on Pass button.



Well .. perhaps I should add an @requires printer on this test ?
But can't you print to file using Windows built in print to pdf ?

Also how does these tests behave in our internal CI machines?

The printing one is manual so it is never going to pass there.

-phil


Thanks,
Jay

On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wrote:


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

This is for JDK 15 so review ASAP please since RDP 1 and the test 
cycle are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds for a 
Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first the 
technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 2Mb 
chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a failure 
code (ie fail!)
This typically occurs when Java heap memory is used for a Java image 
and then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap allocated 
memory is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the window 
is of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, because 
the D3D pipeline doesn't
call the affected method but if you have an Intel chip as do 90% (?) 
of laptops you will see it.
There are also several other places we found that are affected. 
Printing is the other one
somewhat easy to trigger. The others : custom cursors and tray icons 
are less common.
The painful thing here is that there is no definitive list (a list of 
the known ones is below) of
affected Windows GDI APIs and we are just hunting around our code 
trying to see where it

might be side-swiped by this bug.

The basic approach in these workarounds is that for cases where 
performance does not matter we now copy
and for cases where performance does matter or larger amounts of 
memory is involved we check if
the return value of the GDI function indicates failure and then 
re-try with a copy of the heap memory.
Unless GDI was randomly failing already (unlikely) this should be a 
no-risk solution in the high profile cases.
We have done performance measurements on the important screen case 
and the failures
happen fast so the penalty is then in the re-try which is only if ZGC 
is enabled.
Always copying the memory is slower (and memcpy is the slow 
operation) than an alternative approach
that "knows" about the memory allocation of ZGC but this coupling and 
the complexity seem like they aren't
worth it since I haven't seen any visible performance consequence. 
That can be revisited
some day if need be, but for now we have correctness which is the key 
as well as sufficient performance.


I've created an automated test for the most important on-screen case.
Also a manual printing test case which invokes ZGC is provided since 
there we also only
conditionally copy. In the other cases we now always copy so existing 
test cases should over those.


There is some clean up in this fix - one completely unused  (provably 
so because it was #if'd out)
JNI method in awt_PrintJob.cpp is removed since it had code that 
looked like it needed a workaround,

which would be somewhat of a waste of effort.

the doPrintBand code and its callee bitsToDevice has code I think we 
can remove too since
I don't see how it ever gets executed (the top down case for 
browserPrint == true) but
I think I'll save that for a P4 follow-on since it does nothing that 
would be affected by this

Windows bug.

One oddity is the in the printing case I observed that some times the 
rendering is performed
even if an error code is returned. I don't know why, but in code we 
can't tell that it was actually
rendered and in any case there is no harm in repeating the call with 
copied memory.


We are right before the JDK15 stabilisation fork and this fix needs 
to go there and 

[OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

[Philip Race]

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

This is for JDK 15 so review ASAP please since RDP 1 and the test cycle 
are looming.


This is not a fix for a JDK bug. It is a bunch of workarounds for a 
Microsoft Windows bug affecting

GDI in the context of ZGC (http://openjdk.java.net/jeps/333).
Some extra details about the Windows bug at the end, but first the 
technical details of the fix.


With ZGC's memory allocation requirement of reserving memory in 2Mb 
chunks  some Windows GDI
functions, mostly involving some bitmaps APIs may return a failure code 
(ie fail!)
This typically occurs when Java heap memory is used for a Java image and 
then in a JNI
call we use GetPrimitiveArrayCritical so that Java heap allocated memory 
is passed to a GDI

function AND the Java heap memory spans one of the 2Mb boundaries.
This is very easy to trigger in almost any Java UI app if the window is 
of a large enough (ie typical) size.
NB: if you have an Nvidia or ATI card, then you won't see it, because 
the D3D pipeline doesn't
call the affected method but if you have an Intel chip as do 90% (?) of 
laptops you will see it.
There are also several other places we found that are affected. Printing 
is the other one
somewhat easy to trigger. The others : custom cursors and tray icons are 
less common.
The painful thing here is that there is no definitive list (a list of 
the known ones is below) of
affected Windows GDI APIs and we are just hunting around our code trying 
to see where it

might be side-swiped by this bug.

The basic approach in these workarounds is that for cases where 
performance does not matter we now copy
and for cases where performance does matter or larger amounts of memory 
is involved we check if
the return value of the GDI function indicates failure and then re-try 
with a copy of the heap memory.
Unless GDI was randomly failing already (unlikely) this should be a 
no-risk solution in the high profile cases.
We have done performance measurements on the important screen case and 
the failures
happen fast so the penalty is then in the re-try which is only if ZGC is 
enabled.
Always copying the memory is slower (and memcpy is the slow operation) 
than an alternative approach
that "knows" about the memory allocation of ZGC but this coupling and 
the complexity seem like they aren't
worth it since I haven't seen any visible performance consequence. That 
can be revisited
some day if need be, but for now we have correctness which is the key as 
well as sufficient performance.


I've created an automated test for the most important on-screen case.
Also a manual printing test case which invokes ZGC is provided since 
there we also only
conditionally copy. In the other cases we now always copy so existing 
test cases should over those.


There is some clean up in this fix - one completely unused (provably so 
because it was #if'd out)
JNI method in awt_PrintJob.cpp is removed since it had code that looked 
like it needed a workaround,

which would be somewhat of a waste of effort.

the doPrintBand code and its callee bitsToDevice has code I think we can 
remove too since
I don't see how it ever gets executed (the top down case for 
browserPrint == true) but
I think I'll save that for a P4 follow-on since it does nothing that 
would be affected by this

Windows bug.

One oddity is the in the printing case I observed that some times the 
rendering is performed
even if an error code is returned. I don't know why, but in code we 
can't tell that it was actually
rendered and in any case there is no harm in repeating the call with 
copied memory.


We are right before the JDK15 stabilisation fork and this fix needs to 
go there and will
but the webrev is against jdk/client simply because jdk15 does not exist 
yet !


Please test and review ASAP.

About the bug:
Microsoft has acknowleged the bug and will publish a knowledge base 
article about it
but a fix may show up only in a future version of Windows. Not, it 
seems, any time soon.
Below is a list of potentially affected GDI APIs. Per microsoft whether 
it actually manifests in

any specific case depends on "branching"

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/checkbitmapbits

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/wcs/createcolortransform

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-setdibitstodevice

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-stretchdibits

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getbitmapbits

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibitmap

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-createdibsection

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-polydraw

https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-drawescape

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

[Philip Race]

Hi Kim,

Can we amend the JEP itself to be not solely about hotspot.
Since it affects other areas I think that
1) They may need to be compiled with C++14 enabled whether they use new 
features or not

2) They may want - or need - to adopt C++11 or C++14 features too.

You already know that soon we will upgrade the harfbuzz 3rd party 
library used by 2D
and it will bring along the need to use C++11 features and I had no plan 
to propose a JEP for that.

So I don't want to be asked why we didn't do one when hotspot did !
So this really ought to be a JDK JEP whilst of course explaining that 
hotspot is expected

to be the primary adopter.

BTW the JEP (https://bugs.openjdk.java.net/browse/JDK-8208089) still says
> For Solaris: Add the |-std=c++14| compiler option. .

So I am sure there is still some room to update the JEP :-)

-phil.

On 6/5/20, 12:52 AM, Kim Barrett wrote:

[Changes are only to the build system, but since the changes have jdk-wide
effect I’ve cc’d what I think are the relevant dev lists.]

This change is part of JEP 347; the intent is to target JDK 16.

Please review this change to the building of C++ code in the JDK to
enable the use of C++14 language features.  This change does not make
any code changes to use new features provided by C++11 or C++14.

This requires trimming the supported compiler versions, moving the
minimum supported versions forward (significantly, in some cases).
The new minimums are based on compiler documentation rather than
testing.  It may be that more recent versions are actually required.

This change needs to be tested on platforms not supported by Oracle.
The JEP test plan includes additional Oracle testing beyond what I’ve done.

CR:
https://bugs.openjdk.java.net/browse/JDK-8246032

Webrev:
https://cr.openjdk.java.net/~kbarrett/8246032/open.02/

Testing:
mach5 tier1-5 on Oracle supported platforms.

Performance testing showed no significant changes in either direction.

Build-only (no tests) for linux-arm32, linux-s390x, linux-ppc64le

Re: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11

[Philip Race]

I tried that first but for whatever reason it did not toll free bridge 
properly, so I used this API.


-phil

On 6/2/2020 12:34 AM, Prasanta Sadhukhan wrote:


Thanks Kevin for the clarification. Looks ok to me.

Only thing that can be thought of is to use 
CTFontCreateUIFontForLanguage() (instead of [NSFont 
systemFontOfSize:1.0]) similar to JDK-8234916(which is already 
committed) just to have same approach, incase Apple changes anything 
in future.


Regards
Prasanta
On 01-Jun-20 6:41 PM, Kevin Rushforth wrote:

Hi Prasanta,

No, the reason for the warning / garbled JavaFX printing  in this 
Java2D bug (JDK-8244621) is *similar to* that of FX bug JDK-8234916, 
but in no way is one of them caused by the other.


-- Kevin


On 6/1/2020 5:21 AM, Prasanta Sadhukhan wrote:

Hi Phil,

I was reading somewhere that the warning is caused by JDK-8234916. 
Will we still get the problem if we remove 8234916?


Regards
Prasanta
On 22-May-20 2:26 AM, Philip Race wrote:

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

macOS ships some UI fonts which it does not enumerate, all having 
names beginning with "."

It expects you to create them using APIs such as
CTFontCreateUIFontForLanguage(kCTFontSystemFontType, 0, NULL);
or
nsFont = [NSFont systemFontOfSize:1.0];

In apps built with all SDKs to date, so long as you can get the 
real "." name you can still

request it by name.

But with the latest Xcode 11 this not only prints a warning that 
you should not do it,
it also gives you Times New Roman instead - not a standard UI font 
- probably a choice

so it is obvious it is not a UI font.

Our problem here is that JavaFX uses the system font as its 
"logical" font called System
and also JavaFX uses Java 2D for printing. It messages over the 
".*" name to Java 2D
to use as the font to print. But with the latest Xcode 2D is not 
allowed to create the font using that name.


This fix changes the JDK code for macOS that creates the native 
font pointer to check if the name being requested
is one of the UI fonts. If it is, then it uses the NSFont 
systemFontOfSize API to create the font, which fixes the problem.


If someone asks for a random name such as ".foo"
Note that
1) JDK only enumerates the regular and bold system font which is 
all FX uses.


2) The fix *could* have just tested to see if the requested name 
begins with "." and that worked too but it
wasn't clear what would happen if there is some other font called 
".Foo". We tested and
names starting with "." seem to be absolutely reserved for these 
system fonts on macOS
If you see such a font. it is a system font. We tested and if you 
have a random name such as ".FOO"
macOS does the same thing - it assumes it is a system font and 
won't give it to you.
So probably testing for a "." prefix would have been OK but as 
written it is more certain and
is robust against Apple changing the nameing scheme to be (sa) a 
"~" prefix.


No regression test as this isn't easily testable and the main place 
it matters is FX printing.
However we've verified this on 10.13.6 with the old tool chain and 
10.15.2 with the new toolchain

and fixes the warnings and FX printing.

The removal of adding the fixed width font is because we never 
needed it and it is just Monaco anyway ...


-phil.

Re: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11

[Philip Race]

I know about the trailing white space. Well at least I know there is some.
I didn't notice if I accidentally added more.
Correct jcheck won't complain and I have an open bug to clean this up 
across all code before

the move to git. https://bugs.openjdk.java.net/browse/JDK-8240487

-phil.

On 5/21/20, 2:16 PM, Kevin Rushforth wrote:

+1

In case you want to fix it before you push, you have trailing 
whitespace in the file (jcheck won't complain since it doesn't check 
.m files, so no worries if you don't).


-- Kevin


On 5/21/2020 1:56 PM, Philip Race wrote:

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

macOS ships some UI fonts which it does not enumerate, all having 
names beginning with "."

It expects you to create them using APIs such as
CTFontCreateUIFontForLanguage(kCTFontSystemFontType, 0, NULL);
or
nsFont = [NSFont systemFontOfSize:1.0];

In apps built with all SDKs to date, so long as you can get the real 
"." name you can still

request it by name.

But with the latest Xcode 11 this not only prints a warning that you 
should not do it,
it also gives you Times New Roman instead - not a standard UI font - 
probably a choice

so it is obvious it is not a UI font.

Our problem here is that JavaFX uses the system font as its "logical" 
font called System
and also JavaFX uses Java 2D for printing. It messages over the ".*" 
name to Java 2D
to use as the font to print. But with the latest Xcode 2D is not 
allowed to create the font using that name.


This fix changes the JDK code for macOS that creates the native font 
pointer to check if the name being requested
is one of the UI fonts. If it is, then it uses the NSFont 
systemFontOfSize API to create the font, which fixes the problem.


If someone asks for a random name such as ".foo"
Note that
1) JDK only enumerates the regular and bold system font which is all 
FX uses.


2) The fix *could* have just tested to see if the requested name 
begins with "." and that worked too but it
wasn't clear what would happen if there is some other font called 
".Foo". We tested and
names starting with "." seem to be absolutely reserved for these 
system fonts on macOS
If you see such a font. it is a system font. We tested and if you 
have a random name such as ".FOO"
macOS does the same thing - it assumes it is a system font and won't 
give it to you.
So probably testing for a "." prefix would have been OK but as 
written it is more certain and
is robust against Apple changing the nameing scheme to be (sa) a "~" 
prefix.


No regression test as this isn't easily testable and the main place 
it matters is FX printing.
However we've verified this on 10.13.6 with the old tool chain and 
10.15.2 with the new toolchain

and fixes the warnings and FX printing.

The removal of adding the fixed width font is because we never needed 
it and it is just Monaco anyway ...


-phil.

[OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11

[Philip Race]

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

macOS ships some UI fonts which it does not enumerate, all having names 
beginning with "."

It expects you to create them using APIs such as
CTFontCreateUIFontForLanguage(kCTFontSystemFontType, 0, NULL);
or
nsFont = [NSFont systemFontOfSize:1.0];

In apps built with all SDKs to date, so long as you can get the real "." 
name you can still

request it by name.

But with the latest Xcode 11 this not only prints a warning that you 
should not do it,
it also gives you Times New Roman instead - not a standard UI font - 
probably a choice

so it is obvious it is not a UI font.

Our problem here is that JavaFX uses the system font as its "logical" 
font called System
and also JavaFX uses Java 2D for printing. It messages over the  ".*" 
name to Java 2D
to use as the font to print. But with the latest Xcode 2D is not allowed 
to create the font using that name.


This fix changes the JDK code for macOS that creates the native font 
pointer to check if the name being requested
is one of the UI fonts. If it is, then it uses the NSFont 
systemFontOfSize API to create the font, which fixes the problem.


If someone asks for a random name such as ".foo"
Note that
1) JDK only enumerates the regular and bold system font which is all FX 
uses.


2) The fix *could* have just tested to see if the requested name begins 
with "." and that worked too but it
wasn't clear what would happen if there is some other font called 
".Foo". We tested and
names starting with "." seem to be absolutely reserved for these system 
fonts on macOS
If you see such a font. it is a system font. We tested and if you have a 
random name such as ".FOO"
macOS does the same thing - it assumes it is a system font and won't 
give it to you.
So probably testing for a "." prefix would have been OK but as written 
it is more certain and

is robust against Apple changing the nameing scheme to be (sa) a "~" prefix.

No regression test as this isn't easily testable and the main place it 
matters is FX printing.
However we've verified this on 10.13.6 with the old tool chain and 
10.15.2 with the new toolchain

and fixes the warnings and FX printing.

The removal of adding the fixed width font is because we never needed it 
and it is just Monaco anyway ...


-phil.

Re: [OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes.

[Philip Race]

On 5/18/20, 9:29 PM, Sergey Bylokhov wrote:

Hi, Phil.

I guess the old code used TextLayout because the check above is "false":
boolean simple = values == null ||
(values.getKerning() == 0 && values.getLigatures() == 0 &&
values.getBaselineTransform() == null);


yes ...


Is it possible that for the font which use 
attributes/kerning/ligatures the height
calculated via TextLayout and FontDesignMetrics.getSimpleBounds() will 
be different?


no.



BTW what about the comment for this block:
   // this code should be in textlayout
   // quick check for simple text, assume GV ok to use if simple


well, there's the the issue that TL should not barf, but it does.

-phil.



On 5/18/20 5:07 pm, Philip Race wrote:

bug : https://bugs.openjdk.java.net/browse/JDK-8245159
webrev: http://cr.openjdk.java.net/~prr/8245159/

TextLayout does not like being constructed with an empty string, so
when we accept a string from the application and  use it in
creating a TextLayout we need to be check.
I looked around for other cases that may be missing a check but did 
not spot any.


-phil.

[OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes.

[Philip Race]

bug : https://bugs.openjdk.java.net/browse/JDK-8245159
webrev: http://cr.openjdk.java.net/~prr/8245159/

TextLayout does not like being constructed with an empty string, so
when we accept a string from the application and  use it in
creating a TextLayout we need to be check.
I looked around for other cases that may be missing a check but did not 
spot any.


-phil.

[OpenJDK 2D-Dev] RFR: 6949753 java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop

[Philip Race]

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

Buggy, manual and not very useful. Delete.

-phil.

[OpenJDK 2D-Dev] Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested.

[Philip Race]

The first EA build of Project Lanai is available at 
https://jdk.java.net/lanai/


This is a new Java2D graphics pipeline for macOS.

It can run the usual client demos, such as SwingSet2 and J2Ddemo,
and even a large app like an IDE, although not without glitches.
The EA download page has a link to the list of known, open bugs you can 
consult.


It is a first EA build and there is plenty of work still to be done
and we have doubtless not tested every situation nor do we have
every piece of mac hardware out there, so there will be unreported 
issues too.


Please try it, and provide feedback to the lanai-...@openjdk.java.net 
mailing list.


Make sure you specify -Dsun.java2d.metal=true  !!

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop)

[Philip Race]

This is all +1 from me.

-phil.

On 5/6/20, 5:50 PM, Mikael Vidstedt wrote:

Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and 
found some additional Sun Studio cleanups.

New webrev here:

webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client/open/webrev/
incremental: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/client.incr/open/webrev/

Cheers,
Mikael


On May 3, 2020, at 10:12 PM, Mikael Vidstedt  wrote:


Please review this change which implements part of JEP 381:

JBS: https://bugs.openjdk.java.net/browse/JDK-8244224
webrev: 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/client/open/webrev/
JEP: https://bugs.openjdk.java.net/browse/JDK-8241787


Note: When reviewing this, please be aware that this exercise was *extremely* 
mind-numbing, so I appreciate your help reviewing all the individual changes 
carefully. You may want to get that coffee cup filled up (or whatever keeps you 
awake)!


Background:

Because of the size of the total patch and wide range of areas touched, this 
patch is one out of in total six partial patches which together make up the 
necessary changes to remove the Solaris and SPARC ports. The other patches are 
being sent out for review to mailing lists appropriate for the respective areas 
the touch. An email will be sent to jdk-dev summarizing all the 
patches/reviews. To be clear: this patch is *not* in itself complete and 
stand-alone - all of the (six) patches are needed to form a complete patch. 
Some changes in this patch may look wrong or incomplete unless also looking at 
the corresponding changes in other areas.

For convenience, I’m including a link below[1] to the full webrev, but in case 
you have comments on changes in other areas, outside of the files included in 
this thread, please provide those comments directly in the thread on the 
appropriate mailing list for that area if possible.

In case it helps, the changes were effectively produced by searching for and 
updating any code mentioning “solaris", “sparc”, “solstudio”, “sunos”, etc. 
More information about the areas impacted can be found in the JEP itself.


Testing:

A slightly earlier version of this change successfully passed tier1-8, as well 
as client tier1-2. Additional testing will be done after the first round of 
reviews has been completed.

Cheers,
Mikael

[1] 
http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

[Philip Race]

On 5/3/20, 4:11 PM, Sergey Bylokhov wrote:

On 4/30/20 9:31 am, Philip Race wrote:

This test is called MaxAdvance *is max*. My emphasis.


So there is no way to check that  MaxAdvance *is max* for some 
predictable values? even for simple char like "W" or "A"?


"Check" or "ensure" ?
To check you compare.
To ensure you would have to do as you said in a previous reply by 
forcing max advance to
as great as those arbitrary characters and I already gave my reasons why 
I think that is not appropriate.
It is very hard to defend why certain code points are special and you 
would adjust the spec. again(!) to
say that. And it would be to no advantage and perhaps break applications 
that did not expect it to change.


-phil.



Not "all values returned by getWidths() are less than or equal to max 
advance.
The latter is simply the inadequate implementation to partially test 
the assertion
and which was already proving to be too much. The only way to make 
that test

pass is to make changes to what max advance reports and I am saying that
we should not do that. It would be artificial and wrong.

-phil.



On 4/30/20, 9:23 AM, Sergey Bylokhov wrote:

On 4/29/20 3:58 pm, Philip Race wrote:
the advance of 'm' is a commonly used proxy for the design width of 
a latin font.
But I agree it is also not really a great estimate once you 
consider any international text.


Anyway I am not sure where you are headed with that and the
discussion of charWidth() or charWidths().

I am not trying to "fix the world" here, I am just removing a test
that it is pointless to maintain.


Then probably we can report a bug, to state that we have some issues 
here?

From my point of view, the test is mostly fine, it does not check some
real corner cases and compound glyphs but only the simple chars, 
which should
work. If it does not work means all code where we try to predict the 
size of
the text components is broken, and it looks like there is no way to 
fix that.

Re: [OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args.

[Philip Race]

ping !

-phil.

On 4/30/20, 3:08 PM, Philip Race wrote:

Updated with a couple of stability fixes :
1) to use invokeAndWait() instead of invokeLater()
2) To skip fonts that don't support the text we are testing.

http://cr.openjdk.java.net/~prr/8244113.1

-phil

On 4/29/20, 11:56 AM, Philip Race wrote:

bug : https://bugs.openjdk.java.net/browse/JDK-8244113
webrev : http://cr.openjdk.java.net/~prr/8244113/

Apparently jtreg consumes text even from 2 lines later after an @run tag
as being args to pass to the program.

Test still passes everywhere after the change.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args.

[Philip Race]

Updated with a couple of stability fixes :
1) to use invokeAndWait() instead of invokeLater()
2) To skip fonts that don't support the text we are testing.

http://cr.openjdk.java.net/~prr/8244113.1

-phil

On 4/29/20, 11:56 AM, Philip Race wrote:

bug : https://bugs.openjdk.java.net/browse/JDK-8244113
webrev : http://cr.openjdk.java.net/~prr/8244113/

Apparently jtreg consumes text even from 2 lines later after an @run tag
as being args to pass to the program.

Test still passes everywhere after the change.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

[Philip Race]

This test is called MaxAdvance *is max*. My emphasis.
Not "all values returned by getWidths() are less than or equal to max 
advance.
The latter is simply the inadequate implementation to partially test the 
assertion

and which was already proving to be too much. The only way to make that test
pass is to make changes to what max advance reports and I am saying that
we should not do that. It would be artificial and wrong.

-phil.



On 4/30/20, 9:23 AM, Sergey Bylokhov wrote:

On 4/29/20 3:58 pm, Philip Race wrote:
the advance of 'm' is a commonly used proxy for the design width of a 
latin font.
But I agree it is also not really a great estimate once you consider 
any international text.


Anyway I am not sure where you are headed with that and the
discussion of charWidth() or charWidths().

I am not trying to "fix the world" here, I am just removing a test
that it is pointless to maintain.


Then probably we can report a bug, to state that we have some issues 
here?

From my point of view, the test is mostly fine, it does not check some
real corner cases and compound glyphs but only the simple chars, which 
should
work. If it does not work means all code where we try to predict the 
size of
the text components is broken, and it looks like there is no way to 
fix that.

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

[Philip Race]

the advance of 'm' is a commonly used proxy for the design width of a 
latin font.
But I agree it is also not really a great estimate once you consider any 
international text.


Anyway I am not sure where you are headed with that and the
discussion of charWidth() or charWidths().

I am not trying to "fix the world" here, I am just removing a test
that it is pointless to maintain.

-phil.

On 4/29/20, 2:54 PM, Sergey Bylokhov wrote:

On 4/29/20 2:33 pm, Philip Race wrote:

Now that is another topic and unrelated to max advance
I think a spec update and CSR would be required for getWidths()
and I'd still say this test is not worth it.


Probably yes, because it is currently states that "Gets the advance
widths of the first 256 characters " and it is bizarre that the
getMaxAdvance() may return smaller size even for the  simple char's.

Currently ina few places we have code like this:
columnWidth = metrics.charWidth('m');

Which is far than optimal, and getMaxAdvance() should fit better than
the size of the "m"(or 'w'), but seems this method and its current
implementation is completely useless.



-phil

On 4/29/20, 2:21 PM, Sergey Bylokhov wrote:

On 4/28/20 4:28 pm, Philip Race wrote:
And max advance is NOT only about the advance of the first 256 
characters anyway
Yes but it makes it a little bit more useful, it least it will 
always return correct max

advance for the first characters.


Actually I'll argue it can be the opposite.
Doing this you ask it to go check in fallback fonts and in the 
failure I
analysed on macos we got a fallback from a CJK font for an 
unprintable character.
Now whilst that may make it "more likely" if we include that in the 
maxadvance
and care only about chars 0-255 it will pass, you've now got a very 
different max
advance returned than is the design centre for the primary font and 
REAL uses

of chars 0-255 which would never try to display char 132 etc.


Then probably we could skip any unprintable characters?

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

[Philip Race]

Now that is another topic and unrelated to max advance
I think a spec update and CSR would be required for getWidths()
and I'd still say this test is not worth it.

-phil

On 4/29/20, 2:21 PM, Sergey Bylokhov wrote:

On 4/28/20 4:28 pm, Philip Race wrote:
And max advance is NOT only about the advance of the first 256 
characters anyway
Yes but it makes it a little bit more useful, it least it will 
always return correct max

advance for the first characters.


Actually I'll argue it can be the opposite.
Doing this you ask it to go check in fallback fonts and in the failure I
analysed on macos we got a fallback from a CJK font for an 
unprintable character.
Now whilst that may make it "more likely" if we include that in the 
maxadvance
and care only about chars 0-255 it will pass, you've now got a very 
different max
advance returned than is the design centre for the primary font and 
REAL uses

of chars 0-255 which would never try to display char 132 etc.


Then probably we could skip any unprintable characters?

[OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args.

[Philip Race]

bug : https://bugs.openjdk.java.net/browse/JDK-8244113
webrev : http://cr.openjdk.java.net/~prr/8244113/

Apparently jtreg consumes text even from 2 lines later after an @run tag
as being args to pass to the program.

Test still passes everywhere after the change.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

[Philip Race]

On 4/28/20, 2:38 PM, Sergey Bylokhov wrote:

On 4/28/20 1:28 pm, Philip Race wrote:


You mean make sure maxAdvance is always at least as large as the
largest returned by getWidths() ?

getWidths() is almost as useless as getMaxAdvance().
I grimace every time I look at it and can only imagine it was added 
as a sort

of performance cache.
It only returns the advances of the first 256 characters, and it does 
not

even care whether those characters are supported by the font.
Very often they are not as there's a bunch of unprintable code points 
in there.



And max advance is NOT only about the advance of the first 256 
characters anyway
Yes but it makes it a little bit more useful, it least it will always 
return correct max

advance for the first characters.


Actually I'll argue it can be the opposite.
Doing this you ask it to go check in fallback fonts and in the failure I
analysed on macos we got a fallback from a CJK font for an unprintable 
character.
Now whilst that may make it "more likely" if we include that in the 
maxadvance
and care only about chars 0-255 it will pass, you've now got a very 
different max
advance returned than is the design centre for the primary font and REAL 
uses

of chars 0-255 which would never try to display char 132 etc.



So that would be completely artificial and you'd be potentially 
introducing
a change that would cause apps to layout differently to keep an 
useless test

working.


Isn't such applications is not broken already if the getMaxAdvance() 
returns
the size smaller than the any of getWidths()? My suggestion is to 
increase max

maxAdvance if it is positive but smaller than getWidths.


They are already dealing with what they get today.
If you change it how can that not be more risky ?
And they aren't "broken". Realistically max advance is going to be
good enough for a lot of people and your proposal could mean
they now have a wider advance that affects layout without a benefit.
Yes it could also benefit someone else, but I don't see it as worth it
for the reasons out lined above.

So let's not try to randomly pick chars 0-255 as special and lets
not not try to artificially make a test pass that proves nothing useful.

-phil.




-phil.

On 4/28/20, 1:07 PM, Sergey Bylokhov wrote:

Hi, Phil.

Why we cannot change the implementation of getMaxAdvance() and
make a quick check of the FontMetrics.getWidths() the same as in the
test? I think it does not break the new spec and the test will pass.

On 4/28/20 12:38 pm, Philip Race wrote:

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

Now that we have resolved
JDK-8230672 : Specification for 
java.awt.FontMetrics.getMaxAdvance() is too prescriptive.
with an approved CSR, the assertion being tested by 
java/awt/FontMetrics/MaxAdvanceIsMax.java is not enforceable.


The test should just be retired.


-phil.