From victor.dyakov at oracle.com  Wed Mar  4 05:52:42 2015
From: victor.dyakov at oracle.com (Victor D'yakov)
Date: Wed, 04 Mar 2015 08:52:42 +0300
Subject: [OpenJDK 2D-Dev] <Swing Dev> Uptake of TUXJDK font fixes in
	Java 8
In-Reply-To: <CAF=+AsstVAfgdRQt+AFOo18vzFWgGiNTePmAFiALOH4AaiCRig@mail.gmail.com>
References: <CAF=+AsstVAfgdRQt+AFOo18vzFWgGiNTePmAFiALOH4AaiCRig@mail.gmail.com>
Message-ID: <54F69DAA.60106@oracle.com>

Added 2d-dev

On 04.03.2015 5:08, Jan Vissers wrote:
> Hello,
>
> On blogs.oracle.com <http://blogs.oracle.com> there was an 
> announcement of Java 8U40 availability. As far as I could tell from 
> the release notes there were no changes made to provide better support 
> for font rendering on *Nix systems - which is why I asked the 
> following question on: 
> https://blogs.oracle.com/java/entry/announcing_jdk_8_update_40
>
> <quote>
>
> Question: where are the much needed font rendering fixes for *Nix 
> platforms? Without tuxjdk (https://code.google.com/p/tuxjdk/) 
> <https://code.google.com/p/tuxjdk/%29> - which provides a number of 
> patches on top of OpenJDK, my eyes would really bleed spending a whole 
> day coding in Netbeans/Intellij or any swing based app on Linux.
>
> Is there a way to get these fixes into Java SE 8?
> For details on what tuxjdk is fixing check this out:
> https://code.google.com/p/tuxjdk/w/list
>
> </quote>
>
> A prompt answer was given in that a best approach would be to reach 
> out to Swing Toolkit Group - which is what I'm now doing :-)
>
> So again: are there plans to give us developers that use Swing based 
> tools (like Netbeans/Intellij) some decent font rendering on *Nix 
> systems too? Googling on fonts, swing and *Nix does show that there 
> are quite a few people suffering from 'bleeding eyes'.
>
> Thanks,
> -J.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150304/3a2d1308/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Mar  4 12:37:44 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 04 Mar 2015 15:37:44 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API references
	to java.awt.peer
Message-ID: <54F6FC98.5030303@oracle.com>

Hello.
Please review the fix for jdk 9.
There are a number of public API whichreference the unsupported 
java.awt.peer interfaces.

public java.awt.Component.getPeer() @deprecated 1.1
public java.awt.Font.getPeer() @deprecated 1.1
public java.awt.MenuComponent.getPeer() @deprecated 1.1

There is a decision to remove this methods as described: 
http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html

Most important changes:
http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/Component.java.sdiff.html
-    /**
-     * @deprecated As of JDK version 1.1,
-     * programs should not directly manipulate peers;
-     * replaced by <code>boolean isDisplayable()</code>.
-     * @return the peer for this component
-     */
-    @Deprecated
-    public ComponentPeer getPeer() {
-        return peer;
-    }

Component.getPeer was removed and its usage was replaced by:
  - dirrect access to the field if possible
  - (getPeer() !=/== null) is replaced by the isDisplayable()
  - All other places now use an AWTAccessor.

http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/MenuComponent.java.sdiff.html
-    /**
-     * @deprecated As of JDK version 1.1,
-     * programs should not directly manipulate peers.
-     * @return the peer for this component
-     */
-    @Deprecated
-    public MenuComponentPeer getPeer() {
-        return peer;
-    }

MenuComponentPeer.getPeer was removed, now we use an AWTAccessor instead.

http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/Font.java.sdiff.html
Font.getPeer() access was changed to the private, because it is not 
simple getter, and it is used in native code. On the java side now we 
use an AWTAccessor.

Also I tried to fix the open tests, but not sure that I cover all of 
them. I'll fix other tests in the separate CR.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074028
Webrev can be found at: http://cr.openjdk.java.net/~serb/8074028/webrev.05

-- 
Best regards, Sergey.



From magnus.ihse.bursie at oracle.com  Wed Mar  4 13:17:20 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 04 Mar 2015 14:17:20 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native warnings in
 JDK on a per-library basis
Message-ID: <54F705E0.2030102@oracle.com>

When building the native code in the jdk repo, a lot of warnings are 
generated. So many that it's hard to spot any new issues.

While the ultimate goal must be to address and fix these warnings 
individually, this bug is about disabling these warnings where they 
occur, so that it is easier to spot new warnings, and that the existing 
warnings can be addressed one at a time.

Disabling warnings instead of fixing them can be problematic. If you are 
too broad with disabling warnings, you might hide future problems. On 
the other hand, there have been a lot of warnings that indicate serious 
problems that has been "hidden in plain sight" for a very long time in 
the code base anyway.

I have opted to disable warnings at the library level. Disabling 
warnings globally would be too broad. Disabling per file would have been 
too tedious. Many warnings also tend to repeat across multiple files in 
the same library, due to e.g. less well-suited programming style or 
design choice. A library also seems like a suitable chunk of work to 
address later on, in trying to get rid of the source of the warnings.

This fix will not get rid of all warnings, but the bulk of them. It will 
make the remaining warnings stick out more. The few warnings that remain 
are either:
* Not possible to disable.
* Not resulting from native compilation (but from linking, or javadoc, etc).
* Not possible to disable with this framework (this goes for builds on 
pre-4.4 gcc, which Oracle currently does as default on macosx), and 
libfontmanager on Solaris, which mixes C and C++ code. (While the 
solstudio C compiler does not fail on requests to disable C++ warnings, 
the converse is unfortunately not true). It did not seem worth the 
trouble to build a more extensible framework to handle this, compared to 
actually fixing these warnings.

Note that the current JPRT build environment in Oracle uses a pre-4.4 
gcc for macosx by default, so the default macosx build will still 
contain warnings. When building with --with-toolchain-type=clang, the 
clang warning disabling kicks in. (This will be the default in JPRT 
later on this year.)

I intend to file individual bugs to handle these remaining warnings, so 
the net result will be a completely warning free build.

I also intend to file individual bugs on all the libraries that has had 
warnings disabled. I expect the outcome of these bugs to be either:

A) The code modified so it does not trigger warnings, and the warnings 
re-enabled, or

B) The warnings (or a subset of them) kept disabled, but a comment added 
to the makefile describing why this is the proper course of action.

Not all bugs might be worth fixing. For instance, the GCC warnings 
type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
deprecated-declarations, clobbered, int-to-pointer-cast and type-limits 
are all more or less benign, and is possibly the result of a false positive.

On the other hands, warnings such as format-nonliteral, unused-result, 
maybe-uninitialized, format, format-security, int-to-pointer-cast, 
reorder and delete-non-virtual-dtor are more likely to actually point to 
real issues. I recommend anyone finding these warnings on a library they 
care about to try and fix them as soon as possible.

Here is a summary of the libraries and binaries that have gotten 
warnings disabled. I'm not sure about what group owns all these 
libraries; if I missed sending this mail to the correct list, please 
help me and forward it.

* libunpack
* libfdlibm
* libverify
* libjava
* libzip
* libjli/libjli_static
* libj2gss
* libsunec
* libj2pkcs11
* libnet
* libnio
* libosxkrb5
* libosxapp
* libosx
* libapplescriptengine
* libjsound
* libjsoundalsa
* libmlib_image
* libawt
* libawt_xawt
* libawt_lwawt
* liblcms
* libjavajpeg
* libawt_headless
* libfontmanager
* libsplashscreen
* unpack200
* The JVMTI demos compiledMethodLoad and waiters

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

WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01

/Magnus



From erik.joelsson at oracle.com  Wed Mar  4 13:31:53 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 04 Mar 2015 14:31:53 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F705E0.2030102@oracle.com>
References: <54F705E0.2030102@oracle.com>
Message-ID: <54F70949.4040900@oracle.com>

Hello,

Really nice to finally see this patch getting done!

Only one comment:

flags.m4:
In the grep expression, could you move the extra [] outside of the 
actual command line options to grep so that the command line could be 
copied to the shell for debugging in the future? Also, how hard would it 
be to instead do AC_COMPILE_IFELSE with a dummy warning to instead test 
for capability?

/Erik

On 2015-03-04 14:17, Magnus Ihse Bursie wrote:
> When building the native code in the jdk repo, a lot of warnings are 
> generated. So many that it's hard to spot any new issues.
>
> While the ultimate goal must be to address and fix these warnings 
> individually, this bug is about disabling these warnings where they 
> occur, so that it is easier to spot new warnings, and that the 
> existing warnings can be addressed one at a time.
>
> Disabling warnings instead of fixing them can be problematic. If you 
> are too broad with disabling warnings, you might hide future problems. 
> On the other hand, there have been a lot of warnings that indicate 
> serious problems that has been "hidden in plain sight" for a very long 
> time in the code base anyway.
>
> I have opted to disable warnings at the library level. Disabling 
> warnings globally would be too broad. Disabling per file would have 
> been too tedious. Many warnings also tend to repeat across multiple 
> files in the same library, due to e.g. less well-suited programming 
> style or design choice. A library also seems like a suitable chunk of 
> work to address later on, in trying to get rid of the source of the 
> warnings.
>
> This fix will not get rid of all warnings, but the bulk of them. It 
> will make the remaining warnings stick out more. The few warnings that 
> remain are either:
> * Not possible to disable.
> * Not resulting from native compilation (but from linking, or javadoc, 
> etc).
> * Not possible to disable with this framework (this goes for builds on 
> pre-4.4 gcc, which Oracle currently does as default on macosx), and 
> libfontmanager on Solaris, which mixes C and C++ code. (While the 
> solstudio C compiler does not fail on requests to disable C++ 
> warnings, the converse is unfortunately not true). It did not seem 
> worth the trouble to build a more extensible framework to handle this, 
> compared to actually fixing these warnings.
>
> Note that the current JPRT build environment in Oracle uses a pre-4.4 
> gcc for macosx by default, so the default macosx build will still 
> contain warnings. When building with --with-toolchain-type=clang, the 
> clang warning disabling kicks in. (This will be the default in JPRT 
> later on this year.)
>
> I intend to file individual bugs to handle these remaining warnings, 
> so the net result will be a completely warning free build.
>
> I also intend to file individual bugs on all the libraries that has 
> had warnings disabled. I expect the outcome of these bugs to be either:
>
> A) The code modified so it does not trigger warnings, and the warnings 
> re-enabled, or
>
> B) The warnings (or a subset of them) kept disabled, but a comment 
> added to the makefile describing why this is the proper course of action.
>
> Not all bugs might be worth fixing. For instance, the GCC warnings 
> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
> deprecated-declarations, clobbered, int-to-pointer-cast and 
> type-limits are all more or less benign, and is possibly the result of 
> a false positive.
>
> On the other hands, warnings such as format-nonliteral, unused-result, 
> maybe-uninitialized, format, format-security, int-to-pointer-cast, 
> reorder and delete-non-virtual-dtor are more likely to actually point 
> to real issues. I recommend anyone finding these warnings on a library 
> they care about to try and fix them as soon as possible.
>
> Here is a summary of the libraries and binaries that have gotten 
> warnings disabled. I'm not sure about what group owns all these 
> libraries; if I missed sending this mail to the correct list, please 
> help me and forward it.
>
> * libunpack
> * libfdlibm
> * libverify
> * libjava
> * libzip
> * libjli/libjli_static
> * libj2gss
> * libsunec
> * libj2pkcs11
> * libnet
> * libnio
> * libosxkrb5
> * libosxapp
> * libosx
> * libapplescriptengine
> * libjsound
> * libjsoundalsa
> * libmlib_image
> * libawt
> * libawt_xawt
> * libawt_lwawt
> * liblcms
> * libjavajpeg
> * libawt_headless
> * libfontmanager
> * libsplashscreen
> * unpack200
> * The JVMTI demos compiledMethodLoad and waiters
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096
>
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01
>
> /Magnus
>



From Alan.Bateman at oracle.com  Wed Mar  4 13:48:50 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 13:48:50 +0000
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F705E0.2030102@oracle.com>
References: <54F705E0.2030102@oracle.com>
Message-ID: <54F70D42.3010905@oracle.com>

On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
> :
>
> I intend to file individual bugs to handle these remaining warnings, 
> so the net result will be a completely warning free build.
>
> I also intend to file individual bugs on all the libraries that has 
> had warnings disabled. I expect the outcome of these bugs to be either:
>
> A) The code modified so it does not trigger warnings, and the warnings 
> re-enabled, or
>
> B) The warnings (or a subset of them) kept disabled, but a comment 
> added to the makefile describing why this is the proper course of action.
>
> Not all bugs might be worth fixing. For instance, the GCC warnings 
> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
> deprecated-declarations, clobbered, int-to-pointer-cast and 
> type-limits are all more or less benign, and is possibly the result of 
> a false positive.
Right, although for some of these it is important to double check.

Do you plan to paste in the warnings into the bugs that you will create? 
That wold be useful as warnings are a moving target.

-Alan


From magnus.ihse.bursie at oracle.com  Wed Mar  4 15:03:20 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 04 Mar 2015 16:03:20 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F70D42.3010905@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
Message-ID: <54F71EB8.3030109@oracle.com>

On 2015-03-04 14:48, Alan Bateman wrote:
> On 04/03/2015 13:17, Magnus Ihse Bursie wrote:
>> :
>>
>> I intend to file individual bugs to handle these remaining warnings, 
>> so the net result will be a completely warning free build.
>>
>> I also intend to file individual bugs on all the libraries that has 
>> had warnings disabled. I expect the outcome of these bugs to be either:
>>
>> A) The code modified so it does not trigger warnings, and the 
>> warnings re-enabled, or
>>
>> B) The warnings (or a subset of them) kept disabled, but a comment 
>> added to the makefile describing why this is the proper course of 
>> action.
>>
>> Not all bugs might be worth fixing. For instance, the GCC warnings 
>> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
>> deprecated-declarations, clobbered, int-to-pointer-cast and 
>> type-limits are all more or less benign, and is possibly the result 
>> of a false positive.
> Right, although for some of these it is important to double check.
I believe all warnings are important to check! Unfortunately, this has 
not been done for a lot of warnings for a lot of time. :(

With this framework, it is simple to enable a single warning, recompile 
and see the effect. Hopefully this lowers the threshold far enough so 
that all warnings are given proper attention. The incremental build 
functionality will come in very handy. Just by simply removing a warning 
from the DISABLED_WARNINGS_<toolchain> on a library and running "make" 
again, only the files affected will be recompiled.
>
> Do you plan to paste in the warnings into the bugs that you will 
> create? That wold be useful as warnings are a moving target.

I can easily paste in what warning categories are disabled for a 
specific library, yes.

However, if you are asking me to build each library, individually, with 
warnings re-enabled, and pasting the output, I'd rather not. That would 
be a lot of work, to detangle the output of each individual library.

/Magnus


From tim.bell at oracle.com  Wed Mar  4 16:19:32 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 04 Mar 2015 08:19:32 -0800
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F70949.4040900@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com>
Message-ID: <54F73094.8020108@oracle.com>

Magnus:

Looks good to me as well.

Tim

On 03/04/15 05:31, Erik Joelsson wrote:
> Hello,
>
> Really nice to finally see this patch getting done!
>
> Only one comment:
>
> flags.m4:
> In the grep expression, could you move the extra [] outside of the 
> actual command line options to grep so that the command line could be 
> copied to the shell for debugging in the future? Also, how hard would 
> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead 
> test for capability?
>
> /Erik
>
> On 2015-03-04 14:17, Magnus Ihse Bursie wrote:
>> When building the native code in the jdk repo, a lot of warnings are 
>> generated. So many that it's hard to spot any new issues.
>>
>> While the ultimate goal must be to address and fix these warnings 
>> individually, this bug is about disabling these warnings where they 
>> occur, so that it is easier to spot new warnings, and that the 
>> existing warnings can be addressed one at a time.
>>
>> Disabling warnings instead of fixing them can be problematic. If you 
>> are too broad with disabling warnings, you might hide future 
>> problems. On the other hand, there have been a lot of warnings that 
>> indicate serious problems that has been "hidden in plain sight" for a 
>> very long time in the code base anyway.
>>
>> I have opted to disable warnings at the library level. Disabling 
>> warnings globally would be too broad. Disabling per file would have 
>> been too tedious. Many warnings also tend to repeat across multiple 
>> files in the same library, due to e.g. less well-suited programming 
>> style or design choice. A library also seems like a suitable chunk of 
>> work to address later on, in trying to get rid of the source of the 
>> warnings.
>>
>> This fix will not get rid of all warnings, but the bulk of them. It 
>> will make the remaining warnings stick out more. The few warnings 
>> that remain are either:
>> * Not possible to disable.
>> * Not resulting from native compilation (but from linking, or 
>> javadoc, etc).
>> * Not possible to disable with this framework (this goes for builds 
>> on pre-4.4 gcc, which Oracle currently does as default on macosx), 
>> and libfontmanager on Solaris, which mixes C and C++ code. (While the 
>> solstudio C compiler does not fail on requests to disable C++ 
>> warnings, the converse is unfortunately not true). It did not seem 
>> worth the trouble to build a more extensible framework to handle 
>> this, compared to actually fixing these warnings.
>>
>> Note that the current JPRT build environment in Oracle uses a pre-4.4 
>> gcc for macosx by default, so the default macosx build will still 
>> contain warnings. When building with --with-toolchain-type=clang, the 
>> clang warning disabling kicks in. (This will be the default in JPRT 
>> later on this year.)
>>
>> I intend to file individual bugs to handle these remaining warnings, 
>> so the net result will be a completely warning free build.
>>
>> I also intend to file individual bugs on all the libraries that has 
>> had warnings disabled. I expect the outcome of these bugs to be either:
>>
>> A) The code modified so it does not trigger warnings, and the 
>> warnings re-enabled, or
>>
>> B) The warnings (or a subset of them) kept disabled, but a comment 
>> added to the makefile describing why this is the proper course of 
>> action.
>>
>> Not all bugs might be worth fixing. For instance, the GCC warnings 
>> type-limits, sign-compare, pointer-to-int-cast, conversion-null, 
>> deprecated-declarations, clobbered, int-to-pointer-cast and 
>> type-limits are all more or less benign, and is possibly the result 
>> of a false positive.
>>
>> On the other hands, warnings such as format-nonliteral, 
>> unused-result, maybe-uninitialized, format, format-security, 
>> int-to-pointer-cast, reorder and delete-non-virtual-dtor are more 
>> likely to actually point to real issues. I recommend anyone finding 
>> these warnings on a library they care about to try and fix them as 
>> soon as possible.
>>
>> Here is a summary of the libraries and binaries that have gotten 
>> warnings disabled. I'm not sure about what group owns all these 
>> libraries; if I missed sending this mail to the correct list, please 
>> help me and forward it.
>>
>> * libunpack
>> * libfdlibm
>> * libverify
>> * libjava
>> * libzip
>> * libjli/libjli_static
>> * libj2gss
>> * libsunec
>> * libj2pkcs11
>> * libnet
>> * libnio
>> * libosxkrb5
>> * libosxapp
>> * libosx
>> * libapplescriptengine
>> * libjsound
>> * libjsoundalsa
>> * libmlib_image
>> * libawt
>> * libawt_xawt
>> * libawt_lwawt
>> * liblcms
>> * libjavajpeg
>> * libawt_headless
>> * libfontmanager
>> * libsplashscreen
>> * unpack200
>> * The JVMTI demos compiledMethodLoad and waiters
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074096
>>
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.01
>>
>> /Magnus
>>
>



From Alan.Bateman at oracle.com  Wed Mar  4 12:51:49 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 12:51:49 +0000
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F6FC98.5030303@oracle.com>
References: <54F6FC98.5030303@oracle.com>
Message-ID: <54F6FFE5.2070405@oracle.com>

On 04/03/2015 12:37, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> There are a number of public API whichreference the unsupported 
> java.awt.peer interfaces.
>
> public java.awt.Component.getPeer() @deprecated 1.1
> public java.awt.Font.getPeer() @deprecated 1.1
> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>
I don't know this area so I don't feel qualified to do a thorough review 
of the changes. However I welcome the changes, this is long standing 
technical debt and important that we address this as part of the move to 
modules.

I note that Font::getPeer is changed to private, hence something try to 
access it outside of the Font class will get an IllegalAccessError as 
opposed to NoSuchMethodError for the outright removal in the other 
cases. Did you consider renaming to something else, say private FontPeer 
getFontPeer so that it is consistent with the removal of the other two 
methods?

I note that you might not have caught all tests but I would assume that 
any missed tests should fail. Perhaps there are other failures that are 
potentially hiding tests using getPeer?

-Alan



From Sergey.Bylokhov at oracle.com  Wed Mar  4 13:35:30 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 04 Mar 2015 16:35:30 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F6FFE5.2070405@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
Message-ID: <54F70A22.6010607@oracle.com>

On 04.03.2015 15:51, Alan Bateman wrote:
> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 9.
>> There are a number of public API whichreference the unsupported 
>> java.awt.peer interfaces.
>>
>> public java.awt.Component.getPeer() @deprecated 1.1
>> public java.awt.Font.getPeer() @deprecated 1.1
>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>
> I don't know this area so I don't feel qualified to do a thorough 
> review of the changes. However I welcome the changes, this is long 
> standing technical debt and important that we address this as part of 
> the move to modules.
>
> I note that Font::getPeer is changed to private, hence something try 
> to access it outside of the Font class will get an IllegalAccessError 
> as opposed to NoSuchMethodError for the outright removal in the other 
> cases. Did you consider renaming to something else, say private 
> FontPeer getFontPeer so that it is consistent with the removal of the 
> other two methods?
Make sense, I will update the fix.

> I note that you might not have caught all tests but I would assume 
> that any missed tests should fail. Perhaps there are other failures 
> that are potentially hiding tests using getPeer?
At least I fixed most(if not all) tests, which were passed before the 
fix and fails after

>
> -Alan
>


-- 
Best regards, Sergey.



From yuri.nesterenko at oracle.com  Wed Mar  4 14:48:29 2015
From: yuri.nesterenko at oracle.com (Yuri Nesterenko)
Date: Wed, 04 Mar 2015 17:48:29 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F70A22.6010607@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
	<54F70A22.6010607@oracle.com>
Message-ID: <54F71B3D.5030708@oracle.com>

On 03/04/2015 04:35 PM, Sergey Bylokhov wrote:
> On 04.03.2015 15:51, Alan Bateman wrote:
>> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>> There are a number of public API whichreference the unsupported
>>> java.awt.peer interfaces.
>>>
>>> public java.awt.Component.getPeer() @deprecated 1.1
>>> public java.awt.Font.getPeer() @deprecated 1.1
>>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>>
>> I don't know this area so I don't feel qualified to do a thorough
>> review of the changes. However I welcome the changes, this is long
>> standing technical debt and important that we address this as part of
>> the move to modules.
>>
>> I note that Font::getPeer is changed to private, hence something try
>> to access it outside of the Font class will get an IllegalAccessError
>> as opposed to NoSuchMethodError for the outright removal in the other
>> cases. Did you consider renaming to something else, say private
>> FontPeer getFontPeer so that it is consistent with the removal of the
>> other two methods?
> Make sense, I will update the fix.
>
>> I note that you might not have caught all tests but I would assume
>> that any missed tests should fail. Perhaps there are other failures
>> that are potentially hiding tests using getPeer?
> At least I fixed most(if not all) tests, which were passed before the
> fix and fails after

Speaking of the tests, there are some more to fix (like
test/java/awt/regtesthelpers/UtilInternal.java etc.) but not too many.
We could do it separately.

-yan

>
>>
>> -Alan
>>
>
>



From Alan.Bateman at oracle.com  Wed Mar  4 16:30:47 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 04 Mar 2015 16:30:47 +0000
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F71EB8.3030109@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
	<54F71EB8.3030109@oracle.com>
Message-ID: <54F73337.3090309@oracle.com>

On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
> I believe all warnings are important to check! Unfortunately, this has 
> not been done for a lot of warnings for a lot of time. :(
Right, although in the past we had some areas close to be cleared of 
warnings, it's just that we didn't keep up the effort and of course the 
compilers get more pedantic with each version.

>
> With this framework, it is simple to enable a single warning, 
> recompile and see the effect. Hopefully this lowers the threshold far 
> enough so that all warnings are given proper attention. The 
> incremental build functionality will come in very handy. Just by 
> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a 
> library and running "make" again, only the files affected will be 
> recompiled.
Yes, it looks easy to maintain.


>
> I can easily paste in what warning categories are disabled for a 
> specific library, yes.
>
> However, if you are asking me to build each library, individually, 
> with warnings re-enabled, and pasting the output, I'd rather not. That 
> would be a lot of work, to detangle the output of each individual 
> library.
I'm not asking that, it would be too much work. Maybe it's worth saving 
the logs somewhere so that you can point the bugs at it. It would also 
be useful for the bugs to point to your change sets (when they are 
pushed) so that it's obvious which make files were changed to silence 
the warnings.

-Alan


From philip.race at oracle.com  Wed Mar  4 19:56:04 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 04 Mar 2015 11:56:04 -0800
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F70A22.6010607@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
	<54F70A22.6010607@oracle.com>
Message-ID: <54F76354.800@oracle.com>

Looks good to me. I like some of the clean up like :

-        if (getPeer() == null) {
+        if (!isDisplayable()) {

which is the same as we've told other folks to do ..

I was initially surprised at just using the field "peer" as it might
be null, but getPeer() just returned "peer" anyway, so no difference there.

-phil.


On 3/4/2015 5:35 AM, Sergey Bylokhov wrote:
> On 04.03.2015 15:51, Alan Bateman wrote:
>> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>> There are a number of public API whichreference the unsupported 
>>> java.awt.peer interfaces.
>>>
>>> public java.awt.Component.getPeer() @deprecated 1.1
>>> public java.awt.Font.getPeer() @deprecated 1.1
>>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>>
>> I don't know this area so I don't feel qualified to do a thorough 
>> review of the changes. However I welcome the changes, this is long 
>> standing technical debt and important that we address this as part of 
>> the move to modules.
>>
>> I note that Font::getPeer is changed to private, hence something try 
>> to access it outside of the Font class will get an IllegalAccessError 
>> as opposed to NoSuchMethodError for the outright removal in the other 
>> cases. Did you consider renaming to something else, say private 
>> FontPeer getFontPeer so that it is consistent with the removal of the 
>> other two methods?
> Make sense, I will update the fix.
>
>> I note that you might not have caught all tests but I would assume 
>> that any missed tests should fail. Perhaps there are other failures 
>> that are potentially hiding tests using getPeer?
> At least I fixed most(if not all) tests, which were passed before the 
> fix and fails after
>
>>
>> -Alan
>>
>
>



From philip.race at oracle.com  Wed Mar  4 21:31:34 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 04 Mar 2015 13:31:34 -0800
Subject: [OpenJDK 2D-Dev] <AWT Dev> RFR: JDK-8074096 Disable (most)
 native warnings in JDK on a per-library basis
In-Reply-To: <54F73337.3090309@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
	<54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com>
Message-ID: <54F779B6.1000503@oracle.com>

I like the overall approach.
We can then attack the warnings lib by lib and/or platform by platform.

I do want to mention that some libs like liblcms are 3rd party open 
source libraries
and it may not always be possible to convince upstream to change their code.

-phil.


On 03/04/2015 08:30 AM, Alan Bateman wrote:
> On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
>> I believe all warnings are important to check! Unfortunately, this 
>> has not been done for a lot of warnings for a lot of time. :(
> Right, although in the past we had some areas close to be cleared of 
> warnings, it's just that we didn't keep up the effort and of course 
> the compilers get more pedantic with each version.
>
>>
>> With this framework, it is simple to enable a single warning, 
>> recompile and see the effect. Hopefully this lowers the threshold far 
>> enough so that all warnings are given proper attention. The 
>> incremental build functionality will come in very handy. Just by 
>> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a 
>> library and running "make" again, only the files affected will be 
>> recompiled.
> Yes, it looks easy to maintain.
>
>
>>
>> I can easily paste in what warning categories are disabled for a 
>> specific library, yes.
>>
>> However, if you are asking me to build each library, individually, 
>> with warnings re-enabled, and pasting the output, I'd rather not. 
>> That would be a lot of work, to detangle the output of each 
>> individual library.
> I'm not asking that, it would be too much work. Maybe it's worth 
> saving the logs somewhere so that you can point the bugs at it. It 
> would also be useful for the bugs to point to your change sets (when 
> they are pushed) so that it's obvious which make files were changed to 
> silence the warnings.
>
> -Alan



From vadim.pakhnushev at oracle.com  Wed Mar  4 22:30:59 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Thu, 05 Mar 2015 01:30:59 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: 8074028 Remove
 API references to java.awt.peer
In-Reply-To: <54F6FC98.5030303@oracle.com>
References: <54F6FC98.5030303@oracle.com>
Message-ID: <54F787A3.8060407@oracle.com>

On 04/03/15 15:37, Sergey Bylokhov wrote:
> http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/MenuComponent.java.sdiff.html 
>
What's the point of ComponentPeer peer = this.peer; ?
Why not just use peer as in other places in this file?

Thanks,
Vadim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150305/c57b62ec/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Mar  5 12:51:57 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 05 Mar 2015 15:51:57 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F6FFE5.2070405@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
Message-ID: <54F8516D.7060809@oracle.com>

The new version of the fix:
http://cr.openjdk.java.net/~serb/8074028/webrev.06
Font.getPeer() was renamed to Font.getFontPeer().


On 04.03.2015 15:51, Alan Bateman wrote:
> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 9.
>> There are a number of public API whichreference the unsupported 
>> java.awt.peer interfaces.
>>
>> public java.awt.Component.getPeer() @deprecated 1.1
>> public java.awt.Font.getPeer() @deprecated 1.1
>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>
> I don't know this area so I don't feel qualified to do a thorough 
> review of the changes. However I welcome the changes, this is long 
> standing technical debt and important that we address this as part of 
> the move to modules.
>
> I note that Font::getPeer is changed to private, hence something try 
> to access it outside of the Font class will get an IllegalAccessError 
> as opposed to NoSuchMethodError for the outright removal in the other 
> cases. Did you consider renaming to something else, say private 
> FontPeer getFontPeer so that it is consistent with the removal of the 
> other two methods?
>
> I note that you might not have caught all tests but I would assume 
> that any missed tests should fail. Perhaps there are other failures 
> that are potentially hiding tests using getPeer?
>
> -Alan
>


-- 
Best regards, Sergey.



From Alan.Bateman at oracle.com  Thu Mar  5 12:57:54 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 05 Mar 2015 12:57:54 +0000
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F8516D.7060809@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
	<54F8516D.7060809@oracle.com>
Message-ID: <54F852D2.8030709@oracle.com>

On 05/03/2015 12:51, Sergey Bylokhov wrote:
> The new version of the fix:
> http://cr.openjdk.java.net/~serb/8074028/webrev.06
> Font.getPeer() was renamed to Font.getFontPeer().
>
This part looks good to me. I assume someone working in this area will 
give the rest of the changes a thorough review.

-Alan


From james.graham at oracle.com  Thu Mar  5 22:50:43 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 05 Mar 2015 14:50:43 -0800
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAGUMyaSA1ywbLQ0H2NrH4bNe=GORWVXyodR3i+oH+eiRwHXyAQ@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT66uSkoMkOOaUv4mV8GGxJuhRvSbtTS0PRYh8=BciT0JQ@mail.gmail.com>
	<CAGUMyaSA1ywbLQ0H2NrH4bNe=GORWVXyodR3i+oH+eiRwHXyAQ@mail.gmail.com>
Message-ID: <54F8DDC3.5010102@oracle.com>

Some progress!  It looks like Laurent is now an official committer to 
the graphics-rasterizer project!

http://openjdk.java.net/census#lbourges

Have you gotten access to http://cr.openjdk.java.net/~lbourges/ yet?

			...jim

On 2/26/15 2:41 AM, Mario Torre wrote:
> Hi Laurent,
>
> Let's move the process forward so that you can become an Author, at
> that point you'll be able to file bug reports and create webrevs:
>
> http://openjdk.java.net/projects/#project-author
>
> I don't know what was decided regarding the specific project, but
> since Jim is lead of the rasteriser project and I believe the general
> consensus was for you to start from there, this may be the appropriate
> forum, here are some links:
>
> http://openjdk.java.net/census#graphics-rasterizer
>
> http://openjdk.java.net/projects/graphics-rasterizer/
>
> http://mail.openjdk.java.net/mailman/listinfo/graphics-rasterizer-dev
>
> As soon as this process is done, you'll be finally free from a lot of
> this crazy overhead :)
>
> @Jim, @Phil is that right?
>
> Cheers,
> Mario
>
> 2015-02-26 9:31 GMT+01:00 Laurent Bourg?s <bourges.laurent at gmail.com>:
>> Jim,
>>
>> I made a Path2D patch but I sent the webrev by email.
>> Did you got it ? Could you review it ?
>>
>> I got a size limit issue: Your message to 2d-dev awaits moderator approval !
>>
>> Looking forward having an openjdk id ro push my webrev to cr.openjdk.net !
>>
>> Regards,
>> Laurent
>>
>> Le 25 f?vr. 2015 02:06, "Jim Graham" <james.graham at oracle.com> a ?crit :
>>>
>>> Those changes were exactly what I was referring to.  I don't see why we
>>> shouldn't make trimmed arrays when copying the shape.  I'm pretty sure that
>>> the copy constructors are going to be overwhelmingly used to make a
>>> protected copy of an existing shape/path2d which is likely meant mostly for
>>> reading.  In particular, in the case of the return value from
>>> createStrokedShape() I don't think the intention is to create the shape and
>>> then scribble on it, the intent is to treat the answer as if it were
>>> immutable - at least the 99.9% case - so I think a perfectly sized shape is
>>> OK.
>>>
>>> Be sure to add a test case that creates an empty Path2D, clones it, copy
>>> constructs it (to both .Double() and .Float() variants) and then tries to
>>> add new segments to it - to make sure that the array growth code doesn't get
>>> ArrayIndexOutOfBounds exceptions due to making assumptions about the lengths
>>> of the arrays (I eyeballed the makeRoom() code and it looks good, but we
>>> should test it if we are making arrays that are potentially zero length or
>>> very tiny)...
>>>
>>>                          ...jim
>>>
>>> On 2/24/15 9:58 AM, Laurent Bourg?s wrote:
>>>>
>>>> Jim,
>>>>
>>>>> Ah, wait, those constructors do copy the arrays without having to
>>>>> iterate the segments and grow the arrays, but they don't trim them.  I'm
>>>>> trying to remember if there was a specific reason that we decided not to
>>>>> trim the arrays in those constructors, but the only "advantage" I can think
>>>>> of is that the new copy will have the same potential spare room for growth
>>>>> that the original had.  But that is of questionable value so we should
>>>>> probably just patch the existing "construct from a Shape" constructors to
>>>>> trim the arrays to the required length instead...
>>>>
>>>>
>>>> In marlin github, I have the patched Path2D class (not used at runtime):
>>>>
>>>> public Float(Shape s, AffineTransform at) {
>>>>               super(); // LBO: invoke empty constructor explicitely !
>>>>               if (s instanceof Path2D) {
>>>>                   Path2D p2d = (Path2D) s;
>>>>                   setWindingRule(p2d.windingRule);
>>>>                   this.numTypes = p2d.numTypes;
>>>>                   // LBO: trim arrays:
>>>>                   this.pointTypes = Arrays.copyOf(p2d.pointTypes,
>>>> this.numTypes);
>>>> // this.pointTypes = Arrays.copyOf(p2d.pointTypes,
>>>> // p2d.pointTypes.length);
>>>>                   this.numCoords = p2d.numCoords;
>>>>                   this.floatCoords = p2d.cloneCoordsFloat(at);
>>>>               } else {
>>>>                   PathIterator pi = s.getPathIterator(at);
>>>>                   setWindingRule(pi.getWindingRule());
>>>>                   this.pointTypes = new byte[INIT_SIZE];
>>>>                   this.floatCoords = new float[INIT_SIZE * 2];
>>>>                   append(pi, false);
>>>>               }
>>>>           }
>>>>
>>>> float[] cloneCoordsFloat(AffineTransform at) {
>>>>               float ret[];
>>>>               if (at == null) {
>>>>                   // LBO: trim arrays:
>>>>                   ret = Arrays.copyOf(floatCoords, numCoords);
>>>> // ret = Arrays.copyOf(this.floatCoords, this.floatCoords.length);
>>>>               } else {
>>>>                   // LBO: trim arrays:
>>>>                   ret = new float[numCoords];
>>>> // ret = new float[floatCoords.length];
>>>>                   at.transform(floatCoords, 0, ret, 0, numCoords / 2);
>>>>               }
>>>>               return ret;
>>>>           }
>>>>
>>>> What do you think?
>>>>
>>>> FYI my use case in createStrokedShape () is to allocate (and reuse) a
>>>> path2d (4k arrays), fill it and then return a new path whose arrays are
>>>> trimmed.
>>>>
>>>> Laurent
>>>>
>>
>
>
>


From kevin.rushforth at oracle.com  Thu Mar  5 23:13:10 2015
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 05 Mar 2015 15:13:10 -0800
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
 references to java.awt.peer
In-Reply-To: <54F8516D.7060809@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
	<54F8516D.7060809@oracle.com>
Message-ID: <54F8E306.7090007@oracle.com>

I verified that this doesn't break JavaFX Swing interop (specifically 
Drag and Drop), so it looks fine to me.

-- Kevin


Sergey Bylokhov wrote:
> The new version of the fix:
> http://cr.openjdk.java.net/~serb/8074028/webrev.06
> Font.getPeer() was renamed to Font.getFontPeer().
>
>
> On 04.03.2015 15:51, Alan Bateman wrote:
>> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>> There are a number of public API whichreference the unsupported 
>>> java.awt.peer interfaces.
>>>
>>> public java.awt.Component.getPeer() @deprecated 1.1
>>> public java.awt.Font.getPeer() @deprecated 1.1
>>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>>
>> I don't know this area so I don't feel qualified to do a thorough 
>> review of the changes. However I welcome the changes, this is long 
>> standing technical debt and important that we address this as part of 
>> the move to modules.
>>
>> I note that Font::getPeer is changed to private, hence something try 
>> to access it outside of the Font class will get an IllegalAccessError 
>> as opposed to NoSuchMethodError for the outright removal in the other 
>> cases. Did you consider renaming to something else, say private 
>> FontPeer getFontPeer so that it is consistent with the removal of the 
>> other two methods?
>>
>> I note that you might not have caught all tests but I would assume 
>> that any missed tests should fail. Perhaps there are other failures 
>> that are potentially hiding tests using getPeer?
>>
>> -Alan
>>
>
>


From neugens.limasoftware at gmail.com  Thu Mar  5 23:20:55 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Fri, 6 Mar 2015 00:20:55 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <54F8DDC3.5010102@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT66uSkoMkOOaUv4mV8GGxJuhRvSbtTS0PRYh8=BciT0JQ@mail.gmail.com>
	<CAGUMyaSA1ywbLQ0H2NrH4bNe=GORWVXyodR3i+oH+eiRwHXyAQ@mail.gmail.com>
	<54F8DDC3.5010102@oracle.com>
Message-ID: <CAGUMyaS=B-a7Qxw4dmMDyo_nTFwR49VcPHL0ph2Xyx2rvQsENQ@mail.gmail.com>

Congratulations!

Cheers,
Mario

2015-03-05 23:50 GMT+01:00 Jim Graham <james.graham at oracle.com>:
> Some progress!  It looks like Laurent is now an official committer to the
> graphics-rasterizer project!
>
> http://openjdk.java.net/census#lbourges
>
> Have you gotten access to http://cr.openjdk.java.net/~lbourges/ yet?
>
>                         ...jim
>
>
> On 2/26/15 2:41 AM, Mario Torre wrote:
>>
>> Hi Laurent,
>>
>> Let's move the process forward so that you can become an Author, at
>> that point you'll be able to file bug reports and create webrevs:
>>
>> http://openjdk.java.net/projects/#project-author
>>
>> I don't know what was decided regarding the specific project, but
>> since Jim is lead of the rasteriser project and I believe the general
>> consensus was for you to start from there, this may be the appropriate
>> forum, here are some links:
>>
>> http://openjdk.java.net/census#graphics-rasterizer
>>
>> http://openjdk.java.net/projects/graphics-rasterizer/
>>
>> http://mail.openjdk.java.net/mailman/listinfo/graphics-rasterizer-dev
>>
>> As soon as this process is done, you'll be finally free from a lot of
>> this crazy overhead :)
>>
>> @Jim, @Phil is that right?
>>
>> Cheers,
>> Mario
>>
>> 2015-02-26 9:31 GMT+01:00 Laurent Bourg?s <bourges.laurent at gmail.com>:
>>>
>>> Jim,
>>>
>>> I made a Path2D patch but I sent the webrev by email.
>>> Did you got it ? Could you review it ?
>>>
>>> I got a size limit issue: Your message to 2d-dev awaits moderator
>>> approval !
>>>
>>> Looking forward having an openjdk id ro push my webrev to cr.openjdk.net
>>> !
>>>
>>> Regards,
>>> Laurent
>>>
>>> Le 25 f?vr. 2015 02:06, "Jim Graham" <james.graham at oracle.com> a ?crit :
>>>>
>>>>
>>>> Those changes were exactly what I was referring to.  I don't see why we
>>>> shouldn't make trimmed arrays when copying the shape.  I'm pretty sure
>>>> that
>>>> the copy constructors are going to be overwhelmingly used to make a
>>>> protected copy of an existing shape/path2d which is likely meant mostly
>>>> for
>>>> reading.  In particular, in the case of the return value from
>>>> createStrokedShape() I don't think the intention is to create the shape
>>>> and
>>>> then scribble on it, the intent is to treat the answer as if it were
>>>> immutable - at least the 99.9% case - so I think a perfectly sized shape
>>>> is
>>>> OK.
>>>>
>>>> Be sure to add a test case that creates an empty Path2D, clones it, copy
>>>> constructs it (to both .Double() and .Float() variants) and then tries
>>>> to
>>>> add new segments to it - to make sure that the array growth code doesn't
>>>> get
>>>> ArrayIndexOutOfBounds exceptions due to making assumptions about the
>>>> lengths
>>>> of the arrays (I eyeballed the makeRoom() code and it looks good, but we
>>>> should test it if we are making arrays that are potentially zero length
>>>> or
>>>> very tiny)...
>>>>
>>>>                          ...jim
>>>>
>>>> On 2/24/15 9:58 AM, Laurent Bourg?s wrote:
>>>>>
>>>>>
>>>>> Jim,
>>>>>
>>>>>> Ah, wait, those constructors do copy the arrays without having to
>>>>>> iterate the segments and grow the arrays, but they don't trim them.
>>>>>> I'm
>>>>>> trying to remember if there was a specific reason that we decided not
>>>>>> to
>>>>>> trim the arrays in those constructors, but the only "advantage" I can
>>>>>> think
>>>>>> of is that the new copy will have the same potential spare room for
>>>>>> growth
>>>>>> that the original had.  But that is of questionable value so we should
>>>>>> probably just patch the existing "construct from a Shape" constructors
>>>>>> to
>>>>>> trim the arrays to the required length instead...
>>>>>
>>>>>
>>>>>
>>>>> In marlin github, I have the patched Path2D class (not used at
>>>>> runtime):
>>>>>
>>>>> public Float(Shape s, AffineTransform at) {
>>>>>               super(); // LBO: invoke empty constructor explicitely !
>>>>>               if (s instanceof Path2D) {
>>>>>                   Path2D p2d = (Path2D) s;
>>>>>                   setWindingRule(p2d.windingRule);
>>>>>                   this.numTypes = p2d.numTypes;
>>>>>                   // LBO: trim arrays:
>>>>>                   this.pointTypes = Arrays.copyOf(p2d.pointTypes,
>>>>> this.numTypes);
>>>>> // this.pointTypes = Arrays.copyOf(p2d.pointTypes,
>>>>> // p2d.pointTypes.length);
>>>>>                   this.numCoords = p2d.numCoords;
>>>>>                   this.floatCoords = p2d.cloneCoordsFloat(at);
>>>>>               } else {
>>>>>                   PathIterator pi = s.getPathIterator(at);
>>>>>                   setWindingRule(pi.getWindingRule());
>>>>>                   this.pointTypes = new byte[INIT_SIZE];
>>>>>                   this.floatCoords = new float[INIT_SIZE * 2];
>>>>>                   append(pi, false);
>>>>>               }
>>>>>           }
>>>>>
>>>>> float[] cloneCoordsFloat(AffineTransform at) {
>>>>>               float ret[];
>>>>>               if (at == null) {
>>>>>                   // LBO: trim arrays:
>>>>>                   ret = Arrays.copyOf(floatCoords, numCoords);
>>>>> // ret = Arrays.copyOf(this.floatCoords, this.floatCoords.length);
>>>>>               } else {
>>>>>                   // LBO: trim arrays:
>>>>>                   ret = new float[numCoords];
>>>>> // ret = new float[floatCoords.length];
>>>>>                   at.transform(floatCoords, 0, ret, 0, numCoords / 2);
>>>>>               }
>>>>>               return ret;
>>>>>           }
>>>>>
>>>>> What do you think?
>>>>>
>>>>> FYI my use case in createStrokedShape () is to allocate (and reuse) a
>>>>> path2d (4k arrays), fill it and then return a new path whose arrays are
>>>>> trimmed.
>>>>>
>>>>> Laurent
>>>>>
>>>
>>
>>
>>
>



-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

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

Please, support open standards:
http://endsoftpatents.org/


From steven.loomis at oracle.com  Thu Mar  5 23:28:16 2015
From: steven.loomis at oracle.com (Steven Loomis)
Date: Thu, 05 Mar 2015 15:28:16 -0800
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8068619) - remove internal layout
 function to match ICU and harfbuzz
In-Reply-To: <54EF7179.207@oracle.com>
References: <54EF7179.207@oracle.com>
Message-ID: <54F8E690.4020108@oracle.com>

Bug:https://bugs.openjdk.java.net/browse/JDK-8068619
webrev:http://cr.openjdk.java.net/~srl/8068619/webrev.3/

No change from before, just using cr.openjdk.java.net to host

NB ICU (and Harfbuzz) have already applied this change.
-s

On 2/26/2015 11:18 AM, Steven Loomis wrote:
> Should be a fairly simple request, deletes a function (unused by the 
> JDK) which was removed from ICU and harfbuzz for security purposes.
> cc: to the harfbuzz-dev list, I am requesting to land this in jdk9 
> first as it is not strictly harfbuzz related.
>
> To be removed:
>
>     virtual const void *LEFontInstance::getFontTable(LETag tableTag) 
> const = 0;
>
> This version returns the address of memory without any size indication.
>
> Rationale is for syncup with ICU and with Harfbuzz's version of this API.
> The version used by the JDK takes a size_t length.
> Again this function is NOT called  anywhere in the JDK, and is 
> internal as far as JDK's API goes.
>
>
> Bug:https://bugs.openjdk.java.net/browse/JDK-8068619
>
> cr.openjdk.java.net locked me out after one successful post.  So the 
> main .h change  is at this URL: 
> http://cr.openjdk.java.net/~srl/8068619/webrev.0/
>
> And the complete patch ( webrev.2) is below.. I will repost it to cr 
> once cr lets me back in.
>
> ------------------
>
> --- 
> old/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.cpp 
> 2015-02-26 11:12:45.113980779 -0800
> +++ 
> new/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.cpp 
> 2015-02-26 11:12:44.974981686 -0800
> @@ -67,12 +67,6 @@
>  };
>
>
> -const void *FontInstanceAdapter::getFontTable(LETag tableTag) const
> -{
> -  size_t ignored = 0;
> -  return getFontTable(tableTag, ignored);
> -}
> -
>  static const LETag cacheMap[LAYOUTCACHE_ENTRIES] = {
>    GPOS_TAG, GDEF_TAG, GSUB_TAG, MORT_TAG, MORX_TAG, KERN_TAG
>  };
> --- 
> old/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.h 
> 2015-02-26 11:12:45.548977941 -0800
> +++ 
> new/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.h 
> 2015-02-26 11:12:45.394978946 -0800
> @@ -85,7 +85,6 @@
>
>      // tables are cached with the native font scaler data
>      // only supports gsub, gpos, gdef, mort tables at present
> -    virtual const void *getFontTable(LETag tableTag) const;
>      virtual const void *getFontTable(LETag tableTag, size_t &len) const;
>
>      virtual void *getKernPairs() const {
> --- 
> old/jdk/src/java.desktop/share/native/libfontmanager/layout/LEFontInstance.h 
> 2015-02-26 11:12:46.042974718 -0800
> +++ 
> new/jdk/src/java.desktop/share/native/libfontmanager/layout/LEFontInstance.h 
> 2015-02-26 11:12:45.881975768 -0800
> @@ -181,28 +181,6 @@
>       *
>       * Subclasses which represent composite fonts should always 
> return <code>NULL</code>.
>       *
> -     * Note that implementing this function does not allow for range 
> checking.
> -     * Subclasses that desire the safety of range checking must 
> implement the
> -     * variation which has a length parameter.
> -     *
> -     * @param tableTag - the four byte table tag. (e.g. 'cmap')
> -     *
> -     * @return the address of the table in memory, or <code>NULL</code>
> -     *         if the table doesn't exist.
> -     *
> -     * @stable ICU 2.8
> -     */
> -    virtual const void *getFontTable(LETag tableTag) const = 0;
> -
> -    /**
> -     * This method reads a table from the font. Note that in general,
> -     * it only makes sense to call this method on an 
> <code>LEFontInstance</code>
> -     * which represents a physical font - i.e. one which has been 
> returned by
> -     * <code>getSubFont()</code>. This is because each subfont in a 
> composite font
> -     * will have different tables, and there's no way to know which 
> subfont to access.
> -     *
> -     * Subclasses which represent composite fonts should always 
> return <code>NULL</code>.
> -     *
>       * This version sets a length, for range checking.
>       * Note that range checking can only be accomplished if this 
> function is
>       * implemented in subclasses.
> @@ -213,7 +191,7 @@
>       *         if the table doesn't exist.
>       * @internal
>       */
> -    virtual const void* getFontTable(LETag tableTag, size_t &length) 
> const { length=-1; return getFontTable(tableTag); } /* -1 = unknown 
> length */
> +    virtual const void* getFontTable(LETag tableTag, size_t &length) 
> const = 0;
>
>      virtual void *getKernPairs() const = 0;
>      virtual void  setKernPairs(void *pairs) const = 0;



From philip.race at oracle.com  Thu Mar  5 23:33:01 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 05 Mar 2015 15:33:01 -0800
Subject: [OpenJDK 2D-Dev] RFR: (JDK-8068619) - remove internal layout
 function to match ICU and harfbuzz
In-Reply-To: <54F8E690.4020108@oracle.com>
References: <54EF7179.207@oracle.com> <54F8E690.4020108@oracle.com>
Message-ID: <54F8E7AD.80705@oracle.com>

+1

-phil.

On 3/5/2015 3:28 PM, Steven Loomis wrote:
> Bug:https://bugs.openjdk.java.net/browse/JDK-8068619
> webrev:http://cr.openjdk.java.net/~srl/8068619/webrev.3/
>
> No change from before, just using cr.openjdk.java.net to host
>
> NB ICU (and Harfbuzz) have already applied this change.
> -s
>
> On 2/26/2015 11:18 AM, Steven Loomis wrote:
>> Should be a fairly simple request, deletes a function (unused by the 
>> JDK) which was removed from ICU and harfbuzz for security purposes.
>> cc: to the harfbuzz-dev list, I am requesting to land this in jdk9 
>> first as it is not strictly harfbuzz related.
>>
>> To be removed:
>>
>>     virtual const void *LEFontInstance::getFontTable(LETag tableTag) 
>> const = 0;
>>
>> This version returns the address of memory without any size indication.
>>
>> Rationale is for syncup with ICU and with Harfbuzz's version of this 
>> API.
>> The version used by the JDK takes a size_t length.
>> Again this function is NOT called  anywhere in the JDK, and is 
>> internal as far as JDK's API goes.
>>
>>
>> Bug:https://bugs.openjdk.java.net/browse/JDK-8068619
>>
>> cr.openjdk.java.net locked me out after one successful post.  So the 
>> main .h change  is at this URL: 
>> http://cr.openjdk.java.net/~srl/8068619/webrev.0/
>>
>> And the complete patch ( webrev.2) is below.. I will repost it to cr 
>> once cr lets me back in.
>>
>> ------------------
>>
>> --- 
>> old/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.cpp 
>> 2015-02-26 11:12:45.113980779 -0800
>> +++ 
>> new/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.cpp 
>> 2015-02-26 11:12:44.974981686 -0800
>> @@ -67,12 +67,6 @@
>>  };
>>
>>
>> -const void *FontInstanceAdapter::getFontTable(LETag tableTag) const
>> -{
>> -  size_t ignored = 0;
>> -  return getFontTable(tableTag, ignored);
>> -}
>> -
>>  static const LETag cacheMap[LAYOUTCACHE_ENTRIES] = {
>>    GPOS_TAG, GDEF_TAG, GSUB_TAG, MORT_TAG, MORX_TAG, KERN_TAG
>>  };
>> --- 
>> old/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.h 
>> 2015-02-26 11:12:45.548977941 -0800
>> +++ 
>> new/jdk/src/java.desktop/share/native/libfontmanager/FontInstanceAdapter.h 
>> 2015-02-26 11:12:45.394978946 -0800
>> @@ -85,7 +85,6 @@
>>
>>      // tables are cached with the native font scaler data
>>      // only supports gsub, gpos, gdef, mort tables at present
>> -    virtual const void *getFontTable(LETag tableTag) const;
>>      virtual const void *getFontTable(LETag tableTag, size_t &len) 
>> const;
>>
>>      virtual void *getKernPairs() const {
>> --- 
>> old/jdk/src/java.desktop/share/native/libfontmanager/layout/LEFontInstance.h 
>> 2015-02-26 11:12:46.042974718 -0800
>> +++ 
>> new/jdk/src/java.desktop/share/native/libfontmanager/layout/LEFontInstance.h 
>> 2015-02-26 11:12:45.881975768 -0800
>> @@ -181,28 +181,6 @@
>>       *
>>       * Subclasses which represent composite fonts should always 
>> return <code>NULL</code>.
>>       *
>> -     * Note that implementing this function does not allow for range 
>> checking.
>> -     * Subclasses that desire the safety of range checking must 
>> implement the
>> -     * variation which has a length parameter.
>> -     *
>> -     * @param tableTag - the four byte table tag. (e.g. 'cmap')
>> -     *
>> -     * @return the address of the table in memory, or <code>NULL</code>
>> -     *         if the table doesn't exist.
>> -     *
>> -     * @stable ICU 2.8
>> -     */
>> -    virtual const void *getFontTable(LETag tableTag) const = 0;
>> -
>> -    /**
>> -     * This method reads a table from the font. Note that in general,
>> -     * it only makes sense to call this method on an 
>> <code>LEFontInstance</code>
>> -     * which represents a physical font - i.e. one which has been 
>> returned by
>> -     * <code>getSubFont()</code>. This is because each subfont in a 
>> composite font
>> -     * will have different tables, and there's no way to know which 
>> subfont to access.
>> -     *
>> -     * Subclasses which represent composite fonts should always 
>> return <code>NULL</code>.
>> -     *
>>       * This version sets a length, for range checking.
>>       * Note that range checking can only be accomplished if this 
>> function is
>>       * implemented in subclasses.
>> @@ -213,7 +191,7 @@
>>       *         if the table doesn't exist.
>>       * @internal
>>       */
>> -    virtual const void* getFontTable(LETag tableTag, size_t &length) 
>> const { length=-1; return getFontTable(tableTag); } /* -1 = unknown 
>> length */
>> +    virtual const void* getFontTable(LETag tableTag, size_t &length) 
>> const = 0;
>>
>>      virtual void *getKernPairs() const = 0;
>>      virtual void  setKernPairs(void *pairs) const = 0;
>



From bourges.laurent at gmail.com  Fri Mar  6 07:56:55 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 6 Mar 2015 08:56:55 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <54F8DDC3.5010102@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT66uSkoMkOOaUv4mV8GGxJuhRvSbtTS0PRYh8=BciT0JQ@mail.gmail.com>
	<CAGUMyaSA1ywbLQ0H2NrH4bNe=GORWVXyodR3i+oH+eiRwHXyAQ@mail.gmail.com>
	<54F8DDC3.5010102@oracle.com>
Message-ID: <CAKjRUT7t+B404NEUzKzsykHuL3jb8z1oZHE8N1fazdhq0OfwnQ@mail.gmail.com>

Jim,

2015-03-05 23:50 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> Some progress!  It looks like Laurent is now an official committer to the
> graphics-rasterizer project!
>
> http://openjdk.java.net/census#lbourges
>

Yes it is great !


>
> Have you gotten access to http://cr.openjdk.java.net/~lbourges/ yet?
>

Still not, my public key is rejected:
ssh -v lbourges at cr.openjdk.java.net
...
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/bourgesl/.ssh/openjdk
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

However, it seems working with hg.openjdk.java.net.


I would like to publish both Path2D and Marlin webrevs asap.

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/57ab5d39/attachment.html>

From anton.tarasov at oracle.com  Fri Mar  6 15:01:14 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Fri, 06 Mar 2015 18:01:14 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F6FC98.5030303@oracle.com>
References: <54F6FC98.5030303@oracle.com>
Message-ID: <54F9C13A.6060408@oracle.com>

Hi Sergey,

Looks good to me.

Thanks,
Anton.

On 04/03/15 15:37, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 9.
> There are a number of public API whichreference the unsupported 
> java.awt.peer interfaces.
>
> public java.awt.Component.getPeer() @deprecated 1.1
> public java.awt.Font.getPeer() @deprecated 1.1
> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>
> There is a decision to remove this methods as described: 
> http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html
>
> Most important changes:
> http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/Component.java.sdiff.html 
>
> -    /**
> -     * @deprecated As of JDK version 1.1,
> -     * programs should not directly manipulate peers;
> -     * replaced by <code>boolean isDisplayable()</code>.
> -     * @return the peer for this component
> -     */
> -    @Deprecated
> -    public ComponentPeer getPeer() {
> -        return peer;
> -    }
>
> Component.getPeer was removed and its usage was replaced by:
>  - dirrect access to the field if possible
>  - (getPeer() !=/== null) is replaced by the isDisplayable()
>  - All other places now use an AWTAccessor.
>
> http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/MenuComponent.java.sdiff.html 
>
> -    /**
> -     * @deprecated As of JDK version 1.1,
> -     * programs should not directly manipulate peers.
> -     * @return the peer for this component
> -     */
> -    @Deprecated
> -    public MenuComponentPeer getPeer() {
> -        return peer;
> -    }
>
> MenuComponentPeer.getPeer was removed, now we use an AWTAccessor instead.
>
> http://cr.openjdk.java.net/~serb/8074028/webrev.05/src/java.desktop/share/classes/java/awt/Font.java.sdiff.html 
>
> Font.getPeer() access was changed to the private, because it is not 
> simple getter, and it is used in native code. On the java side now we 
> use an AWTAccessor.
>
> Also I tried to fix the open tests, but not sure that I cover all of 
> them. I'll fix other tests in the separate CR.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074028
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8074028/webrev.05
>



From anton.tarasov at oracle.com  Fri Mar  6 15:05:59 2015
From: anton.tarasov at oracle.com (Anton Tarasov)
Date: Fri, 06 Mar 2015 18:05:59 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
 references to java.awt.peer
In-Reply-To: <54F8E306.7090007@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
	<54F8516D.7060809@oracle.com> <54F8E306.7090007@oracle.com>
Message-ID: <54F9C257.9000602@oracle.com>

Thanks for the check, Kevin!

Anton.

On 06/03/15 02:13, Kevin Rushforth wrote:
> I verified that this doesn't break JavaFX Swing interop (specifically 
> Drag and Drop), so it looks fine to me.
>
> -- Kevin
>
>
> Sergey Bylokhov wrote:
>> The new version of the fix:
>> http://cr.openjdk.java.net/~serb/8074028/webrev.06
>> Font.getPeer() was renamed to Font.getFontPeer().
>>
>>
>> On 04.03.2015 15:51, Alan Bateman wrote:
>>> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review the fix for jdk 9.
>>>> There are a number of public API whichreference the unsupported 
>>>> java.awt.peer interfaces.
>>>>
>>>> public java.awt.Component.getPeer() @deprecated 1.1
>>>> public java.awt.Font.getPeer() @deprecated 1.1
>>>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>>>
>>> I don't know this area so I don't feel qualified to do a thorough 
>>> review of the changes. However I welcome the changes, this is long 
>>> standing technical debt and important that we address this as part 
>>> of the move to modules.
>>>
>>> I note that Font::getPeer is changed to private, hence something try 
>>> to access it outside of the Font class will get an 
>>> IllegalAccessError as opposed to NoSuchMethodError for the outright 
>>> removal in the other cases. Did you consider renaming to something 
>>> else, say private FontPeer getFontPeer so that it is consistent with 
>>> the removal of the other two methods?
>>>
>>> I note that you might not have caught all tests but I would assume 
>>> that any missed tests should fail. Perhaps there are other failures 
>>> that are potentially hiding tests using getPeer?
>>>
>>> -Alan
>>>
>>
>>



From magnus.ihse.bursie at oracle.com  Fri Mar  6 16:13:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 06 Mar 2015 17:13:09 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F73337.3090309@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70D42.3010905@oracle.com>
	<54F71EB8.3030109@oracle.com> <54F73337.3090309@oracle.com>
Message-ID: <54F9D215.8090806@oracle.com>

On 2015-03-04 17:30, Alan Bateman wrote:
> On 04/03/2015 15:03, Magnus Ihse Bursie wrote:
>> I believe all warnings are important to check! Unfortunately, this 
>> has not been done for a lot of warnings for a lot of time. :(
> Right, although in the past we had some areas close to be cleared of 
> warnings, it's just that we didn't keep up the effort and of course 
> the compilers get more pedantic with each version.
>
>>
>> With this framework, it is simple to enable a single warning, 
>> recompile and see the effect. Hopefully this lowers the threshold far 
>> enough so that all warnings are given proper attention. The 
>> incremental build functionality will come in very handy. Just by 
>> simply removing a warning from the DISABLED_WARNINGS_<toolchain> on a 
>> library and running "make" again, only the files affected will be 
>> recompiled.
> Yes, it looks easy to maintain.
>
>
>>
>> I can easily paste in what warning categories are disabled for a 
>> specific library, yes.
>>
>> However, if you are asking me to build each library, individually, 
>> with warnings re-enabled, and pasting the output, I'd rather not. 
>> That would be a lot of work, to detangle the output of each 
>> individual library.
> I'm not asking that, it would be too much work. Maybe it's worth 
> saving the logs somewhere so that you can point the bugs at it. It 
> would also be useful for the bugs to point to your change sets (when 
> they are pushed) so that it's obvious which make files were changed to 
> silence the warnings.

I'll try to locate a suitable way of storing the logs, and record a 
pointer to that in the bugs. I'll also link to the change set in the 
bugs as you request.

/Magnus

>
> -Alan



From magnus.ihse.bursie at oracle.com  Fri Mar  6 16:14:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 06 Mar 2015 17:14:57 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F70949.4040900@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com>
Message-ID: <54F9D281.3030206@oracle.com>

On 2015-03-04 14:31, Erik Joelsson wrote:
> Hello,
>
> Really nice to finally see this patch getting done!
>
> Only one comment:
>
> flags.m4:
> In the grep expression, could you move the extra [] outside of the 
> actual command line options to grep so that the command line could be 
> copied to the shell for debugging in the future? Also, how hard would 
> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead 
> test for capability?

I have updated the fix to use the eminent FLAGS_COMPILER_CHECK_ARGUMENTS 
instead. :-)

http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02

/Magnus



From bourges.laurent at gmail.com  Fri Mar  6 18:35:32 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 6 Mar 2015 19:35:32 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT6inPkSgTuLK7B5cZ1me=UPfkTkQehv-qtGfC0iD2pu5w@mail.gmail.com>
	<CAKjRUT7zRUPs8CFM-jAYw9VeTC+7O0SszuGy6n=a+ygfqBKQmw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
Message-ID: <CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>

Jim,

Here is my first "official" webrev (vs graphics-rasterizer forest)
concerning Path2D copy constructors:
http://cr.openjdk.java.net/~lbourges/webrev_Path2D_0/

this is a simple Path2D patch to trim arrays (numTypes & float/double
Coords) in copy constructors (Path2D.Float and Path2D.Double variants) with
the requested test: Path2DTrimCopy.

Please tell me if the test is correct as I do not run it with jtreg
(annotations ?)


>
> 2015-02-25 2:05 GMT+01:00 Jim Graham <james.graham at oracle.com>:
>
>> Those changes were exactly what I was referring to.  I don't see why we
>> shouldn't make trimmed arrays when copying the shape.  I'm pretty sure that
>> the copy constructors are going to be overwhelmingly used to make a
>> protected copy of an existing shape/path2d which is likely meant mostly for
>> reading.  In particular, in the case of the return value from
>> createStrokedShape() I don't think the intention is to create the shape and
>> then scribble on it, the intent is to treat the answer as if it were
>> immutable - at least the 99.9% case - so I think a perfectly sized shape is
>> OK.
>>
>> Be sure to add a test case that creates an empty Path2D, clones it, copy
>> constructs it (to both .Double() and .Float() variants) and then tries to
>> add new segments to it - to make sure that the array growth code doesn't
>> get ArrayIndexOutOfBounds exceptions due to making assumptions about the
>> lengths of the arrays (I eyeballed the makeRoom() code and it looks good,
>> but we should test it if we are making arrays that are potentially zero
>> length or very tiny)...
>>
>>
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/5a53fa03/attachment.html>

From philip.race at oracle.com  Fri Mar  6 19:06:02 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Mar 2015 11:06:02 -0800
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>	<54DF8F7F.5040700@redhat.com>	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>	<54E5CA9A.3090801@oracle.com>	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>	<54E5F25F.2020303@oracle.com>
	<1424361976.4253.41.camel@localhost>	<54E67B0A.8080508@oracle.com>	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>	<54E7846E.6000703@oracle.com>	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>	<54ECB5CD.8080602@oracle.com>
	<54ECB8B8.2010806@oracle.com>	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>	<54ED1FF2.3040209@oracle.com>	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
Message-ID: <54F9FA9A.1060705@oracle.com>

Hi,

you placed the test in the java.awt.geom package.

   25 package java.awt.geom;

and are accessing internals of that package.

In jigsaw/modular mode that won't even compile.

So the test should go in the anonymous package and avoid accessing 
internals.
It should be possible to use just public API  to verify the arrays  of a 
shape
being cloned are trimmed .

Why is it necessary to explicitly add the call to super(); ?

223             super();


-phil.


On 3/6/2015 10:35 AM, Laurent Bourg?s wrote:
> Jim,
>
> Here is my first "official" webrev (vs graphics-rasterizer forest) 
> concerning Path2D copy constructors:
> http://cr.openjdk.java.net/~lbourges/webrev_Path2D_0/ 
> <http://cr.openjdk.java.net/%7Elbourges/webrev_Path2D_0/>
>
> this is a simple Path2D patch to trim arrays (numTypes & float/double 
> Coords) in copy constructors (Path2D.Float and Path2D.Double variants) 
> with the requested test: Path2DTrimCopy.
>
> Please tell me if the test is correct as I do not run it with jtreg 
> (annotations ?)
>
>
>     2015-02-25 2:05 GMT+01:00 Jim Graham <james.graham at oracle.com
>     <mailto:james.graham at oracle.com>>:
>
>         Those changes were exactly what I was referring to.  I don't
>         see why we shouldn't make trimmed arrays when copying the
>         shape.  I'm pretty sure that the copy constructors are going
>         to be overwhelmingly used to make a protected copy of an
>         existing shape/path2d which is likely meant mostly for
>         reading. In particular, in the case of the return value from
>         createStrokedShape() I don't think the intention is to create
>         the shape and then scribble on it, the intent is to treat the
>         answer as if it were immutable - at least the 99.9% case - so
>         I think a perfectly sized shape is OK.
>
>         Be sure to add a test case that creates an empty Path2D,
>         clones it, copy constructs it (to both .Double() and .Float()
>         variants) and then tries to add new segments to it - to make
>         sure that the array growth code doesn't get
>         ArrayIndexOutOfBounds exceptions due to making assumptions
>         about the lengths of the arrays (I eyeballed the makeRoom()
>         code and it looks good, but we should test it if we are making
>         arrays that are potentially zero length or very tiny)...
>
>
> Laurent



From bourges.laurent at gmail.com  Fri Mar  6 20:37:03 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 6 Mar 2015 21:37:03 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <54F9FA9A.1060705@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
Message-ID: <CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>

Phil,

Thanks for your feedback !

2015-03-06 20:06 GMT+01:00 Phil Race <philip.race at oracle.com>:

> Hi,
>
> you placed the test in the java.awt.geom package.
>
>   25 package java.awt.geom;
>
> and are accessing internals of that package.
>
> In jigsaw/modular mode that won't even compile.
>

Ok it is annoying:
as all Path2D fields are package protected, I designed the test using
direct access to any fields ...


> So the test should go in the anonymous package and avoid accessing
> internals.
> It should be possible to use just public API  to verify the arrays  of a
> shape
> being cloned are trimmed .
>

No, it is not possible to use Shape API to access arrays nor fields
(numTypes ...):
only getPathIterator() could give me data but it won't tell me if the
underlying arrays or fields are correct.

Maybe I could use introspection to getDeclaredField(name) and
setAccessible(true) to get internal data.

Any idea or utility class I could use ?


>
> Why is it necessary to explicitly add the call to super(); ?
>
> 223             super();
>

I agree it is not necessary but it explicitely says that I use the empty
constructor:

    /**
     * Constructs a new empty {@code Path2D} object.
     * It is assumed that the package sibling subclass that is
     * defaulting to this constructor will fill in all values.
     *
     * @since 1.6
     */
    /* private protected */
    Path2D() {
    }

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/ce6b5a38/attachment.html>

From philip.race at oracle.com  Fri Mar  6 21:29:32 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Mar 2015 13:29:32 -0800
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
	<CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
Message-ID: <54FA1C3C.50104@oracle.com>

Hi,

On 03/06/2015 12:37 PM, Laurent Bourg?s wrote:
> Phil,
>
> Thanks for your feedback !
>
> 2015-03-06 20:06 GMT+01:00 Phil Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>>:
>
>     Hi,
>
>     you placed the test in the java.awt.geom package.
>
>       25 package java.awt.geom;
>
>     and are accessing internals of that package.
>
>     In jigsaw/modular mode that won't even compile.
>
>
> Ok it is annoying:
> as all Path2D fields are package protected, I designed the test using 
> direct access to any fields ...
>
>
>     So the test should go in the anonymous package and avoid accessing
>     internals.
>     It should be possible to use just public API  to verify the
>     arrays  of a shape
>     being cloned are trimmed .
>
>
> No, it is not possible to use Shape API to access arrays nor fields 
> (numTypes ...):
> only getPathIterator() could give me data but it won't tell me if the 
> underlying arrays or fields are correct.

That is true ..

Well, if you need it to be in java.awt.geom, I think even today you'll 
find it won't work
unless you jump through some jtreg hoops to install it on the bootclasspath.
I think its something like "@run main/othervm -Xbootclasspath/a:. "
And later in the modular JDK it will need to be modified again.

I'd say either update the test to work with jtreg today - and test it to 
be sure,
or provide the test without an @test tag, or with an @ignore tag, so 
people can
still manually verify it but the harness won't run it.

>
> Maybe I could use introspection to getDeclaredField(name) and 
> setAccessible(true) to get internal data.

That won't work either. So maybe this is a "noreg-hard" or 
"noreg-cleanup" bug.
We add those labels to the JBS/JIRA bug when something isn't testable.


>
> Any idea or utility class I could use

>
>     Why is it necessary to explicitly add the call to super(); ?
>
>     223             super();
>
>
> I agree it is not necessary but it explicitely says that I use the 
> empty constructor:
>
>     /**
>      * Constructs a new empty {@code Path2D} object.
>      * It is assumed that the package sibling subclass that is
>      * defaulting to this constructor will fill in all values.
>      *
>      * @since 1.6
>      */
>     /* private protected */
>     Path2D() {
>     }

If we all did this, all of the time, there'd be a lot of extra lines in 
the code, that the compiler
would fill in for us anyway.

-phil.

>
> Laurent
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/c595a8f3/attachment.html>

From bourges.laurent at gmail.com  Fri Mar  6 22:03:16 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 6 Mar 2015 23:03:16 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <54FA1C3C.50104@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
	<CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
	<54FA1C3C.50104@oracle.com>
Message-ID: <CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>

Phil,

Here is a new webrev:
http://cr.openjdk.java.net/~lbourges/webrev_Path2D_1/

See my comments below:

> you placed the test in the java.awt.geom package.
>>
>>   25 package java.awt.geom;
>>
>> and are accessing internals of that package.
>>
>> In jigsaw/modular mode that won't even compile.
>>
>
>  Ok it is annoying:
> as all Path2D fields are package protected, I designed the test using
> direct access to any fields ...
>
>
>> So the test should go in the anonymous package and avoid accessing
>> internals.
>> It should be possible to use just public API  to verify the arrays  of a
>> shape
>> being cloned are trimmed .
>>
>
>  No, it is not possible to use Shape API to access arrays nor fields
> (numTypes ...):
> only getPathIterator() could give me data but it won't tell me if the
> underlying arrays or fields are correct.
>
>
> That is true ..
>
> Well, if you need it to be in java.awt.geom, I think even today you'll
> find it won't work
> unless you jump through some jtreg hoops to install it on the
> bootclasspath.
> I think its something like "@run main/othervm -Xbootclasspath/a:. "
> And later in the modular JDK it will need to be modified again.
>
> I'd say either update the test to work with jtreg today - and test it to
> be sure,
> or provide the test without an @test tag, or with an @ignore tag, so
> people can
> still manually verify it but the harness won't run it.
>

I removed the @test tag but added comments indicating to run the test
manually.

>
>
>  Maybe I could use introspection to getDeclaredField(name) and
> setAccessible(true) to get internal data.
>
>
> That won't work either. So maybe this is a "noreg-hard" or "noreg-cleanup"
> bug.
> We add those labels to the JBS/JIRA bug when something isn't testable.
>

Nevermind.


>    Any idea or utility class I could use
>
>
>
>> Why is it necessary to explicitly add the call to super(); ?
>>
>> 223             super();
>>
>
>  I agree it is not necessary but it explicitely says that I use the empty
> constructor:
>
>     /**
>      * Constructs a new empty {@code Path2D} object.
>      * It is assumed that the package sibling subclass that is
>      * defaulting to this constructor will fill in all values.
>      *
>      * @since 1.6
>      */
>     /* private protected */
>     Path2D() {
>     }
>
>
> If we all did this, all of the time, there'd be a lot of extra lines in
> the code, that the compiler
> would fill in for us anyway.
>

I removed the superfluous super() calls.

Thanks for your review,

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/59ec5978/attachment.html>

From philip.race at oracle.com  Fri Mar  6 23:00:08 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Mar 2015 15:00:08 -0800
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
	<CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
	<54FA1C3C.50104@oracle.com>
	<CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>
Message-ID: <54FA3178.6020002@oracle.com>

Hi,

Two more things regarding the test
1. It was pointed out that you are using GPL+CP .. tests just use GPL
2. There's no @bug tag the test. In fact there's no bug ID here at all :-)

A bug ID is needed in order to push.
You have a JBS account now so could have created it yourself .. but
by the time I remembered that I'd already created it for you :-
https://bugs.openjdk.java.net/browse/JDK-8074587

But I did assign it to you :-)

-phil.

On 03/06/2015 02:03 PM, Laurent Bourg?s wrote:
> Phil,
>
> Here is a new webrev:
> http://cr.openjdk.java.net/~lbourges/webrev_Path2D_1/ 
> <http://cr.openjdk.java.net/%7Elbourges/webrev_Path2D_1/>
>
> See my comments below:
>
>>         you placed the test in the java.awt.geom package.
>>
>>           25 package java.awt.geom;
>>
>>         and are accessing internals of that package.
>>
>>         In jigsaw/modular mode that won't even compile.
>>
>>
>>     Ok it is annoying:
>>     as all Path2D fields are package protected, I designed the test
>>     using direct access to any fields ...
>>
>>
>>         So the test should go in the anonymous package and avoid
>>         accessing internals.
>>         It should be possible to use just public API  to verify the
>>         arrays of a shape
>>         being cloned are trimmed .
>>
>>
>>     No, it is not possible to use Shape API to access arrays nor
>>     fields (numTypes ...):
>>     only getPathIterator() could give me data but it won't tell me if
>>     the underlying arrays or fields are correct.
>
>     That is true ..
>
>     Well, if you need it to be in java.awt.geom, I think even today
>     you'll find it won't work
>     unless you jump through some jtreg hoops to install it on the
>     bootclasspath.
>     I think its something like "@run main/othervm -Xbootclasspath/a:. "
>     And later in the modular JDK it will need to be modified again.
>
>     I'd say either update the test to work with jtreg today - and test
>     it to be sure,
>     or provide the test without an @test tag, or with an @ignore tag,
>     so people can
>     still manually verify it but the harness won't run it.
>
>
> I removed the @test tag but added comments indicating to run the test 
> manually.
>
>
>>
>>     Maybe I could use introspection to getDeclaredField(name) and
>>     setAccessible(true) to get internal data.
>
>     That won't work either. So maybe this is a "noreg-hard" or
>     "noreg-cleanup" bug.
>     We add those labels to the JBS/JIRA bug when something isn't testable.
>
>
> Nevermind.
>
>
>>     Any idea or utility class I could use
>
>>
>>         Why is it necessary to explicitly add the call to super(); ?
>>
>>         223             super();
>>
>>
>>     I agree it is not necessary but it explicitely says that I use
>>     the empty constructor:
>>
>>         /**
>>          * Constructs a new empty {@code Path2D} object.
>>          * It is assumed that the package sibling subclass that is
>>          * defaulting to this constructor will fill in all values.
>>          *
>>          * @since 1.6
>>          */
>>         /* private protected */
>>         Path2D() {
>>         }
>
>     If we all did this, all of the time, there'd be a lot of extra
>     lines in the code, that the compiler
>     would fill in for us anyway.
>
>
> I removed the superfluous super() calls.
>
> Thanks for your review,
>
> Laurent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/335de143/attachment.html>

From philip.race at oracle.com  Fri Mar  6 23:03:21 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Mar 2015 15:03:21 -0800
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074028 Remove API
	references to java.awt.peer
In-Reply-To: <54F8516D.7060809@oracle.com>
References: <54F6FC98.5030303@oracle.com> <54F6FFE5.2070405@oracle.com>
	<54F8516D.7060809@oracle.com>
Message-ID: <54FA3239.40401@oracle.com>

Looks fine (I just looked at the getFontPeer() this time around.
Pls remember to do a CCC before pushing this !

-phil.

On 03/05/2015 04:51 AM, Sergey Bylokhov wrote:
> The new version of the fix:
> http://cr.openjdk.java.net/~serb/8074028/webrev.06
> Font.getPeer() was renamed to Font.getFontPeer().
>
>
> On 04.03.2015 15:51, Alan Bateman wrote:
>> On 04/03/2015 12:37, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk 9.
>>> There are a number of public API whichreference the unsupported 
>>> java.awt.peer interfaces.
>>>
>>> public java.awt.Component.getPeer() @deprecated 1.1
>>> public java.awt.Font.getPeer() @deprecated 1.1
>>> public java.awt.MenuComponent.getPeer() @deprecated 1.1
>>>
>> I don't know this area so I don't feel qualified to do a thorough 
>> review of the changes. However I welcome the changes, this is long 
>> standing technical debt and important that we address this as part of 
>> the move to modules.
>>
>> I note that Font::getPeer is changed to private, hence something try 
>> to access it outside of the Font class will get an IllegalAccessError 
>> as opposed to NoSuchMethodError for the outright removal in the other 
>> cases. Did you consider renaming to something else, say private 
>> FontPeer getFontPeer so that it is consistent with the removal of the 
>> other two methods?
>>
>> I note that you might not have caught all tests but I would assume 
>> that any missed tests should fail. Perhaps there are other failures 
>> that are potentially hiding tests using getPeer?
>>
>> -Alan
>>
>
>



From bourges.laurent at gmail.com  Fri Mar  6 23:21:47 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Sat, 7 Mar 2015 00:21:47 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <54FA3178.6020002@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
	<CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
	<54FA1C3C.50104@oracle.com>
	<CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>
	<54FA3178.6020002@oracle.com>
Message-ID: <CAKjRUT5Puupcc31EPb+_70DytP1Nj=jLFUp9nK1h91cnFr_WwQ@mail.gmail.com>

Phil,

> Two more things regarding the test
> 1. It was pointed out that you are using GPL+CP .. tests just use GPL

You mean I must fix the test file header ?

> 2. There's no @bug tag the test. In fact there's no bug ID here at all :-)
>
> A bug ID is needed in order to push.
> You have a JBS account now so could have created it yourself .. but
> by the time I remembered that I'd already created it for you :-
> https://bugs.openjdk.java.net/browse/JDK-8074587
>
> But I did assign it to you :-)

You're right, I got it.
It seems it is not affected to the graphics rasterizer project, isn't it ?

I am still not familiar with JBS nor pushing changes...

I will read again the doc about pushing changesets ... tomorrow as it is
late. Could you give some hints ?

Do you need another webrev with the correct bug id ?

Thanks,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150307/cc5b4305/attachment.html>

From philip.race at oracle.com  Fri Mar  6 23:32:00 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 06 Mar 2015 15:32:00 -0800
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAKjRUT5Puupcc31EPb+_70DytP1Nj=jLFUp9nK1h91cnFr_WwQ@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
	<CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
	<54FA1C3C.50104@oracle.com>
	<CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>
	<54FA3178.6020002@oracle.com>
	<CAKjRUT5Puupcc31EPb+_70DytP1Nj=jLFUp9nK1h91cnFr_WwQ@mail.gmail.com>
Message-ID: <54FA38F0.10907@oracle.com>

On 03/06/2015 03:21 PM, Laurent Bourg?s wrote:
>
> Phil,
>
> > Two more things regarding the test
> > 1. It was pointed out that you are using GPL+CP .. tests just use GPL
>
> You mean I must fix the test file header ?
>

Yes, please.

> > 2. There's no @bug tag the test. In fact there's no bug ID here at 
> all :-)
> >
> > A bug ID is needed in order to push.
> > You have a JBS account now so could have created it yourself .. but
> > by the time I remembered that I'd already created it for you :-
> >https://bugs.openjdk.java.net/browse/JDK-8074587 
> <https://bugs.openjdk.java.net/browse/JDK-8074587>
> >
> > But I did assign it to you :-)
>
> You're right, I got it.
> It seems it is not affected to the graphics rasterizer project, isn't it ?
>

You can push to graphics rasterizer of course, and no bug ID is needed.
But I assume this to be one that we'd want to push sooner rather than later
to the JDK 9 client forest here :- 
http://hg.openjdk.java.net/jdk9/client/jdk
since its not directly related to marlin




> I am still not familiar with JBS nor pushing changes...
>
> I will read again the doc about pushing changesets ... tomorrow as it 
> is late. Could you give some hints ?
>


Jim or I will have to push it there (jdk9/client) for you of course, but 
the more such
fixes you contribute, the sooner we can ask for JDK 9 committer rights 
as well.

> Do you need another webrev with the correct bug id ?
>

Yes, in order to push it for you, but I'd suggest to hold off to see if 
Jim points
out anything first ..

-phil.

> Thanks,
> Laurent
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150306/91e14c93/attachment.html>

From james.graham at oracle.com  Sat Mar  7 01:28:05 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 06 Mar 2015 17:28:05 -0800
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Openjdk java2d rasterizer
 JEP for pisces (marlin) enhancements ?
In-Reply-To: <CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
Message-ID: <54FA5425.2090007@oracle.com>

We should probably focus on a single Mailing List for code reviews. 
This particular review is not necessarily specific to the rasterizer, so 
it should probably have only been sent to the 2d-dev list (Path2D is 
owned by 2D).

Also, please start a new thread for code reviews (and new topics).  This 
code review will now be forever threaded with the long discussion about 
rasterizer optimizations because it shares too many headers with the 
other thread... :(

			...jim

On 3/6/15 10:35 AM, Laurent Bourg?s wrote:
> Jim,
>
> Here is my first "official" webrev (vs graphics-rasterizer forest)
> concerning Path2D copy constructors:
> http://cr.openjdk.java.net/~lbourges/webrev_Path2D_0/
>
> this is a simple Path2D patch to trim arrays (numTypes & float/double
> Coords) in copy constructors (Path2D.Float and Path2D.Double variants)
> with the requested test: Path2DTrimCopy.
>
> Please tell me if the test is correct as I do not run it with jtreg
> (annotations ?)
>
>
>     2015-02-25 2:05 GMT+01:00 Jim Graham <james.graham at oracle.com
>     <mailto:james.graham at oracle.com>>:
>
>         Those changes were exactly what I was referring to.  I don't see
>         why we shouldn't make trimmed arrays when copying the shape.
>         I'm pretty sure that the copy constructors are going to be
>         overwhelmingly used to make a protected copy of an existing
>         shape/path2d which is likely meant mostly for reading.  In
>         particular, in the case of the return value from
>         createStrokedShape() I don't think the intention is to create
>         the shape and then scribble on it, the intent is to treat the
>         answer as if it were immutable - at least the 99.9% case - so I
>         think a perfectly sized shape is OK.
>
>         Be sure to add a test case that creates an empty Path2D, clones
>         it, copy constructs it (to both .Double() and .Float() variants)
>         and then tries to add new segments to it - to make sure that the
>         array growth code doesn't get ArrayIndexOutOfBounds exceptions
>         due to making assumptions about the lengths of the arrays (I
>         eyeballed the makeRoom() code and it looks good, but we should
>         test it if we are making arrays that are potentially zero length
>         or very tiny)...
>
>
> Laurent


From james.graham at oracle.com  Sat Mar  7 01:43:20 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 06 Mar 2015 17:43:20 -0800
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <54F9FA9A.1060705@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>	<54DF8F7F.5040700@redhat.com>	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>	<54E5CA9A.3090801@oracle.com>	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>	<54E5F25F.2020303@oracle.com>
	<1424361976.4253.41.camel@localhost>	<54E67B0A.8080508@oracle.com>	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>	<54E7846E.6000703@oracle.com>	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>	<54ECB5CD.8080602@oracle.com>
	<54ECB8B8.2010806@oracle.com>	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>	<54ED1FF2.3040209@oracle.com>	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
Message-ID: <54FA57B8.60201@oracle.com>

First, the test cases that I asked for were to verify that a path that 
was cloned was still operational.  I see no tests that verify that the 
returned objects will still function, only tests that examine internal 
data structures for a metric that may not be appropriate in the future.

On 3/6/15 11:06 AM, Phil Race wrote:
> So the test should go in the anonymous package and avoid accessing
> internals.
> It should be possible to use just public API  to verify the arrays  of a
> shape
> being cloned are trimmed .

We should not be testing if the cloned arrays are trimmed.  We don't 
care from a testing standpoint.  It is an implementation detail of a 
performance feature and we should not write any test that says "Object A 
should do its work by doing X, Y, and Z".

If we want to test performance then we should write a benchmark that 
tests how long it takes to do an operation.  That will likely be a 
manual test, though.  It should not be examining internals to take its 
measurements, though.  Benchmarks tend to only use public APIs as they 
should be benchmarking operations that Java programs encounter.

If we want to test if your fix will break something, then we need to 
test that.  Currently your tests do not do that.  We only need public 
APIs to do that.

What I would like to see in the test:

- Delete all of the existing tests in there.  None of them are 
appropriate to our testing goals.

- Write tests that create paths in various forms and run them through 
the following sub-tests:
      - each of the following should be tested on a fresh clone...
      - get a PathIterator and iterate it through until it is done
        (optional - compare to the expected segments that were in the 
original)
      - get a flattened PathIterator using "getPathIterator(flatness,)" 
and make sure it works
        (optional - compare to original path if the original was already 
flat)
        (but, also run it on a path with curves to make sure flattening 
engine didn't break)
      - add various kinds of segments to the cloned path
      - get the bounds of the cloned path
      - use the transform() method on the cloned path
      - call intersects(point), intersects(rect) and contains(rect) on a 
cloned path
      - call getCurrentPoint() on the cloned path

- Perform each of the above tests on a (set of) clone(s) of the 
following paths:
      - each of the following executed on both a Float and a Double 
instance...
      - an empty path
      - a path with just a moveto
      - a path with a moveto+some lines
      - a path with a moveto+some curves

The way I tend to write tests like this is to use cascading methods like:

void testEqual(Path2D pathA, Path2D path2D pathB) {
     // Grab 2 path iterators and test for equality with float coords[]
}

void test(Path2D p2d, boolean isEmpty) {
     testEqual(new Path2D.Float(p2d), p2d);
     testEqual(new Path2D.Double(p2d), p2d);
     testEqual(new GeneralPath(p2d), p2d);

     testIterator(new Path2D.Float(p2d));
     testIterator(new Path2D.Double(p2d));
     testIterator((Path2D) p2d.clone());

     testFlattening(... 3 clone variants ...);

     testAddMove(... 3 clone variants ...);
     // These should expect exception if empty
     testAddLine(... 3 clone variants ..., isEmpty);
     testAddQuad(... 3 clone variants ..., isEmpty);
}

interface PathFactory {
     Path2D makePath();
}

void test(PathFactory pf) {
     test(pf.makePath(), true);
     test(addMove(pf.makePath()), false);
     test(addLines(pf.makePath()), false);
     test(addCurves(pf.makePath())), false);
}

@Test
void testFloatPaths() {
     test(() -> new Path2D.Float());
}

@Test
void testDoublePaths() {
     test(() -> new Path2D.Double());
}

@Test
void testGeneralPath() {
     test(() -> new GeneralPath());
}

			...jim


From james.graham at oracle.com  Sat Mar  7 01:45:29 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 06 Mar 2015 17:45:29 -0800
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Openjdk java2d rasterizer
 JEP for pisces (marlin) enhancements ?
In-Reply-To: <CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com>
	<CAKjRUT79+xn02-Fi68stcfD_THodT9jzghKOyTjx3nTQs8FoRg@mail.gmail.com>
	<54FA1C3C.50104@oracle.com>
	<CAKjRUT7_CgvD66gvTset_PuZu-wU2qV26fB=cyK3TXceiKp2Jw@mail.gmail.com>
Message-ID: <54FA5839.9030200@oracle.com>

On lines 228 and 1069 you should not mix p2d and this.  I would go with 
both p2d.pointTypes and p2d.numTypes in both cases...

			...jim

On 3/6/15 2:03 PM, Laurent Bourg?s wrote:
> Phil,
>
> Here is a new webrev:
> http://cr.openjdk.java.net/~lbourges/webrev_Path2D_1/
>
> See my comments below:
>
>>         you placed the test in the java.awt.geom package.
>>
>>           25 package java.awt.geom;
>>
>>         and are accessing internals of that package.
>>
>>         In jigsaw/modular mode that won't even compile.
>>
>>
>>     Ok it is annoying:
>>     as all Path2D fields are package protected, I designed the test
>>     using direct access to any fields ...
>>
>>
>>         So the test should go in the anonymous package and avoid
>>         accessing internals.
>>         It should be possible to use just public API  to verify the
>>         arrays  of a shape
>>         being cloned are trimmed .
>>
>>
>>     No, it is not possible to use Shape API to access arrays nor
>>     fields (numTypes ...):
>>     only getPathIterator() could give me data but it won't tell me if
>>     the underlying arrays or fields are correct.
>
>     That is true ..
>
>     Well, if you need it to be in java.awt.geom, I think even today
>     you'll find it won't work
>     unless you jump through some jtreg hoops to install it on the
>     bootclasspath.
>     I think its something like "@run main/othervm -Xbootclasspath/a:. "
>     And later in the modular JDK it will need to be modified again.
>
>     I'd say either update the test to work with jtreg today - and test
>     it to be sure,
>     or provide the test without an @test tag, or with an @ignore tag, so
>     people can
>     still manually verify it but the harness won't run it.
>
>
> I removed the @test tag but added comments indicating to run the test
> manually.
>
>
>>
>>     Maybe I could use introspection to getDeclaredField(name) and
>>     setAccessible(true) to get internal data.
>
>     That won't work either. So maybe this is a "noreg-hard" or
>     "noreg-cleanup" bug.
>     We add those labels to the JBS/JIRA bug when something isn't testable.
>
>
> Nevermind.
>
>
>>     Any idea or utility class I could use
>
>>
>>         Why is it necessary to explicitly add the call to super(); ?
>>
>>         223             super();
>>
>>
>>     I agree it is not necessary but it explicitely says that I use the
>>     empty constructor:
>>
>>         /**
>>          * Constructs a new empty {@code Path2D} object.
>>          * It is assumed that the package sibling subclass that is
>>          * defaulting to this constructor will fill in all values.
>>          *
>>          * @since 1.6
>>          */
>>         /* private protected */
>>         Path2D() {
>>         }
>
>     If we all did this, all of the time, there'd be a lot of extra lines
>     in the code, that the compiler
>     would fill in for us anyway.
>
>
> I removed the superfluous super() calls.
>
> Thanks for your review,
>
> Laurent


From bourges.laurent at gmail.com  Sat Mar  7 23:18:33 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Sun, 8 Mar 2015 00:18:33 +0100
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <54FA57B8.60201@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
Message-ID: <CAKjRUT74kHmrwWCoR--hcCJOyVn0WMWY1bt_mJS8a2ETQ1enuQ@mail.gmail.com>

Jim,

Ok, I will totally rewrite the Path2D test soon.

I was busy on marlin optimizing its merge sort variant based on my
mapbench's array data (stats...).

I will publish soon a new release with an up-to-date report between pisces,
marlin & ductus.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150308/32783cd2/attachment.html>

From erik.joelsson at oracle.com  Mon Mar  9 09:08:54 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 09 Mar 2015 10:08:54 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8074096 Disable (most) native
 warnings in JDK on a per-library basis
In-Reply-To: <54F9D281.3030206@oracle.com>
References: <54F705E0.2030102@oracle.com> <54F70949.4040900@oracle.com>
	<54F9D281.3030206@oracle.com>
Message-ID: <54FD6326.4070403@oracle.com>

Thanks, looks good!

/Erik

On 2015-03-06 17:14, Magnus Ihse Bursie wrote:
> On 2015-03-04 14:31, Erik Joelsson wrote:
>> Hello,
>>
>> Really nice to finally see this patch getting done!
>>
>> Only one comment:
>>
>> flags.m4:
>> In the grep expression, could you move the extra [] outside of the 
>> actual command line options to grep so that the command line could be 
>> copied to the shell for debugging in the future? Also, how hard would 
>> it be to instead do AC_COMPILE_IFELSE with a dummy warning to instead 
>> test for capability?
>
> I have updated the fix to use the eminent 
> FLAGS_COMPILER_CHECK_ARGUMENTS instead. :-)
>
> http://cr.openjdk.java.net/~ihse/JDK-8074096-disable-native-warnings/webrev.02 
>
>
> /Magnus
>



From brian.burkhalter at oracle.com  Tue Mar 10 16:59:02 2015
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 10 Mar 2015 09:59:02 -0700
Subject: [OpenJDK 2D-Dev] Why is java.awt.image.BufferedImage not
	serializable ?
In-Reply-To: <BLU168-W90C3DBAF0F68664696D306D3180@phx.gbl>
References: <BLU168-W90C3DBAF0F68664696D306D3180@phx.gbl>
Message-ID: <CDB961AB-E263-418F-AB81-7E7CF4C2A738@oracle.com>

Bonjour,

I think your question would be better directed to the 2d-dev list:

http://mail.openjdk.java.net/mailman/listinfo/2d-dev

Merci,

Brian

On Mar 9, 2015, at 7:58 PM, Jean-Fran?ois Savard <j-f.savard at hotmail.com> wrote:

> I believe java.awt.image.BufferedImage (and all java images type) are not serializable simply because it is illogical to serializable an Image file, as the point of serializing is to keep something as a file independent of the JVM. Which is already the case for a normal image file.
> Would you please confirm ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150310/d45fbf8c/attachment.html>

From j-f.savard at hotmail.com  Tue Mar 10 17:20:17 2015
From: j-f.savard at hotmail.com (=?iso-8859-1?B?SmVhbi1GcmFu529pcyBTYXZhcmQ=?=)
Date: Tue, 10 Mar 2015 13:20:17 -0400
Subject: [OpenJDK 2D-Dev] Why are java images type not serializable ?
Message-ID: <BLU168-W11808A92905096E1B31B9BBD3180@phx.gbl>

Hi,

I've realized java.awt.image.BufferedImage is not serializable.
After a couple of research, I've realized that each java image types (correct me if I'm wrong) are not serializable at all.
I've then decided to do research without specifying java as language and realized serialization of image is not present in most of the languages. I've come to the conclusion that is simply because serializing an image is illogical. When you load an image, it is because you already have the resource stored somewhere (file or in-memory), so there is no point in serializing it as the main utility of serialization is to store data independent of the JVM, which is already the case for an image file. For the case where the image is in-memory, it mean you already loaded the ressource and have the byte array so it is better to simply serialize that byte array.
Would you please confirm that my understanding is correct ? 

Best regards. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150310/e2171568/attachment.html>

From james.graham at oracle.com  Tue Mar 10 18:37:44 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 10 Mar 2015 11:37:44 -0700
Subject: [OpenJDK 2D-Dev] Why are java images type not serializable ?
In-Reply-To: <BLU168-W11808A92905096E1B31B9BBD3180@phx.gbl>
References: <BLU168-W11808A92905096E1B31B9BBD3180@phx.gbl>
Message-ID: <54FF39F8.1010601@oracle.com>

Serializing images by content is generally wasteful in terms of the size 
of the data stream.

For images loaded from a URL or file, presumably those can be reloaded 
by the application if it has a way to retrigger loading its resources (a 
common technique is to lazily load some images or have a central method 
for loading media - both of which are easy to trigger in the process of 
deserializing).

For images that are generated on the fly, often those can be regenerated 
by the code, but it may not be as automatic as lazily reloading an image 
from its file/URL.

One issue is that images may be loaded from a cache and multiple 
references stored throughout the program (particularly for images used 
as common UI elements).  I suppose that a well-written serialization 
mechanism may notice the repeated references and try to share the 
serialized forms, but I'm not entirely sure how that works or how that 
would impact serializing the images.

There is also the issue that BufferedImages can be fully custom, which 
means that we have no idea how the pixels are stored or where they are 
stored.  The fact that ColorModel, SampleModel, and Raster are openly 
subclassable allows for such completely custom implementations.  We 
could not guarantee serializability of custom subclasses of any of 
those, unfortunately...

			...jim

On 3/10/15 10:20 AM, Jean-Fran?ois Savard wrote:
> Hi,
>
> I've realized java.awt.image.BufferedImage is not serializable.
>
> After a couple of research, I've realized that each java image types
> (correct me if I'm wrong) are not serializable at all.
>
> I've then decided to do research without specifying java as language and
> realized serialization of image is not present in most of the languages.
> I've come to the conclusion that is simply because serializing an image
> is illogical. When you load an image, it is because you already have the
> resource stored somewhere (file or in-memory), so there is no point in
> serializing it as the main utility of serialization is to store data
> independent of the JVM, which is already the case for an image file. For
> the case where the image is in-memory, it mean you already loaded the
> ressource and have the byte array so it is better to simply serialize
> that byte array.
>
> Would you please confirm that my understanding is correct ?
>
> Best regards.


From james.graham at oracle.com  Tue Mar 10 21:18:53 2015
From: james.graham at oracle.com (Jim Graham)
Date: Tue, 10 Mar 2015 14:18:53 -0700
Subject: [OpenJDK 2D-Dev] Why are java images type not serializable ?
In-Reply-To: <54FF39F8.1010601@oracle.com>
References: <BLU168-W11808A92905096E1B31B9BBD3180@phx.gbl>
	<54FF39F8.1010601@oracle.com>
Message-ID: <54FF5FBD.2020305@oracle.com>

Just to clarify - what I've described here is not necessarily a hard and 
fast reason why it can't be done, but more the issues and considerations 
that go into why we haven't done it in the past.  That, and the fact 
that there isn't a big history of this being requested (insofar as I 
don't remember there being a bug/rfe filed against it).

It should certainly be filed as an RFE and we can discuss the technical 
hurdles and the workarounds in that context and gauge the level of 
interest from the community...

			...jim

On 3/10/15 11:37 AM, Jim Graham wrote:
> Serializing images by content is generally wasteful in terms of the size
> of the data stream.
>
> For images loaded from a URL or file, presumably those can be reloaded
> by the application if it has a way to retrigger loading its resources (a
> common technique is to lazily load some images or have a central method
> for loading media - both of which are easy to trigger in the process of
> deserializing).
>
> For images that are generated on the fly, often those can be regenerated
> by the code, but it may not be as automatic as lazily reloading an image
> from its file/URL.
>
> One issue is that images may be loaded from a cache and multiple
> references stored throughout the program (particularly for images used
> as common UI elements).  I suppose that a well-written serialization
> mechanism may notice the repeated references and try to share the
> serialized forms, but I'm not entirely sure how that works or how that
> would impact serializing the images.
>
> There is also the issue that BufferedImages can be fully custom, which
> means that we have no idea how the pixels are stored or where they are
> stored.  The fact that ColorModel, SampleModel, and Raster are openly
> subclassable allows for such completely custom implementations.  We
> could not guarantee serializability of custom subclasses of any of
> those, unfortunately...
>
>              ...jim
>
> On 3/10/15 10:20 AM, Jean-Fran?ois Savard wrote:
>> Hi,
>>
>> I've realized java.awt.image.BufferedImage is not serializable.
>>
>> After a couple of research, I've realized that each java image types
>> (correct me if I'm wrong) are not serializable at all.
>>
>> I've then decided to do research without specifying java as language and
>> realized serialization of image is not present in most of the languages.
>> I've come to the conclusion that is simply because serializing an image
>> is illogical. When you load an image, it is because you already have the
>> resource stored somewhere (file or in-memory), so there is no point in
>> serializing it as the main utility of serialization is to store data
>> independent of the JVM, which is already the case for an image file. For
>> the case where the image is in-memory, it mean you already loaded the
>> ressource and have the byte array so it is better to simply serialize
>> that byte array.
>>
>> Would you please confirm that my understanding is correct ?
>>
>> Best regards.


From Sergey.Bylokhov at oracle.com  Thu Mar 12 01:40:02 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Mar 2015 18:40:02 -0700
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8074668 [macosx] Mac 10.10:
 Application run with splash screen has focus issues
Message-ID: <5500EE72.8050804@oracle.com>

Hello.
Please review the fix for jdk 8/9.
Lots of issues(hangs or focus lost) occurred after we call 
NSScreen.backingScaleFactor on a Appkit Thread in time of splash screen 
initialization.
This is a regression of two fixes:
https://bugs.openjdk.java.net/browse/JDK-8043869
https://bugs.openjdk.java.net/browse/JDK-8049198
Current issue occures after the second fix.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074668
As a fix I suggest to disable functionality which was added in 
JDK-8049198 <https://bugs.openjdk.java.net/browse/JDK-8049198> and 
JDK-8043869 <https://bugs.openjdk.java.net/browse/JDK-8043869>. Because 
if I try to revert them back I should change more files which I consider 
will be danger.

-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150311/a047b93f/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Mar 12 01:46:55 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 11 Mar 2015 18:46:55 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: 8074668 [macosx]
 Mac 10.10: Application run with splash screen has focus issues
In-Reply-To: <5500EE72.8050804@oracle.com>
References: <5500EE72.8050804@oracle.com>
Message-ID: <5500F00F.10304@oracle.com>

11.03.15 18:40, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 8/9.
> Lots of issues(hangs or focus lost) occurred after we call 
> NSScreen.backingScaleFactor on a Appkit Thread in time of splash 
> screen initialization.
> This is a regression of two fixes:
> https://bugs.openjdk.java.net/browse/JDK-8043869
> https://bugs.openjdk.java.net/browse/JDK-8049198
> Current issue occures after the second fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074668
> As a fix I suggest to disable functionality which was added in 
> JDK-8049198 <https://bugs.openjdk.java.net/browse/JDK-8049198> and 
> JDK-8043869 <https://bugs.openjdk.java.net/browse/JDK-8043869>. 
> Because if I try to revert them back I should change more files which 
> I consider will be danger.
The fix which broke the splash screen:
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fb3f4212427f

Suggested fix:
src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
@@ -129,15 +129,11 @@
  char* SplashGetScaledImageName(const char* jar, const char* file,
                                 float *scaleFactor) {
      NSAutoreleasePool *pool = [NSAutoreleasePool new];
      *scaleFactor = 1;
      char* scaledFile = nil;
- __block float screenScaleFactor = 1;
-
- [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
- screenScaleFactor = [SplashNSScreen() backingScaleFactor];
- }];
+ float screenScaleFactor = 1;

      if (screenScaleFactor > 1) {
          NSString *fileName = [NSString stringWithUTF8String: file];
          NSUInteger length = [fileName length];
          NSRange range = [fileName rangeOfString: @"."

> -- 
> Best regards, Sergey.


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150311/3f1c59e6/attachment.html>

From philip.race at oracle.com  Thu Mar 12 02:02:28 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 11 Mar 2015 19:02:28 -0700
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: 8074668 [macosx]
 Mac 10.10: Application run with splash screen has focus issues
In-Reply-To: <5500F00F.10304@oracle.com>
References: <5500EE72.8050804@oracle.com> <5500F00F.10304@oracle.com>
Message-ID: <5500F3B4.3060606@oracle.com>

+1 .. I was pondering the exact same approach so I am OK with this
as it leaves the useful code in place and disables the problematic part.
There was a test added for the hi-res splash. Perhaps you should add
an @ignore for now ?

-phil.

On 3/11/15 6:46 PM, Sergey Bylokhov wrote:
> 11.03.15 18:40, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 8/9.
>> Lots of issues(hangs or focus lost) occurred after we call 
>> NSScreen.backingScaleFactor on a Appkit Thread in time of splash 
>> screen initialization.
>> This is a regression of two fixes:
>> https://bugs.openjdk.java.net/browse/JDK-8043869
>> https://bugs.openjdk.java.net/browse/JDK-8049198
>> Current issue occures after the second fix.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074668
>> As a fix I suggest to disable functionality which was added in 
>> JDK-8049198 <https://bugs.openjdk.java.net/browse/JDK-8049198> and 
>> JDK-8043869 <https://bugs.openjdk.java.net/browse/JDK-8043869>. 
>> Because if I try to revert them back I should change more files which 
>> I consider will be danger.
> The fix which broke the splash screen:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fb3f4212427f
>
> Suggested fix:
> src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
> @@ -129,15 +129,11 @@
>  char* SplashGetScaledImageName(const char* jar, const char* file,
>                                 float *scaleFactor) {
>      NSAutoreleasePool *pool = [NSAutoreleasePool new];
>      *scaleFactor = 1;
>      char* scaledFile = nil;
> - __block float screenScaleFactor = 1;
> -
> - [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
> - screenScaleFactor = [SplashNSScreen() backingScaleFactor];
> - }];
> + float screenScaleFactor = 1;
>
>      if (screenScaleFactor > 1) {
>          NSString *fileName = [NSString stringWithUTF8String: file];
>          NSUInteger length = [fileName length];
>          NSRange range = [fileName rangeOfString: @"."
>
>> -- 
>> Best regards, Sergey.
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150311/68774d2a/attachment.html>

From alexandr.scherbatiy at oracle.com  Thu Mar 12 07:32:30 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 12 Mar 2015 10:32:30 +0300
Subject: [OpenJDK 2D-Dev] <AWT Dev> [9] Review Request: 8074668 [macosx]
 Mac 10.10: Application run with splash screen has focus issues
In-Reply-To: <5500F00F.10304@oracle.com>
References: <5500EE72.8050804@oracle.com> <5500F00F.10304@oracle.com>
Message-ID: <5501410E.1060200@oracle.com>


  The fix looks good to me.

  Thanks,
  Alexandr.

On 3/12/2015 4:46 AM, Sergey Bylokhov wrote:
> 11.03.15 18:40, Sergey Bylokhov wrote:
>> Hello.
>> Please review the fix for jdk 8/9.
>> Lots of issues(hangs or focus lost) occurred after we call 
>> NSScreen.backingScaleFactor on a Appkit Thread in time of splash 
>> screen initialization.
>> This is a regression of two fixes:
>> https://bugs.openjdk.java.net/browse/JDK-8043869
>> https://bugs.openjdk.java.net/browse/JDK-8049198
>> Current issue occures after the second fix.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074668
>> As a fix I suggest to disable functionality which was added in 
>> JDK-8049198 <https://bugs.openjdk.java.net/browse/JDK-8049198> and 
>> JDK-8043869 <https://bugs.openjdk.java.net/browse/JDK-8043869>. 
>> Because if I try to revert them back I should change more files which 
>> I consider will be danger.
> The fix which broke the splash screen:
> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fb3f4212427f
>
> Suggested fix:
> src/macosx/native/sun/awt/splashscreen/splashscreen_sys.m
> @@ -129,15 +129,11 @@
>  char* SplashGetScaledImageName(const char* jar, const char* file,
>                                 float *scaleFactor) {
>      NSAutoreleasePool *pool = [NSAutoreleasePool new];
>      *scaleFactor = 1;
>      char* scaledFile = nil;
> - __block float screenScaleFactor = 1;
> -
> - [ThreadUtilities performOnMainThreadWaiting:YES block:^(){
> - screenScaleFactor = [SplashNSScreen() backingScaleFactor];
> - }];
> + float screenScaleFactor = 1;
>
>      if (screenScaleFactor > 1) {
>          NSString *fileName = [NSString stringWithUTF8String: file];
>          NSUInteger length = [fileName length];
>          NSRange range = [fileName rangeOfString: @"."
>
>> -- 
>> Best regards, Sergey.
>
>
> -- 
> Best regards, Sergey.



From anton.tarasov at oracle.com  Thu Mar 12 09:20:58 2015
From: anton.tarasov at oracle.com (Anton V. Tarasov)
Date: Thu, 12 Mar 2015 12:20:58 +0300
Subject: [OpenJDK 2D-Dev] <Swing Dev> [9] Review Request: 8074668
 [macosx] Mac 10.10: Application run with splash screen has focus issues
In-Reply-To: <5500EE72.8050804@oracle.com>
References: <5500EE72.8050804@oracle.com>
Message-ID: <55015A7A.7090601@oracle.com>

Hi Sergey,

Looks good to me.

Regards,
Anton.

On 12.03.2015 4:40, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk 8/9.
> Lots of issues(hangs or focus lost) occurred after we call NSScreen.backingScaleFactor on a Appkit 
> Thread in time of splash screen initialization.
> This is a regression of two fixes:
> https://bugs.openjdk.java.net/browse/JDK-8043869
> https://bugs.openjdk.java.net/browse/JDK-8049198
> Current issue occures after the second fix.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074668
> As a fix I suggest to disable functionality which was added in JDK-8049198 
> <https://bugs.openjdk.java.net/browse/JDK-8049198> and JDK-8043869 
> <https://bugs.openjdk.java.net/browse/JDK-8043869>. Because if I try to revert them back I should 
> change more files which I consider will be danger.
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150312/7d79e804/attachment.html>

From bourges.laurent at gmail.com  Fri Mar 13 09:09:53 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 13 Mar 2015 10:09:53 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <54F8DDC3.5010102@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT66uSkoMkOOaUv4mV8GGxJuhRvSbtTS0PRYh8=BciT0JQ@mail.gmail.com>
	<CAGUMyaSA1ywbLQ0H2NrH4bNe=GORWVXyodR3i+oH+eiRwHXyAQ@mail.gmail.com>
	<54F8DDC3.5010102@oracle.com>
Message-ID: <CAKjRUT7syok_-GM__QZkDM1ocHfDisiGQ_t=Uw2OX6cFjN9UAw@mail.gmail.com>

Dear all,

I am glad to announce that I submitted first Marlin webrevs and a new
thread has started on the graphics-rasterizer mailing list:

http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/2015-March/000073.html


I think it is time to stop this thread on the java2d mailing list.

Of course, you can subscribe to the graphics-rasterizer mailing list to
follow Marlin's integration effort into OpenJDK 9.


Regards,

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150313/ef1999d1/attachment.html>

From bourges.laurent at gmail.com  Fri Mar 13 09:12:16 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 13 Mar 2015 10:12:16 +0100
Subject: [OpenJDK 2D-Dev] Openjdk java2d rasterizer JEP for pisces
 (marlin) enhancements ?
In-Reply-To: <CAKjRUT7syok_-GM__QZkDM1ocHfDisiGQ_t=Uw2OX6cFjN9UAw@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT7hwpLhzQWCAfSQ2C8WhuvPu4D2HBr3FWGu0DdbUJTN_Q@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT66uSkoMkOOaUv4mV8GGxJuhRvSbtTS0PRYh8=BciT0JQ@mail.gmail.com>
	<CAGUMyaSA1ywbLQ0H2NrH4bNe=GORWVXyodR3i+oH+eiRwHXyAQ@mail.gmail.com>
	<54F8DDC3.5010102@oracle.com>
	<CAKjRUT7syok_-GM__QZkDM1ocHfDisiGQ_t=Uw2OX6cFjN9UAw@mail.gmail.com>
Message-ID: <CAKjRUT5CFQ5xVd03Hq8VXrKCRLxz_J5cBPSuJOKHeidbdo85GQ@mail.gmail.com>

Sorry, I forgot to mention I made a performance summary:
http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/2015-March/000077.html

Here is the performance summary:

http://cr.openjdk.java.net/~lbourges/marlin/report/perf_summary.htm


*Threads* *4* *1* *2* *4*
*Renderer* *Test count* *27* *9* *9* *9*
*ductus* *Pct95* 355,442 157,616 263,145 645,566
*pisces* *Pct95* 398,576 345,619 373,08 477,03
*Marlin 0.5.6* *Pct95* 130,718 129,718 130,557 131,877
*Marlin JDK9* *Pct95* 137,709 134,898 138,736 139,494


All details (benchmark log files) are published:
http://cr.openjdk.java.net/~lbourges/marlin/report/


Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150313/a2e61d06/attachment.html>

From alexandr.scherbatiy at oracle.com  Fri Mar 13 13:34:27 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 13 Mar 2015 16:34:27 +0300
Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom
 MultiResolution image support on HiDPI displays
In-Reply-To: <54DE956C.9040105@oracle.com>
References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com>
Message-ID: <5502E763.7080008@oracle.com>


   Hello,

   Could you review the proposed API based on MultiresolutionImage 
interface:
     http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/

  - return unmodifiable list comment is added to the 
getResolutionVariants() method javadoc in MultiresolutionImage interface
  - base image size arguments are removed form the 
getResolutionVariant(...) method in MultiresolutionImage interface
  - BaseMultiResolutionImage class that allows to create a 
multi-resolution image based on resolution variant array is added
  - the test for the BaseMultiResolutionImage is added

  Thanks,
  Alexandr.

On 2/14/2015 3:23 AM, Jim Graham wrote:
> The second solution looks good.  I'd make it standard practice 
> (perhaps even mentioned in the documentation) to return unmodifiable 
> lists from the getVariants() method.  The Collections class provides 
> easy methods to create these lists, and it sends a clear message to 
> the caller that the list was provided for them to read, but not write 
> to.  Otherwise they may add a new image to the list you provided them 
> and wonder why it wasn't showing up.  Also, an unmodifiable list can 
> be cached and reused for subsequent calls without having to create a 
> new list every time.
>
> In getResolutionVariant() was there a reason why the base dimensions 
> were provided as float?  The destination dimensions make sense as 
> float since they could be the result of a scale, but the source 
> dimensions are typically getWidth/getHeight() on the base image.  A 
> related question would be if they are needed at all, since the 
> implementation should probably already be aware of what the base image 
> is and what its dimensions are.  I'm guessing they are provided 
> because the implementation in SG2D already knows them and it makes it 
> easier to forward the implementation on to a shared (static?) method?
>
> With respect to default implementations, I take it that the BaseMRI is 
> along the pattern that we see in Swing for Base classes.  Would it be 
> helpful to provide an implementation (in addition or instead) that 
> allows a developer to take a bunch of images and quickly make an MRI 
> without having to override anything?  The implementations of 
> getBaseImage() and getResolutionVariants() are pretty straightforward 
> and a fairly reasonable default algorithm can be provided for 
> getRV(dimensions).  This question is more of an idle question for my 
> own curiosity than a stumbling block...
>
>             ...jim
>
> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote:
>>
>>    Hi Phil,
>>
>>    I have prepared two versions of the proposed API:
>>
>>    I) Resolution variants are added directly to the Image:
>>     http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
>>
>>    II)  MultiResolutionImage interface is used:
>>      http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
>>
>>    It could help to decide which way should be chosen for the the
>> multi-resolution image support.
>>
>>    Below are some comments:
>>
>>    1. High level goal:
>>       Introduce an API that allows to create and handle an image with
>> resolution variants.
>>
>>    2. What is not subject of the provided API
>>      - Scale naming convention for high-resolution images
>>      - Providing pixel scale factor for the screen/window
>>
>>    3. Use cases
>>     3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
>>       A high-resolution image is loaded from resources and stored in
>> JBHiDPIScaledImage class  which is a subclass of the buffered image.
>>       The high-resolution image is used to create a disabled icon in the
>> IconLoader.getDisabledIcon(icon) method.
>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java 
>>
>>
>>
>>     3.2 Loading and drawing high-resolution icons in NetBeans
>>       NetBeans does not have support for the high-resolution icons 
>> loading.
>>       It loads an icon from the file system using
>> Toolkit.getDefaultToolkit().getImage(url) method or from resources
>>       by  ImageReader  and store it in ToolTipImage class which is
>> subclass of the buffered image.
>>       ImageUtilities.createDisabledIcon(icon) method creates a disabled
>> icon by applying  RGBImageFilter to the icon.
>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java 
>>
>>
>>
>>     3.3 Loading system icons in JDK 1.8
>>       JDK requests icons from the native system for system L&Fs and
>> applies filters for them.
>>       See for example AquaUtils.generateLightenedImage() method:
>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java 
>>
>>
>>
>>    4. HiDPI support for Images on different OSes
>>
>>      4.1 Mac OS X
>>        Cocoa API contains NSImage that allows to work with image
>> representations: add/remove/get all representations.
>>        It picks up an image with necessary resolution based on the
>> screen backing store pixel scale factor and applied transforms.
>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html 
>>
>>
>>
>>      4.2 Linux
>>        GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not
>> public/stable)
>>        that parses the -gtk-scaled css property and draws a GtkCssImage
>> according to the given scale factor.
>>
>>        I have not found information about the HiDPI support in Xlib.
>>
>>      4.3 Windows
>>        I have only found the tutorial that suggests to select and draw a
>> bitmap using the queried DPI
>>        and scale the coordinates for drawing a rectangular frame
>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
>>
>>        Windows also provides the horizontal and vertical DPI of the 
>> desktop
>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>
>>    5. Pseudo API
>>       Below are some ways which illustrates how multi-resolution images
>> can be created and used.
>>
>>      5.1 Resolution variants are stored directly in Image class.
>>      To query a resolution variant it needs to compare the resolution
>> variant width/height
>>      with the requested high-resolution size.
>>      ------------
>>      public abstract class Image {
>>
>>          public void addResolutionVariant(Image image) {...}
>>          public List<Image> getResolutionVariants() {...}
>>      }
>>      ------------
>>      // create a disabled image with resolution variants
>>
>>      Image disabledImage = getDisabledImage(image);
>>
>>      for (Image rv : image.getResolutionVariants()) {
>> disabledImage.addResolutionVariant(getDisabledImage(rv));
>>      }
>>      ------------
>>      This approach requires that all resolution variants have been
>> created even not of them are really used.
>>
>>      5.2  Resolution variants are stored in a separate object that
>> allows to create them by demand.
>>      To query a resolution variant it needs to compare the resolution
>> variant scale factor
>>      with the requested scale (that can include both screen DPI scale
>> and applied transforms).
>>      ------------
>>      public abstract class Image {
>>
>>          public static interface ResolutionVariant {
>>              Image getImage();
>>              float getScaleFactor();
>>          }
>>
>>          public void addResolutionVariant(ResolutionVariant
>> resolutionVariant) {...}
>>          public List<ResolutionVariant> getResolutionVariants() {...}
>>      }
>>      ------------
>>      // create a disabled image with resolution variants
>>      Image disabledImage = getDisabledImage(image);
>>
>>      for (Image.ResolutionVariant rv : image.getResolutionVariants()) {
>>          disabledImage.addResolutionVariant(new 
>> Image.ResolutionVariant() {
>>
>>              public Image getImage() {
>>                  return getDisabledImage(rv.getImage());
>>              }
>>
>>              public float getScaleFactor() {
>>                  return rv.getScaleFactor();
>>              }
>>          });
>>      }
>>      ------------
>>
>>      It does not have problem if a predefined set of images is provided
>> (like image.png and image at 2x.png on the file system).
>>      This does not cover cases where a resolution variant can be created
>> using the exact requested size (like loading icons from the native 
>> system).
>>      A resolution variant can be queried based on a scale factor and
>> applied transforms.
>>
>>      5.3 The provided example allows to create a resolution variant
>> using the requested high-resolution image size.
>>      ------------
>>      public interface MultiResolutionImage {
>>          Image getResolutionVariant(float width, float height);
>>      }
>>      ------------
>>      // create a multi-resolution image
>>      Image mrImage = new AbstractMultiResolutionImage() {
>>
>>              public Image getResolutionVariant(float width, float 
>> height) {
>>                  // create and return a resolution variant with exact
>> requested width/height size
>>              }
>>
>>              protected Image getBaseImage() {
>>                  return baseImage;
>>              }
>>          };
>>      ------------
>>      // create a disabled image with resolution variants
>>      Image disabledImage = null;
>>      if (image instanceof MultiResolutionImage) {
>>          final MultiResolutionImage mrImage = (MultiResolutionImage) 
>> image;
>>          disabledImage = new AbstractMultiResolutionImage(){
>>
>>              public Image getResolutionVariant(float width, float 
>> height) {
>>                  return
>> getDisabledImage(mrImage.getResolutionVariant(width, height));
>>              }
>>
>>              protected Image getBaseImage() {
>>                  return getDisabledImage(mrImage);
>>              }
>>          };
>>      } else {
>>          disabledImage = getDisabledImage(image);
>>      }
>>      ------------
>>
>>    Thanks,
>>    Alexandr.



From philip.race at oracle.com  Mon Mar 16 20:41:24 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 16 Mar 2015 13:41:24 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11 related
	Java files on OSX
Message-ID: <55073FF4.9070606@oracle.com>

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

Although a more complete fix would do something like refactor the source 
files,
as that would be less fragile amongst other things, this at least gets 
us into a
better shape with minimal disruption - and solves my immediate problem :-)

However, it was not sufficient to modify the build file since NativeFont
needs to have an implementation and the unix (aka X11) one just drags
in everything else. So I have a stub version, the same as on Windows.

And it is not clear to me why there was an unused reference to
FontConfigManager in the Mac code. Removing it breaks
a link that dragged in X11 related code.

I expect the files shipped on OS X to go down as a result of
removing these 'dead' ones.
I would also have got rid of the Windows L&F but that needs
a bit of work on the Swing side first : 
https://bugs.openjdk.java.net/browse/JDK-8075255

-phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150316/fd63f1b5/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Mar 16 21:18:26 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Mar 2015 14:18:26 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
 related Java files on OSX
In-Reply-To: <55073FF4.9070606@oracle.com>
References: <55073FF4.9070606@oracle.com>
Message-ID: <550748A2.9020604@oracle.com>

Hi, Phil
Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" using 
$(wildcard, or we still using some files on osx from the unix folder?

>
> Although a more complete fix would do something like refactor the 
> source files,
> as that would be less fragile amongst other things, this at least gets 
> us into a
> better shape with minimal disruption - and solves my immediate problem 
> :-)
There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254
> And it is not clear to me why there was an unused reference to
> FontConfigManager in the Mac code. Removing it breaks
> a link that dragged in X11 related code.
>
> I expect the files shipped on OS X to go down as a result of
> removing these 'dead' ones.
> I would also have got rid of the Windows L&F but that needs
> a bit of work on the Swing side first : 
> https://bugs.openjdk.java.net/browse/JDK-8075255
>
> -phil.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150316/a52397c7/attachment.html>

From philip.race at oracle.com  Mon Mar 16 21:32:14 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 16 Mar 2015 14:32:14 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <54E8499F.7060706@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
	<54E8499F.7060706@oracle.com>
Message-ID: <55074BDE.1050602@oracle.com>

Here is an updated fix that instead of removing the sun.nio dependency 
instead removes
the jdk.charsets static dependency. From the internal API point of view 
its sun.nio.cs.ext
that is the issue, not sun.nio

http://cr.openjdk.java.net/~prr/8035302.1/


-phil.

On 2/21/15 1:02 AM, Alan Bateman wrote:
> On 20/02/2015 22:30, Phil Race wrote:
>> On 2/20/2015 1:48 PM, Alan Bateman wrote:
>>>
>>> :
>>>
>>> 1. For the record, can you explain why the X11 charsets can't move 
>>> to jdk.charsets? I have a vague recollection that they aren't 
>>> standard but I can't recall any details.
>>
>> They aren't standard. And are (mostly) for X11 only. And if they did 
>> then as I understand
>> then we'd still have a dependency on the jdk.charsets module which is 
>> one of the motivations
>> for this, is it not ?
> If the X11 charsets were into jdk.charsets then I assume the font code 
> could access them via the charsets API. Would that work or does the 
> font code need access beyond what the API provides? I'm mostly just 
> trying to see whether this option has been explored or not.
>
>>
>>>
>>> 2. sun.nio.cs.ext.EUC_TWMapping is generated in the build and it 
>>> doesn't look right to me to check in a copy. Same comment on EUC_KR 
>>> and EUC_CN as it looks like they have been copied into X11KSC5601 
>>> and X11GB2312. Have to look at generating these in the build instead?
>>
>> Of course I considered this but I don't see the need. They are 
>> perfectly stable
>> for our needs, and  they aren't all  completely identical  -so I'd 
>> need new code to generate
>> them and the work to get this done is already quite sufficient 
>> without creating more
>> that isn't needed.
> I don't think we should be checking these into the src tree. If the 
> solution involves a copy of these charsets then you need to look at 
> the charset generation so that a copy is generated with a package name 
> that you want.
>
>>
>>>
>>> 3. There is also a copy of sun.nio.cs.DoubleByte in the webrev. This 
>>> used to be in sun.nio.cs.ext (and hence jdk.charsets) so maybe this 
>>> patch started out before Sherman pushed the changes for JDK-8073152.
>>
>> Yes, I just learned of this but it doesn't make any difference to 
>> this patch
>> since its not moved to a public location.
> The issue that we are trying to address here is the direct dependency 
> on a service provider module (jdk.charsets). The sun.nio.cs is in the 
> java.base module and it should be okay to continue with the qualified 
> export (as is already in place).
>
> -Alan.



From david.dehaven at oracle.com  Mon Mar 16 21:33:59 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 16 Mar 2015 14:33:59 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
	related Java files on OSX
In-Reply-To: <550748A2.9020604@oracle.com>
References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com>
Message-ID: <B6A2EF43-954E-485A-A0D1-EAFE8B5C2C0B@oracle.com>


Previously, things were too .. "jiggly" to just remove everything listed lest the whole structure collapsed. Nice to see more effort on this front.

Yes, OSX is still a cross-breed between "solaris" source and it's own source, hence the overly complicated exclusion patterns. Or was, maybe things changed when I wasn't looking (one can dream).

-DrD-

> Hi, Phil
> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" using $(wildcard, or we still using some files on osx from the unix folder?
> 
>> 
>> Although a more complete fix would do something like refactor the source files,
>> as that would be less fragile amongst other things, this at least gets us into a
>> better shape with minimal disruption - and solves my immediate problem :-)
> There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254
>> And it is not clear to me why there was an unused reference to
>> FontConfigManager in the Mac code. Removing it breaks
>> a link that dragged in X11 related code.
>> 
>> I expect the files shipped on OS X to go down as a result of
>> removing these 'dead' ones.
>> I would also have got rid of the Windows L&F but that needs
>> a bit of work on the Swing side first : https://bugs.openjdk.java.net/browse/JDK-8075255
>> 
>> -phil.
>> 
> 
> 
> -- 
> Best regards, Sergey.
> 



From philip.race at oracle.com  Mon Mar 16 22:05:30 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 16 Mar 2015 15:05:30 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
 related Java files on OSX
In-Reply-To: <550748A2.9020604@oracle.com>
References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com>
Message-ID: <550753AA.4050804@oracle.com>

There are some files in sun/print some directories still being used but 
for the files
explicitly listed, then in each case all .java files in those 
directories are now unused.
So yes, I can make this cleaner and less fragile too!

http://cr.openjdk.java.net/~prr/8075277.1/

-phil.*
*
On 3/16/15 2:18 PM, Sergey Bylokhov wrote:
> Hi, Phil
> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" 
> using $(wildcard, or we still using some files on osx from the unix 
> folder?
>
>>
>> Although a more complete fix would do something like refactor the 
>> source files,
>> as that would be less fragile amongst other things, this at least 
>> gets us into a
>> better shape with minimal disruption - and solves my immediate 
>> problem :-)
> There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254
>> And it is not clear to me why there was an unused reference to
>> FontConfigManager in the Mac code. Removing it breaks
>> a link that dragged in X11 related code.
>>
>> I expect the files shipped on OS X to go down as a result of
>> removing these 'dead' ones.
>> I would also have got rid of the Windows L&F but that needs
>> a bit of work on the Swing side first : 
>> https://bugs.openjdk.java.net/browse/JDK-8075255
>>
>> -phil.
>>
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150316/a9074f7e/attachment.html>

From philip.race at oracle.com  Mon Mar 16 23:05:08 2015
From: philip.race at oracle.com (Phil Race)
Date: Mon, 16 Mar 2015 16:05:08 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
 related Java files on OSX
In-Reply-To: <550753AA.4050804@oracle.com>
References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com>
	<550753AA.4050804@oracle.com>
Message-ID: <550761A4.7040001@oracle.com>

One more update: http://cr.openjdk.java.net/~prr/8075277.2/

just adds sun/awt/motif/* to the exclude list.

I'm deleting that directory in another fix but those without those 
changes need it
excluded too

-phil.

On 3/16/15 3:05 PM, Phil Race wrote:
> There are some files in sun/print some directories still being used 
> but for the files
> explicitly listed, then in each case all .java files in those 
> directories are now unused.
> So yes, I can make this cleaner and less fragile too!
>
> http://cr.openjdk.java.net/~prr/8075277.1/
>
> -phil.*
> *
> On 3/16/15 2:18 PM, Sergey Bylokhov wrote:
>> Hi, Phil
>> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" 
>> using $(wildcard, or we still using some files on osx from the unix 
>> folder?
>>
>>>
>>> Although a more complete fix would do something like refactor the 
>>> source files,
>>> as that would be less fragile amongst other things, this at least 
>>> gets us into a
>>> better shape with minimal disruption - and solves my immediate 
>>> problem :-)
>> There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254
>>> And it is not clear to me why there was an unused reference to
>>> FontConfigManager in the Mac code. Removing it breaks
>>> a link that dragged in X11 related code.
>>>
>>> I expect the files shipped on OS X to go down as a result of
>>> removing these 'dead' ones.
>>> I would also have got rid of the Windows L&F but that needs
>>> a bit of work on the Swing side first : 
>>> https://bugs.openjdk.java.net/browse/JDK-8075255
>>>
>>> -phil.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150316/0ed4b7ec/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Mar 17 00:05:46 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 16 Mar 2015 17:05:46 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
 related Java files on OSX
In-Reply-To: <550761A4.7040001@oracle.com>
References: <55073FF4.9070606@oracle.com> <550748A2.9020604@oracle.com>
	<550753AA.4050804@oracle.com> <550761A4.7040001@oracle.com>
Message-ID: <55076FDA.9050009@oracle.com>

Hi, Phil.
The fix looks fine.
btw the change of bootmodules.jimage:
old: 56961944
new: 55879357

16.03.15 16:05, Phil Race wrote:
> One more update: http://cr.openjdk.java.net/~prr/8075277.2/
>
> just adds sun/awt/motif/* to the exclude list.
>
> I'm deleting that directory in another fix but those without those 
> changes need it
> excluded too
>
> -phil.
>
> On 3/16/15 3:05 PM, Phil Race wrote:
>> There are some files in sun/print some directories still being used 
>> but for the files
>> explicitly listed, then in each case all .java files in those 
>> directories are now unused.
>> So yes, I can make this cleaner and less fragile too!
>>
>> http://cr.openjdk.java.net/~prr/8075277.1/
>>
>> -phil.*
>> *
>> On 3/16/15 2:18 PM, Sergey Bylokhov wrote:
>>> Hi, Phil
>>> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" 
>>> using $(wildcard, or we still using some files on osx from the unix 
>>> folder?
>>>
>>>>
>>>> Although a more complete fix would do something like refactor the 
>>>> source files,
>>>> as that would be less fragile amongst other things, this at least 
>>>> gets us into a
>>>> better shape with minimal disruption - and solves my immediate 
>>>> problem :-)
>>> There is a CR for this: https://bugs.openjdk.java.net/browse/JDK-8075254
>>>> And it is not clear to me why there was an unused reference to
>>>> FontConfigManager in the Mac code. Removing it breaks
>>>> a link that dragged in X11 related code.
>>>>
>>>> I expect the files shipped on OS X to go down as a result of
>>>> removing these 'dead' ones.
>>>> I would also have got rid of the Windows L&F but that needs
>>>> a bit of work on the Swing side first : 
>>>> https://bugs.openjdk.java.net/browse/JDK-8075255
>>>>
>>>> -phil.
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150316/3f047da1/attachment.html>

From erik.joelsson at oracle.com  Tue Mar 17 12:06:41 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 17 Mar 2015 13:06:41 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
 related Java files on OSX
In-Reply-To: <550761A4.7040001@oracle.com>
References: <55073FF4.9070606@oracle.com>
	<550748A2.9020604@oracle.com>	<550753AA.4050804@oracle.com>
	<550761A4.7040001@oracle.com>
Message-ID: <550818D1.4070607@oracle.com>

Hello Phil,

A minor style issue. We would appreciate if the java.desktop_EXCLUDES 
followed the same style as java.desktop_EXCLUDE_FILES, with 4 spaces 
indent and a line break at the start and end, like this:

java.desktop_EXCLUDES += \
     sun/awt/X11 \
     sun/java2d/x11 \
     sun/java2d/jules \
     sun/java2d/xr \
     com/sun/java/swing/plaf/gtk \
     #

/Erik


On 2015-03-17 00:05, Phil Race wrote:
> One more update: http://cr.openjdk.java.net/~prr/8075277.2/
>
> just adds sun/awt/motif/* to the exclude list.
>
> I'm deleting that directory in another fix but those without those 
> changes need it
> excluded too
>
> -phil.
>
> On 3/16/15 3:05 PM, Phil Race wrote:
>> There are some files in sun/print some directories still being used 
>> but for the files
>> explicitly listed, then in each case all .java files in those 
>> directories are now unused.
>> So yes, I can make this cleaner and less fragile too!
>>
>> http://cr.openjdk.java.net/~prr/8075277.1/
>>
>> -phil.*
>> *
>> On 3/16/15 2:18 PM, Sergey Bylokhov wrote:
>>> Hi, Phil
>>> Is it possible to replace a long list "java.desktop_EXCLUDE_FILES" 
>>> using $(wildcard, or we still using some files on osx from the unix 
>>> folder?
>>>
>>>>
>>>> Although a more complete fix would do something like refactor the 
>>>> source files,
>>>> as that would be less fragile amongst other things, this at least 
>>>> gets us into a
>>>> better shape with minimal disruption - and solves my immediate 
>>>> problem :-)
>>> There is a CR for this: 
>>> https://bugs.openjdk.java.net/browse/JDK-8075254
>>>> And it is not clear to me why there was an unused reference to
>>>> FontConfigManager in the Mac code. Removing it breaks
>>>> a link that dragged in X11 related code.
>>>>
>>>> I expect the files shipped on OS X to go down as a result of
>>>> removing these 'dead' ones.
>>>> I would also have got rid of the Windows L&F but that needs
>>>> a bit of work on the Swing side first : 
>>>> https://bugs.openjdk.java.net/browse/JDK-8075255
>>>>
>>>> -phil.
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150317/4eaf2613/attachment.html>

From magnus.ihse.bursie at oracle.com  Tue Mar 17 15:22:46 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 17 Mar 2015 16:22:46 +0100
Subject: [OpenJDK 2D-Dev] RFR: 8075277 : JDK is still building X11
 related Java files on OSX
In-Reply-To: <550818D1.4070607@oracle.com>
References: <55073FF4.9070606@oracle.com>	<550748A2.9020604@oracle.com>	<550753AA.4050804@oracle.com>	<550761A4.7040001@oracle.com>
	<550818D1.4070607@oracle.com>
Message-ID: <550846C6.2060803@oracle.com>

On 2015-03-17 13:06, Erik Joelsson wrote:
> Hello Phil,
>
> A minor style issue. We would appreciate if the java.desktop_EXCLUDES 
> followed the same style as java.desktop_EXCLUDE_FILES, with 4 spaces 
> indent and a line break at the start and end, like this:
>
> java.desktop_EXCLUDES += \
>     sun/awt/X11 \
>     sun/java2d/x11 \
>     sun/java2d/jules \
>     sun/java2d/xr \
>     com/sun/java/swing/plaf/gtk \
>     #

Agree on the style fix. Apart from that, looks good to me!

/Magnus


From philip.race at oracle.com  Thu Mar 19 18:26:07 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 19 Mar 2015 11:26:07 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <55074BDE.1050602@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
	<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
Message-ID: <550B14BF.3040209@oracle.com>

Any comments ?

-phil.

On 03/16/2015 02:32 PM, Phil Race wrote:
> Here is an updated fix that instead of removing the sun.nio dependency 
> instead removes
> the jdk.charsets static dependency. From the internal API point of 
> view its sun.nio.cs.ext
> that is the issue, not sun.nio
>
> http://cr.openjdk.java.net/~prr/8035302.1/
>
>
> -phil.
>
> On 2/21/15 1:02 AM, Alan Bateman wrote:
>> On 20/02/2015 22:30, Phil Race wrote:
>>> On 2/20/2015 1:48 PM, Alan Bateman wrote:
>>>>
>>>> :
>>>>
>>>> 1. For the record, can you explain why the X11 charsets can't move 
>>>> to jdk.charsets? I have a vague recollection that they aren't 
>>>> standard but I can't recall any details.
>>>
>>> They aren't standard. And are (mostly) for X11 only. And if they did 
>>> then as I understand
>>> then we'd still have a dependency on the jdk.charsets module which 
>>> is one of the motivations
>>> for this, is it not ?
>> If the X11 charsets were into jdk.charsets then I assume the font 
>> code could access them via the charsets API. Would that work or does 
>> the font code need access beyond what the API provides? I'm mostly 
>> just trying to see whether this option has been explored or not.
>>
>>>
>>>>
>>>> 2. sun.nio.cs.ext.EUC_TWMapping is generated in the build and it 
>>>> doesn't look right to me to check in a copy. Same comment on EUC_KR 
>>>> and EUC_CN as it looks like they have been copied into X11KSC5601 
>>>> and X11GB2312. Have to look at generating these in the build instead?
>>>
>>> Of course I considered this but I don't see the need. They are 
>>> perfectly stable
>>> for our needs, and  they aren't all  completely identical  -so I'd 
>>> need new code to generate
>>> them and the work to get this done is already quite sufficient 
>>> without creating more
>>> that isn't needed.
>> I don't think we should be checking these into the src tree. If the 
>> solution involves a copy of these charsets then you need to look at 
>> the charset generation so that a copy is generated with a package 
>> name that you want.
>>
>>>
>>>>
>>>> 3. There is also a copy of sun.nio.cs.DoubleByte in the webrev. 
>>>> This used to be in sun.nio.cs.ext (and hence jdk.charsets) so maybe 
>>>> this patch started out before Sherman pushed the changes for 
>>>> JDK-8073152.
>>>
>>> Yes, I just learned of this but it doesn't make any difference to 
>>> this patch
>>> since its not moved to a public location.
>> The issue that we are trying to address here is the direct dependency 
>> on a service provider module (jdk.charsets). The sun.nio.cs is in the 
>> java.base module and it should be okay to continue with the qualified 
>> export (as is already in place).
>>
>> -Alan.
>



From mandy.chung at oracle.com  Fri Mar 20 03:19:47 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 19 Mar 2015 20:19:47 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <550B14BF.3040209@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
	<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
	<550B14BF.3040209@oracle.com>
Message-ID: <550B91D3.6000406@oracle.com>


On 03/16/2015 02:32 PM, Phil Race wrote:
>> Here is an updated fix that instead of removing the sun.nio 
>> dependency instead removes the jdk.charsets static dependency. From 
>> the internal API point of view its sun.nio.cs.ext that is the issue, 
>> not sun.nio
>>
>> http://cr.openjdk.java.net/~prr/8035302.1/
>>

Looks quite good and much cleaner.

src/jdk.charsets/unix/classes/sun/nio/cs/ext/CompoundTextSupport.java

    cls = Class.forName("sun.awt.motif." + enc);

Should we do something about this Class.forName?

modules.xml - you can take out <depend>jdk.charsets</depend>
from java.desktop module.  You can verify the module access
by make verify-modules target.

There are tests referencing sun.awt.motif that I assume you will
update and send out another webrev?

Tests under test/java/awt are expected and surprisingly there are
tests in test/sun/nio/cs:

test/sun/nio/cs/TestX11CNS.java
test/sun/nio/cs/TestX11JIS0201.java

thank you for doing this.
Mandy



From andrew.brygin at oracle.com  Fri Mar 20 11:30:49 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Fri, 20 Mar 2015 14:30:49 +0300
Subject: [OpenJDK 2D-Dev] [9] request for review: 8074954:
 ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
Message-ID: <550C04E9.2070807@oracle.com>

Hello,

  could you please review a fix for CR 8074954?

Bug: https://bugs.openjdk.java.net/browse/JDK-8074954
Webrev: http://cr.openjdk.java.net/~bae/8074954/9/webrev.00/

  The problem happens if an input stream does not contain enough data
  to read a multi-byte type (as 4-bytes integer or 2-bytes short)
  completely. In this case the actual number of obtained bytes is
  returned, and if we get at least one byte, the EOF exception in
  not triggered.
  As a result, an incorrect value is returned.

  Suggested fix is to check explicitly whether required number of bytes
  has been read.

  Supplied regression test demonstrates the problem.

  Please take a look.

Thanks,
Andrew.


From Sergey.Bylokhov at oracle.com  Fri Mar 20 17:32:52 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 20 Mar 2015 20:32:52 +0300
Subject: [OpenJDK 2D-Dev] [9] request for review: 8074954:
 ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
In-Reply-To: <550C04E9.2070807@oracle.com>
References: <550C04E9.2070807@oracle.com>
Message-ID: <550C59C4.6000000@oracle.com>

Hi, Andrew?
Hi, Andrew.
Should we update a readFully() also?
      * @exception java.io.EOFException if the stream reaches the end before
      * reading all the bytes.
      * @exception IOException if an I/O error occurs.
      */
     void readFully(byte[] b, int off, int len) throws IOException;

20.03.15 14:30, Andrew Brygin wrote:
> Hello,
>
>  could you please review a fix for CR 8074954?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074954
> Webrev: http://cr.openjdk.java.net/~bae/8074954/9/webrev.00/
>
>  The problem happens if an input stream does not contain enough data
>  to read a multi-byte type (as 4-bytes integer or 2-bytes short)
>  completely. In this case the actual number of obtained bytes is
>  returned, and if we get at least one byte, the EOF exception in
>  not triggered.
>  As a result, an incorrect value is returned.
>
>  Suggested fix is to check explicitly whether required number of bytes
>  has been read.
>
>  Supplied regression test demonstrates the problem.
>
>  Please take a look.
>
> Thanks,
> Andrew.


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150320/fe96b307/attachment.html>

From philip.race at oracle.com  Fri Mar 20 17:45:10 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 20 Mar 2015 10:45:10 -0700
Subject: [OpenJDK 2D-Dev] [9] request for review: 8074954:
 ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
In-Reply-To: <550C59C4.6000000@oracle.com>
References: <550C04E9.2070807@oracle.com> <550C59C4.6000000@oracle.com>
Message-ID: <550C5CA6.2070401@oracle.com>

Andrew, The fix looks good to me.

Sergey, are you asking for that text to be added ? Looks to me like its 
already there,
so probably I am not following what you mean.

-phil.

On 03/20/2015 10:32 AM, Sergey Bylokhov wrote:
> Hi, Andrew?
> Hi, Andrew.
> Should we update a readFully() also?
>      * @exception java.io.EOFException if the stream reaches the end 
> before
>      * reading all the bytes.
>      * @exception IOException if an I/O error occurs.
>      */
>     void readFully(byte[] b, int off, int len) throws IOException;
>
> 20.03.15 14:30, Andrew Brygin wrote:
>> Hello,
>>
>>  could you please review a fix for CR 8074954?
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074954
>> Webrev: http://cr.openjdk.java.net/~bae/8074954/9/webrev.00/
>>
>>  The problem happens if an input stream does not contain enough data
>>  to read a multi-byte type (as 4-bytes integer or 2-bytes short)
>>  completely. In this case the actual number of obtained bytes is
>>  returned, and if we get at least one byte, the EOF exception in
>>  not triggered.
>>  As a result, an incorrect value is returned.
>>
>>  Suggested fix is to check explicitly whether required number of bytes
>>  has been read.
>>
>>  Supplied regression test demonstrates the problem.
>>
>>  Please take a look.
>>
>> Thanks,
>> Andrew.
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150320/428abdc2/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Mar 20 17:54:31 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 20 Mar 2015 20:54:31 +0300
Subject: [OpenJDK 2D-Dev] [9] request for review: 8074954:
 ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
In-Reply-To: <550C5CA6.2070401@oracle.com>
References: <550C04E9.2070807@oracle.com> <550C59C4.6000000@oracle.com>
	<550C5CA6.2070401@oracle.com>
Message-ID: <550C5ED7.4060608@oracle.com>

> Andrew, The fix looks good to me.
>
> Sergey, are you asking for that text to be added ? Looks to me like 
> its already there,
> so probably I am not following what you mean.
No, readFully() has this code:
             int nbytes = read(b, off, len);
             if (nbytes == -1) {
                 throw new EOFException();
             }
I assume this method should throw an exception if nbytes!=len as 
described in the specification. same as readShort/readInt.

>
> -phil.
>
> On 03/20/2015 10:32 AM, Sergey Bylokhov wrote:
>> Hi, Andrew?
>> Hi, Andrew.
>> Should we update a readFully() also?
>>      * @exception java.io.EOFException if the stream reaches the end 
>> before
>>      * reading all the bytes.
>>      * @exception IOException if an I/O error occurs.
>>      */
>>     void readFully(byte[] b, int off, int len) throws IOException;
>>
>> 20.03.15 14:30, Andrew Brygin wrote:
>>> Hello,
>>>
>>>  could you please review a fix for CR 8074954?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074954
>>> Webrev: http://cr.openjdk.java.net/~bae/8074954/9/webrev.00/
>>>
>>>  The problem happens if an input stream does not contain enough data
>>>  to read a multi-byte type (as 4-bytes integer or 2-bytes short)
>>>  completely. In this case the actual number of obtained bytes is
>>>  returned, and if we get at least one byte, the EOF exception in
>>>  not triggered.
>>>  As a result, an incorrect value is returned.
>>>
>>>  Suggested fix is to check explicitly whether required number of bytes
>>>  has been read.
>>>
>>>  Supplied regression test demonstrates the problem.
>>>
>>>  Please take a look.
>>>
>>> Thanks,
>>> Andrew.
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150320/ca0582a0/attachment.html>

From philip.race at oracle.com  Fri Mar 20 17:56:48 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 20 Mar 2015 10:56:48 -0700
Subject: [OpenJDK 2D-Dev] [9] request for review: 8074954:
 ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
In-Reply-To: <550C5ED7.4060608@oracle.com>
References: <550C04E9.2070807@oracle.com> <550C59C4.6000000@oracle.com>
	<550C5CA6.2070401@oracle.com> <550C5ED7.4060608@oracle.com>
Message-ID: <550C5F60.5040703@oracle.com>

I see. You were referring to the implementation. But your snippet
doesn't show the loop which should handle this case properly :

  350          while (len > 0) {
  351             int nbytes = read(b, off, len);
  352             if (nbytes == -1) {
  353                 throw new EOFException();
  354             }
  355             off += nbytes;
  356             len -= nbytes;
  357         }


-phil.

On 03/20/2015 10:54 AM, Sergey Bylokhov wrote:
>> Andrew, The fix looks good to me.
>>
>> Sergey, are you asking for that text to be added ? Looks to me like 
>> its already there,
>> so probably I am not following what you mean.
> No, readFully() has this code:
>             int nbytes = read(b, off, len);
>             if (nbytes == -1) {
>                 throw new EOFException();
>             }
> I assume this method should throw an exception if nbytes!=len as 
> described in the specification. same as readShort/readInt.
>
>>
>> -phil.
>>
>> On 03/20/2015 10:32 AM, Sergey Bylokhov wrote:
>>> Hi, Andrew?
>>> Hi, Andrew.
>>> Should we update a readFully() also?
>>>      * @exception java.io.EOFException if the stream reaches the end 
>>> before
>>>      * reading all the bytes.
>>>      * @exception IOException if an I/O error occurs.
>>>      */
>>>     void readFully(byte[] b, int off, int len) throws IOException;
>>>
>>> 20.03.15 14:30, Andrew Brygin wrote:
>>>> Hello,
>>>>
>>>>  could you please review a fix for CR 8074954?
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074954
>>>> Webrev: http://cr.openjdk.java.net/~bae/8074954/9/webrev.00/
>>>>
>>>>  The problem happens if an input stream does not contain enough data
>>>>  to read a multi-byte type (as 4-bytes integer or 2-bytes short)
>>>>  completely. In this case the actual number of obtained bytes is
>>>>  returned, and if we get at least one byte, the EOF exception in
>>>>  not triggered.
>>>>  As a result, an incorrect value is returned.
>>>>
>>>>  Suggested fix is to check explicitly whether required number of bytes
>>>>  has been read.
>>>>
>>>>  Supplied regression test demonstrates the problem.
>>>>
>>>>  Please take a look.
>>>>
>>>> Thanks,
>>>> Andrew.
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150320/bd965098/attachment.html>

From Sergey.Bylokhov at oracle.com  Fri Mar 20 18:03:45 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 20 Mar 2015 21:03:45 +0300
Subject: [OpenJDK 2D-Dev] [9] request for review: 8074954:
 ImageInputStreamImpl.readShort/readInt do not behave correctly at EOF
In-Reply-To: <550C5F60.5040703@oracle.com>
References: <550C04E9.2070807@oracle.com> <550C59C4.6000000@oracle.com>
	<550C5CA6.2070401@oracle.com> <550C5ED7.4060608@oracle.com>
	<550C5F60.5040703@oracle.com>
Message-ID: <550C6101.6090008@oracle.com>

Right. It will be thrown on the next iteration.
The fix looks fine then.

20.03.15 20:56, Phil Race wrote:
> I see. You were referring to the implementation. But your snippet
> doesn't show the loop which should handle this case properly :
>   350          while (len > 0) {
>   351             int nbytes = read(b, off, len);
>   352             if (nbytes == -1) {
>   353                 throw new EOFException();
>   354             }
>   355             off += nbytes;
>   356             len -= nbytes;
>   357         }
>
> -phil.
>
> On 03/20/2015 10:54 AM, Sergey Bylokhov wrote:
>>> Andrew, The fix looks good to me.
>>>
>>> Sergey, are you asking for that text to be added ? Looks to me like 
>>> its already there,
>>> so probably I am not following what you mean.
>> No, readFully() has this code:
>>             int nbytes = read(b, off, len);
>>             if (nbytes == -1) {
>>                 throw new EOFException();
>>             }
>> I assume this method should throw an exception if nbytes!=len as 
>> described in the specification. same as readShort/readInt.
>>
>>>
>>> -phil.
>>>
>>> On 03/20/2015 10:32 AM, Sergey Bylokhov wrote:
>>>> Hi, Andrew?
>>>> Hi, Andrew.
>>>> Should we update a readFully() also?
>>>>      * @exception java.io.EOFException if the stream reaches the 
>>>> end before
>>>>      * reading all the bytes.
>>>>      * @exception IOException if an I/O error occurs.
>>>>      */
>>>>     void readFully(byte[] b, int off, int len) throws IOException;
>>>>
>>>> 20.03.15 14:30, Andrew Brygin wrote:
>>>>> Hello,
>>>>>
>>>>>  could you please review a fix for CR 8074954?
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074954
>>>>> Webrev: http://cr.openjdk.java.net/~bae/8074954/9/webrev.00/
>>>>>
>>>>>  The problem happens if an input stream does not contain enough data
>>>>>  to read a multi-byte type (as 4-bytes integer or 2-bytes short)
>>>>>  completely. In this case the actual number of obtained bytes is
>>>>>  returned, and if we get at least one byte, the EOF exception in
>>>>>  not triggered.
>>>>>  As a result, an incorrect value is returned.
>>>>>
>>>>>  Suggested fix is to check explicitly whether required number of 
>>>>> bytes
>>>>>  has been read.
>>>>>
>>>>>  Supplied regression test demonstrates the problem.
>>>>>
>>>>>  Please take a look.
>>>>>
>>>>> Thanks,
>>>>> Andrew.
>>>>
>>>>
>>>> -- 
>>>> Best regards, Sergey.
>>>
>>
>>
>> -- 
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150320/e078c7e5/attachment.html>

From philip.race at oracle.com  Fri Mar 20 21:39:01 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 20 Mar 2015 14:39:01 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <550B91D3.6000406@oracle.com>
References: <54E7ABB8.7010901@oracle.com> <54E7B587.70904@oracle.com>
	<54E8499F.7060706@oracle.com> <55074BDE.1050602@oracle.com>
	<550B14BF.3040209@oracle.com> <550B91D3.6000406@oracle.com>
Message-ID: <550C9375.8070404@oracle.com>

On 3/19/15 8:19 PM, Mandy Chung wrote:
>
> On 03/16/2015 02:32 PM, Phil Race wrote:
>>> Here is an updated fix that instead of removing the sun.nio 
>>> dependency instead removes the jdk.charsets static dependency. From 
>>> the internal API point of view its sun.nio.cs.ext that is the issue, 
>>> not sun.nio
>>>
>>> http://cr.openjdk.java.net/~prr/8035302.1/
>>>
>
> Looks quite good and much cleaner.
>
> src/jdk.charsets/unix/classes/sun/nio/cs/ext/CompoundTextSupport.java
>
>    cls = Class.forName("sun.awt.motif." + enc);
>
> Should we do something about this Class.forName?

Hmm .. that class is littered with references to X11 !
eg
  if (isEncodingSupported("X11GB2312")) {

Sherman : why is all of this here ?

>
> modules.xml - you can take out <depend>jdk.charsets</depend>
> from java.desktop module.  You can verify the module access
> by make verify-modules target.
>
> There are tests referencing sun.awt.motif that I assume you will
> update and send out another webrev?
>
> Tests under test/java/awt are expected and surprisingly there are
> tests in test/sun/nio/cs:
>
> test/sun/nio/cs/TestX11CNS.java
> test/sun/nio/cs/TestX11JIS0201.java

I am getting rid of these
>
> thank you for doing this.
> Mandy
>



From neugens at redhat.com  Tue Mar 24 15:35:12 2015
From: neugens at redhat.com (Mario Torre)
Date: Tue, 24 Mar 2015 16:35:12 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
	https://bugs.openjdk.java.net/browse/JDK-8069312 ??
Message-ID: <1427211312.3866.93.camel@galactica>

Hi all,

I just received some emails related to the backports of bug
https://bugs.openjdk.java.net/browse/JDK-8067364

I've seen in particular JDK-8069312 is being closed as "Won't Fix".

There are no comments on the bug report and it's not clear what version
this is related to.

Can somebody explain what's going on?

Thanks,
Mario




From dalibor.topic at oracle.com  Tue Mar 24 15:56:32 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Tue, 24 Mar 2015 16:56:32 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <1427211312.3866.93.camel@galactica>
References: <1427211312.3866.93.camel@galactica>
Message-ID: <55118930.8060508@oracle.com>

On 24.03.2015 16:35, Mario Torre wrote:
> Hi all,
>
> I just received some emails related to the backports of bug
> https://bugs.openjdk.java.net/browse/JDK-8067364
>
> I've seen in particular JDK-8069312 is being closed as "Won't Fix".

Fix version for that issue is '7-pool'. That means the fix won't be 
backported to OpenJDK 7u.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From neugens at redhat.com  Tue Mar 24 16:24:26 2015
From: neugens at redhat.com (Mario Torre)
Date: Tue, 24 Mar 2015 17:24:26 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <55118930.8060508@oracle.com>
References: <1427211312.3866.93.camel@galactica> <55118930.8060508@oracle.com>
Message-ID: <1427214266.3866.94.camel@galactica>

On Tue, 2015-03-24 at 16:56 +0100, dalibor topic wrote:
> On 24.03.2015 16:35, Mario Torre wrote:
> > Hi all,
> >
> > I just received some emails related to the backports of bug
> > https://bugs.openjdk.java.net/browse/JDK-8067364
> >
> > I've seen in particular JDK-8069312 is being closed as "Won't Fix".
> 
> Fix version for that issue is '7-pool'. That means the fix won't be 
> backported to OpenJDK 7u.

But we said the next maintainer would be responsible to decide this so
the fix was just in hold for now, then why "won't fix"? Am I missing
something?

Cheers,
Mario




From philip.race at oracle.com  Tue Mar 24 17:16:18 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 24 Mar 2015 10:16:18 -0700
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <1427214266.3866.94.camel@galactica>
References: <1427211312.3866.93.camel@galactica> <55118930.8060508@oracle.com>
	<1427214266.3866.94.camel@galactica>
Message-ID: <55119BE2.6020301@oracle.com>

I think this is a round-about way of saying that Oracle is moving
its OpenJDK efforts off 7 to focus on just jdk8u and jdk9 and
the sustaining engineering group won't be proactively backporting
it to any Oracle JDK7 update release, which is probably just security
releases going forward.

Now, since this regression was new in 7u65 I do think it important
to fix in any 7 train that we might expect people to use .. so
I am sure the new maintainer of openjdk 7 updates will be happy
to let it in and perhaps it should have been fixed in 7-pool whatever
that really means, but that's up to someone else.

However I am not sure how the openjdk7 fixes will be tracked going forward
i.e is it still JBS but there is some other target release value that 
should be being used ?

-phil.

On 3/24/2015 9:24 AM, Mario Torre wrote:
> On Tue, 2015-03-24 at 16:56 +0100, dalibor topic wrote:
>> On 24.03.2015 16:35, Mario Torre wrote:
>>> Hi all,
>>>
>>> I just received some emails related to the backports of bug
>>> https://bugs.openjdk.java.net/browse/JDK-8067364
>>>
>>> I've seen in particular JDK-8069312 is being closed as "Won't Fix".
>> Fix version for that issue is '7-pool'. That means the fix won't be
>> backported to OpenJDK 7u.
> But we said the next maintainer would be responsible to decide this so
> the fix was just in hold for now, then why "won't fix"? Am I missing
> something?
>
> Cheers,
> Mario
>
>



From dalibor.topic at oracle.com  Tue Mar 24 17:19:23 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Tue, 24 Mar 2015 18:19:23 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <1427214266.3866.94.camel@galactica>
References: <1427211312.3866.93.camel@galactica>	 <55118930.8060508@oracle.com>
	<1427214266.3866.94.camel@galactica>
Message-ID: <55119C9B.4050508@oracle.com>



On 24.03.2015 17:24, Mario Torre wrote:
 > Am I missing something?

Yes. See 
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2015-March/010279.html 
for details.

cheers,
dalibor topic
-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From philip.race at oracle.com  Tue Mar 24 17:28:18 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 24 Mar 2015 10:28:18 -0700
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <55119BE2.6020301@oracle.com>
References: <1427211312.3866.93.camel@galactica>
	<55118930.8060508@oracle.com>	<1427214266.3866.94.camel@galactica>
	<55119BE2.6020301@oracle.com>
Message-ID: <55119EB2.60805@oracle.com>

 > i.e is it still JBS but there is some other target release value that 
should be being used ?

It seems that question has been answered in the link Dalibor sent : its 
"openjdk7u"
for the release.

-phil.

On 3/24/2015 10:16 AM, Phil Race wrote:
> I think this is a round-about way of saying that Oracle is moving
> its OpenJDK efforts off 7 to focus on just jdk8u and jdk9 and
> the sustaining engineering group won't be proactively backporting
> it to any Oracle JDK7 update release, which is probably just security
> releases going forward.
>
> Now, since this regression was new in 7u65 I do think it important
> to fix in any 7 train that we might expect people to use .. so
> I am sure the new maintainer of openjdk 7 updates will be happy
> to let it in and perhaps it should have been fixed in 7-pool whatever
> that really means, but that's up to someone else.
>
> However I am not sure how the openjdk7 fixes will be tracked going 
> forward
> i.e is it still JBS but there is some other target release value that 
> should be being used ?
>
> -phil.
>
> On 3/24/2015 9:24 AM, Mario Torre wrote:
>> On Tue, 2015-03-24 at 16:56 +0100, dalibor topic wrote:
>>> On 24.03.2015 16:35, Mario Torre wrote:
>>>> Hi all,
>>>>
>>>> I just received some emails related to the backports of bug
>>>> https://bugs.openjdk.java.net/browse/JDK-8067364
>>>>
>>>> I've seen in particular JDK-8069312 is being closed as "Won't Fix".
>>> Fix version for that issue is '7-pool'. That means the fix won't be
>>> backported to OpenJDK 7u.
>> But we said the next maintainer would be responsible to decide this so
>> the fix was just in hold for now, then why "won't fix"? Am I missing
>> something?
>>
>> Cheers,
>> Mario
>>
>>
>



From neugens at redhat.com  Tue Mar 24 17:34:40 2015
From: neugens at redhat.com (Mario Torre)
Date: Tue, 24 Mar 2015 18:34:40 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <55119EB2.60805@oracle.com>
References: <1427211312.3866.93.camel@galactica>
	<55118930.8060508@oracle.com>	<1427214266.3866.94.camel@galactica>
	<55119BE2.6020301@oracle.com> <55119EB2.60805@oracle.com>
Message-ID: <1427218480.3866.97.camel@galactica>

On Tue, 2015-03-24 at 10:28 -0700, Phil Race wrote:
>  > i.e is it still JBS but there is some other target release value that 
> should be being used ?
> 
> It seems that question has been answered in the link Dalibor sent : its 
> "openjdk7u"
> for the release.

Yes, this makes totally sense, however the bug was closed as won't fix.

I know I'm failing from my side in adjusting to this new work flow so
please indulge me, but I would expect the bug to be still open and just
move from 7-pool to openjdk7u.

Or will a new backport be createad with openjdk7u as target release?

Thanks,
Mario




From philip.race at oracle.com  Tue Mar 24 17:48:01 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 24 Mar 2015 10:48:01 -0700
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <1427218480.3866.97.camel@galactica>
References: <1427211312.3866.93.camel@galactica>	
	<55118930.8060508@oracle.com>	<1427214266.3866.94.camel@galactica>	
	<55119BE2.6020301@oracle.com> <55119EB2.60805@oracle.com>
	<1427218480.3866.97.camel@galactica>
Message-ID: <5511A351.2080300@oracle.com>

On 3/24/2015 10:34 AM, Mario Torre wrote:
> On Tue, 2015-03-24 at 10:28 -0700, Phil Race wrote:
>>   > i.e is it still JBS but there is some other target release value that
>> should be being used ?
>>
>> It seems that question has been answered in the link Dalibor sent : its
>> "openjdk7u"
>> for the release.
> Yes, this makes totally sense, however the bug was closed as won't fix.
>
> I know I'm failing from my side in adjusting to this new work flow so
> please indulge me, but I would expect the bug to be still open and just
> move from 7-pool to openjdk7u.

There is a workflow - one that I think is over-used - of creating 
backports and
closing them as "not an issue", or "will not fix", as a way of making it 
clear
that "we didn't just forget about this release, we made a decision 
documented here".
Sometimes they are created and closed like that all in the blink of an eye.
That's not exactly what happened here, since I think there may have been an
intent to fix that was rescinded, but probably it could be considered to 
document
that better by its presence than its absence.

>
> Or will a new backport be createad with openjdk7u as target release?

* If you pushed to the new openjdk 7 without doing anything, then a new 
backport will
be automatically created when you push
* If you create a new one manually, assign to yourself, target it to  
openjdk7, then that one
will get marked fixed when you push
* Or, you could re-open the existing one, target it to openjdk7u (and 
assign to yourself)
and it will be marked fixed when you push. However I think the workflow 
I documented
above will then be messed up.

-phil.

>
> Thanks,
> Mario
>
>



From dalibor.topic at oracle.com  Tue Mar 24 18:05:22 2015
From: dalibor.topic at oracle.com (dalibor topic)
Date: Tue, 24 Mar 2015 19:05:22 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <1427218480.3866.97.camel@galactica>
References: <1427211312.3866.93.camel@galactica>	
	<55118930.8060508@oracle.com>	<1427214266.3866.94.camel@galactica>	
	<55119BE2.6020301@oracle.com> <55119EB2.60805@oracle.com>
	<1427218480.3866.97.camel@galactica>
Message-ID: <5511A762.2070604@oracle.com>



On 24.03.2015 18:34, Mario Torre wrote:
> Or will a new backport be createad with openjdk7u as target release?

The proposal is to adjust hgupdater to set fixVersion to 'openjdk7u' 
after 7u80 GA on the backport issues which are automatically created for 
you when you push to a jdk7u(-dev) forest.

cheers,
dalibor topic

-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603
Gesch?ftsf?hrer: J?rgen Kunz

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment


From neugens at redhat.com  Wed Mar 25 09:46:18 2015
From: neugens at redhat.com (Mario Torre)
Date: Wed, 25 Mar 2015 10:46:18 +0100
Subject: [OpenJDK 2D-Dev] Won't fix
 https://bugs.openjdk.java.net/browse/JDK-8069312 ??
In-Reply-To: <5511A351.2080300@oracle.com>
References: <1427211312.3866.93.camel@galactica>
	<55118930.8060508@oracle.com>	<1427214266.3866.94.camel@galactica>
	<55119BE2.6020301@oracle.com> <55119EB2.60805@oracle.com>
	<1427218480.3866.97.camel@galactica> <5511A351.2080300@oracle.com>
Message-ID: <1427276778.3866.104.camel@galactica>

On Tue, 2015-03-24 at 10:48 -0700, Phil Race wrote:
> On 3/24/2015 10:34 AM, Mario Torre wrote:
> > On Tue, 2015-03-24 at 10:28 -0700, Phil Race wrote:
> >>   > i.e is it still JBS but there is some other target release value that
> >> should be being used ?
> >>
> >> It seems that question has been answered in the link Dalibor sent : its
> >> "openjdk7u"
> >> for the release.
> > Yes, this makes totally sense, however the bug was closed as won't fix.
> >
> > I know I'm failing from my side in adjusting to this new work flow so
> > please indulge me, but I would expect the bug to be still open and just
> > move from 7-pool to openjdk7u.
> 
> There is a workflow - one that I think is over-used - of creating 
> backports and
> closing them as "not an issue", or "will not fix", as a way of making it 
> clear
> that "we didn't just forget about this release, we made a decision 
> documented here".
> Sometimes they are created and closed like that all in the blink of an eye.
> That's not exactly what happened here, since I think there may have been an
> intent to fix that was rescinded, but probably it could be considered to 
> document
> that better by its presence than its absence.

Ok, I see.

I guess what bothers me is the lack of comments on the bug report then,
from the external it appears as if someone just unilaterally decided the
bug won't be fixed without offering any explanation.

I still think that increasing the release flag and add a comment is a
better thing to do.

> >
> > Or will a new backport be createad with openjdk7u as target release?
> 
> * If you pushed to the new openjdk 7 without doing anything, then a new 
> backport will
> be automatically created when you push
> * If you create a new one manually, assign to yourself, target it to  
> openjdk7, then that one
> will get marked fixed when you push
> * Or, you could re-open the existing one, target it to openjdk7u (and 
> assign to yourself)
> and it will be marked fixed when you push. However I think the workflow 
> I documented
> above will then be messed up.

Right, I'll either create a new report or push directly then, I'll try
my best to not mess up the workflow :)

Cheers,
Mario




From alexander.v.stepanov at oracle.com  Wed Mar 25 10:31:21 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Wed, 25 Mar 2015 13:31:21 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8075934 Fix some tidy
 warnings/errors for javax/imageio
Message-ID: <55128E79.5040605@oracle.com>

Hello,

Could you please review the fix for
https://bugs.openjdk.java.net/browse/JDK-8075934

Webrev:
http://cr.openjdk.java.net/~avstepan/8075934/webrev.01/

Just a small HTML markup fix.

Thanks,
Alexander


From andrew.brygin at oracle.com  Wed Mar 25 14:51:29 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Wed, 25 Mar 2015 17:51:29 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
 Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <548B21D2.8080701@oracle.com>
References: <CA+3bSS-SWXEzmcCDttDb8Odp_sozPxv_A0k4zAZvPQ+uU4Ka=A@mail.gmail.com>	<53BD5E45.4000805@oracle.com>	<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>	<54297B00.5020604@oracle.com>	<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>	<5437EE69.3090606@oracle.com>
	<54380F42.7060705@oracle.com>	<54381FFC.5000507@oracle.com>
	<5438465D.5070503@oracle.com>	<54384C03.5020006@oracle.com>
	<543ADF1B.9020802@oracle.com>	<543BC85F.8050202@oracle.com>
	<543C62AC.2010907@oracle.com>	<544A92CC.10406@oracle.com>
	<544AB09D.5060805@oracle.com> <548B21D2.8080701@oracle.com>
Message-ID: <5512CB71.30908@oracle.com>

Hello Phil,

  could you please take a look to updated version of the fix?

http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/

* CGGlyphImages.m
  The main part of the recent changes is related to generation of LCD 
glyph images.
  With previous version of the fix we produced lcd glyphs which were quite
  close to jdk6 results if we render dark text on light background 
(black on white
  as an extreme case).
  However, it was discovered that in the case of light text on dark 
background,
  our results had significant differences  comparing with jdk6.
  In order to reduce the difference, now we produce two separate glyph 
images
  (black-on-white and white-on-black), blend them, and then pass the blended
  glyph image to text pipes. This approach seems to give an acceptable  
results
  for both light and dark cases.

*  OGLTextRenderer.c
  It was discovered, that in some cases lcd glyphs had visible 'dark 
border' around.
  This border appeared due to the gamma correction in lcd shader, which 
uses lookup
  on 3D texture instead of using 'pow' routine. The texture is populated 
with significant
  granularity (16 points per edge), what is a root cause of rough 
interpolation of color values.
  Suggested change is to eliminate the interpolation and use 'pow' 
routine directly.
  It gives more accurate color values, and does not introduce 
significant performance hit
  (see benchmark summary below).
  However, this part of the fix affects not only macosx, but any 
platform where OGL text
  shader can be used, so it probably worth to split into a separate fix.

Summary:
   lcd-ogl-3Dlookup:
     Number of tests:  4
     Overall average:  42.68027553311743
     Best spread:      3.49% variance
     Worst spread:     29.59% variance
     (Basis for results comparison)

   lcd-ogl-pow:
     Number of tests:  4
     Overall average:  42.468941501367084
     Best spread:      2.51% variance
     Worst spread:     29.44% variance
     Comparison to basis:
       Best result:      103.28% of basis
       Worst result:     97.36% of basis
       Number of wins:   1
       Number of ties:   2
       Number of losses: 1

Thanks,
Andrew


On 12/12/2014 8:11 PM, Andrew Brygin wrote:
> Hello Phil,
>
>  at the moment, I failed to get acceptable results for rendering to 
> translucent destination.
>  I am playing with an idea to fall back to grayscale AA on non-opaque 
> pixels (or pixels with
>  opacity less than a certain threshold) directly in the lcd shader 
> program.
>
>  For now, there is an updated version of the fix which supports lcd 
> text in OGL pipeline
>  for a case of  alpha paint and default composite. However, the case 
> of translucent
>  destination is not supported yet, that makes lcd text unavailable in 
> swing apps
>  on macosx.
>
>  All changes specific for this version are in OGLSurfaceData.java and 
> OGLTextRenderer.c.
>  Rest of the fix is unchanged.
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.04/
>
>  Of course,  this version may affect the performance of lcd text 
> rendering, but
>  I have no numbers to estimate the effect at the moment. In the worst 
> case,
>  we can consider to use two different programs: one for opaque paint 
> (in order
>  to preserve performance), and another (like published now) for the 
> case of alpha
>  paint.
>
>  Please take a look.
>
> Thanks,
> Andrew
>
> On 10/25/2014 12:03 AM, Phil Race wrote:
>> On 10/24/2014 10:56 AM, Andrew Brygin wrote:
>>> Hello,
>>>
>>>  please take a look to updated version of the fix:
>>>
>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.03/
>>>
>>>  TODOs were removed:
>>>  * CGLSurfaceData.java
>>>       the condition for lcd rendering is inherited from OGL surface 
>>> data, but
>>>       here we have to remove the check for the transparency, because 
>>> we always
>>>       create transparent  volatile images for swing backbuffers on 
>>> macosx in order
>>>       to support shaped windows.
>>
>> Are you saying its created translucent regardless, or only if its 
>> shaped?
>> But if its really translucent/transparent under the text, then
>> IIRC the shaders - and s/w loops - do not properly handle that case.
>> You probably should try drawing LCD text over a fully transparent area
>> to see what happens.
>>
>>>
>>> * * *CGGlyphImages.m and AWTStrike.m
>>>       NSException is used to  handle invalid (unevaluated) text 
>>> antialising hint values.
>>>       We actually have already used NSException to handle memory 
>>> allocation failure,
>>>       so this change just makes usage of get/release of primitive 
>>> arrays a bit more safe.
>>>
>>>
>>> Known differences comparing to apple jdk6:
>>>
>>> a) we do not interpret TEXT_ANTIALIASING_ON as lcd text.
>>
>> Its should never have meant that, else you would have no way to 
>> explicitly
>> request grey scale.
>>>
>>> b) we do not render lcd text in a case of non-opaque paint. This 
>>> behavior is common for
>>>      all cases (software loops, OGL, and D3D), so it seems to 
>>> deserve a separate bug if we
>>>      want to handle this case.
>>
>> I think that's another manifestation of the issue mentioned above.
>>
>> -phil.
>>
>



From campbell at plausible.coop  Wed Mar 25 17:24:33 2015
From: campbell at plausible.coop (Chris Campbell)
Date: Wed, 25 Mar 2015 10:24:33 -0700
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
 Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <5512CB71.30908@oracle.com>
References: <CA+3bSS-SWXEzmcCDttDb8Odp_sozPxv_A0k4zAZvPQ+uU4Ka=A@mail.gmail.com>	<53BD5E45.4000805@oracle.com>	<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>	<54297B00.5020604@oracle.com>	<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>	<5437EE69.3090606@oracle.com>
	<54380F42.7060705@oracle.com>	<54381FFC.5000507@oracle.com>
	<5438465D.5070503@oracle.com>	<54384C03.5020006@oracle.com>
	<543ADF1B.9020802@oracle.com>	<543BC85F.8050202@oracle.com>
	<543C62AC.2010907@oracle.com>	<544A92CC.10406@oracle.com>
	<544AB09D.5060805@oracle.com> <548B21D2.8080701@oracle.com>
	<5512CB71.30908@oracle.com>
Message-ID: <5512EF51.7070907@plausible.coop>

Hi Andrew,

That's a good find re: pow().  In the comment at lines 277-283 I 
mentioned that there was only a scalar variant of pow().  I wonder if 
that was a limitation in some early version of GLSL I was using or 
perhaps some driver bug/restriction.  According to all the docs I can 
find the vector variants have been there all along:
https://www.opengl.org/sdk/docs/man4/index.php

So now I'm wondering if the slowness was actually due to me trying 3 
scalar pow() calls versus one vector pow() call.

Oh, aha!  I think this explains part of it:

  269  * This is the GLSL fragment shader source code for rendering 
LCD-optimized
  270  * text.  Do not be frightened; it is much easier to understand 
than the
  271  * equivalent ASM-like fragment program!

Looks like I wrote the original version of this shader using the 
GL_ARB_fragment_program language, which indeed only had a scalar POW 
instruction (see section 3.11.5.20):
https://www.opengl.org/registry/specs/ARB/fragment_program.txt

And then I'm guessing that when I rewrote it in more modern GLSL, I 
didn't notice that pow() supported vectors.  Sigh.  That 3D texture LUT 
was a lot of work for a whole lot of nothing.

In any case, you might want to rewrite the comment at lines 277-283 to 
suit the new code.  Same goes for the comment at line 315:

     // gamma adjust the dest color using the invgamma LUT

Also, I noticed that the restrictions in 
OGLContext_IsLCDShaderSupportAvailable() could be loosened since you 
only need 2 texture units now.  Just in the extremely unlikely case that 
anyone's running this stuff on ancient hardware :)

Thanks,
Chris


Andrew Brygin wrote:
> Hello Phil,
>
> could you please take a look to updated version of the fix?
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>
> * OGLTextRenderer.c
> It was discovered, that in some cases lcd glyphs had visible 'dark
> border' around.
> This border appeared due to the gamma correction in lcd shader, which
> uses lookup
> on 3D texture instead of using 'pow' routine. The texture is populated
> with significant
> granularity (16 points per edge), what is a root cause of rough
> interpolation of color values.
> Suggested change is to eliminate the interpolation and use 'pow' routine
> directly.
> It gives more accurate color values, and does not introduce significant
> performance hit
> (see benchmark summary below).
> However, this part of the fix affects not only macosx, but any platform
> where OGL text
> shader can be used, so it probably worth to split into a separate fix.
>
> Summary:
> lcd-ogl-3Dlookup:
> Number of tests: 4
> Overall average: 42.68027553311743
> Best spread: 3.49% variance
> Worst spread: 29.59% variance
> (Basis for results comparison)
>
> lcd-ogl-pow:
> Number of tests: 4
> Overall average: 42.468941501367084
> Best spread: 2.51% variance
> Worst spread: 29.44% variance
> Comparison to basis:
> Best result: 103.28% of basis
> Worst result: 97.36% of basis
> Number of wins: 1
> Number of ties: 2
> Number of losses: 1
>
> Thanks,
> Andrew
>
>


From Sergey.Bylokhov at oracle.com  Wed Mar 25 18:27:04 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 25 Mar 2015 21:27:04 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8075934 Fix some tidy
 warnings/errors for javax/imageio
In-Reply-To: <55128E79.5040605@oracle.com>
References: <55128E79.5040605@oracle.com>
Message-ID: <5512FDF8.2090908@oracle.com>

Hi, Alexander.
The fix looks good.

25.03.15 13:31, alexander stepanov wrote:
> Hello,
>
> Could you please review the fix for
> https://bugs.openjdk.java.net/browse/JDK-8075934
>
> Webrev:
> http://cr.openjdk.java.net/~avstepan/8075934/webrev.01/
>
> Just a small HTML markup fix.
>
> Thanks,
> Alexander


-- 
Best regards, Sergey.



From philip.race at oracle.com  Wed Mar 25 22:48:22 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 25 Mar 2015 15:48:22 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <550C9375.8070404@oracle.com>
References: <54E7ABB8.7010901@oracle.com>
	<54E7B587.70904@oracle.com>	<54E8499F.7060706@oracle.com>
	<55074BDE.1050602@oracle.com>	<550B14BF.3040209@oracle.com>
	<550B91D3.6000406@oracle.com> <550C9375.8070404@oracle.com>
Message-ID: <55133B36.5040109@oracle.com>

Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/

- removed the jdk.charsets export to java.desktop from modules.xml

- removed the COMPOUND_TEXT support which likely has not been used since 
Motif support was removed

-phil.

On 3/20/15 2:39 PM, Phil Race wrote:
> On 3/19/15 8:19 PM, Mandy Chung wrote:
>>
>> On 03/16/2015 02:32 PM, Phil Race wrote:
>>>> Here is an updated fix that instead of removing the sun.nio 
>>>> dependency instead removes the jdk.charsets static dependency. From 
>>>> the internal API point of view its sun.nio.cs.ext that is the 
>>>> issue, not sun.nio
>>>>
>>>> http://cr.openjdk.java.net/~prr/8035302.1/
>>>>
>>
>> Looks quite good and much cleaner.
>>
>> src/jdk.charsets/unix/classes/sun/nio/cs/ext/CompoundTextSupport.java
>>
>>    cls = Class.forName("sun.awt.motif." + enc);
>>
>> Should we do something about this Class.forName?
>
> Hmm .. that class is littered with references to X11 !
> eg
>  if (isEncodingSupported("X11GB2312")) {
>
> Sherman : why is all of this here ?
>
>>
>> modules.xml - you can take out <depend>jdk.charsets</depend>
>> from java.desktop module.  You can verify the module access
>> by make verify-modules target.
>>
>> There are tests referencing sun.awt.motif that I assume you will
>> update and send out another webrev?
>>
>> Tests under test/java/awt are expected and surprisingly there are
>> tests in test/sun/nio/cs:
>>
>> test/sun/nio/cs/TestX11CNS.java
>> test/sun/nio/cs/TestX11JIS0201.java
>
> I am getting rid of these
>>
>> thank you for doing this.
>> Mandy
>>
>



From Alan.Bateman at oracle.com  Thu Mar 26 08:11:20 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Mar 2015 08:11:20 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <55133B36.5040109@oracle.com>
References: <54E7ABB8.7010901@oracle.com>
	<54E7B587.70904@oracle.com>	<54E8499F.7060706@oracle.com>
	<55074BDE.1050602@oracle.com>	<550B14BF.3040209@oracle.com>
	<550B91D3.6000406@oracle.com> <550C9375.8070404@oracle.com>
	<55133B36.5040109@oracle.com>
Message-ID: <5513BF28.30002@oracle.com>

On 25/03/2015 22:48, Phil Race wrote:
> Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
>
> - removed the jdk.charsets export to java.desktop from modules.xml
>
> - removed the COMPOUND_TEXT support which likely has not been used 
> since Motif support was removed
This looks good to me. The code in FontDescriptor to get the historical 
name is indeed odd, I don't know if Sherman has any other suggestions 
for this.

Is there anything that can be salvaged from the tests? That is, are 
there are existing fonts tests that will exercise these charsets like 
the old tests in sun/nio/cs ?

-Alan




From alexander.v.stepanov at oracle.com  Thu Mar 26 10:00:11 2015
From: alexander.v.stepanov at oracle.com (alexander stepanov)
Date: Thu, 26 Mar 2015 13:00:11 +0300
Subject: [OpenJDK 2D-Dev] [9] Review Request: 8075934 Fix some tidy
 warnings/errors for javax/imageio
In-Reply-To: <5512FDF8.2090908@oracle.com>
References: <55128E79.5040605@oracle.com> <5512FDF8.2090908@oracle.com>
Message-ID: <5513D8AB.2070406@oracle.com>

Thanks!

On 25.03.2015 21:27, Sergey Bylokhov wrote:
> Hi, Alexander.
> The fix looks good.
>
> 25.03.15 13:31, alexander stepanov wrote:
>> Hello,
>>
>> Could you please review the fix for
>> https://bugs.openjdk.java.net/browse/JDK-8075934
>>
>> Webrev:
>> http://cr.openjdk.java.net/~avstepan/8075934/webrev.01/
>>
>> Just a small HTML markup fix.
>>
>> Thanks,
>> Alexander
>
>



From hs at tagtraum.com  Thu Mar 26 12:49:13 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 26 Mar 2015 13:49:13 +0100
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage screen
	compatible
Message-ID: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>

Hey there,

I'm in the process of moving some custom code to take advantage of the fairly new MultiResolutionImage capabilities.
Loading multi resolution stuff works nicely, but I fear drawing is a bit of a problem.

In my old mechanism, I would

- load images using the toolkit
- create a screen-compatible BufferedImage via graphicsConfiguration.createCompatibleImage(...)
- draw the image into said buffer
- and then paint the screen-compatible buffer when needed (typically in some Icon implementation)

The assumption here is that drawing the screen-compatible image is much faster than the toolkit image (which isn't necessarily screen-compatible, usually TYPE_INT_ARGB instead of TYPE_INT_ARGB_PRE).

AFAIK, there are no published java.* APIs for MultiResolutionImages.

So if I understand this correctly, there is currently no officially supported, high performance way to draw MultiResolutionImages.

Therefore, in the spirit of https://bugs.openjdk.java.net/browse/JDK-8059943, I'd like to suggest, to either move sun.awt.image.MultiResolutionImage to some java.* package, so that one can write an implementation that is fast.
Or provide a standard way to ensure that Toolkit-loaded images are screen-compatible. Perhaps a little tweak in sun.awt.image.ImageRepresentation or the code that calls it is all that's needed (i.e. a change of the default ColorModel in ToolkitImage). Or is that not possible because of compatibility reasons?

Does that sound reasonable? Am I missing something?

Thanks,

-hendrik

From andrew.brygin at oracle.com  Thu Mar 26 12:59:06 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Thu, 26 Mar 2015 15:59:06 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
 Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <5512EF51.7070907@plausible.coop>
References: <CA+3bSS-SWXEzmcCDttDb8Odp_sozPxv_A0k4zAZvPQ+uU4Ka=A@mail.gmail.com>	<53BD5E45.4000805@oracle.com>	<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>	<54297B00.5020604@oracle.com>	<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>	<5437EE69.3090606@oracle.com>
	<54380F42.7060705@oracle.com>	<54381FFC.5000507@oracle.com>
	<5438465D.5070503@oracle.com>	<54384C03.5020006@oracle.com>
	<543ADF1B.9020802@oracle.com>	<543BC85F.8050202@oracle.com>
	<543C62AC.2010907@oracle.com>	<544A92CC.10406@oracle.com>
	<544AB09D.5060805@oracle.com> <548B21D2.8080701@oracle.com>
	<5512CB71.30908@oracle.com> <5512EF51.7070907@plausible.coop>
Message-ID: <5514029A.1090101@oracle.com>

Hi Chris,

  thank you for the comments and explanation. I have updated the 
OGLContext_IsLCDShaderSupportAvailable()
  and comments in OGLTextRenderer.c accordingly:

http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/

  Good to know that you keep an eye on the OGL pipeline :)

Thanks,
Andrew

On 3/25/2015 8:24 PM, Chris Campbell wrote:
> Hi Andrew,
>
> That's a good find re: pow().  In the comment at lines 277-283 I 
> mentioned that there was only a scalar variant of pow().  I wonder if 
> that was a limitation in some early version of GLSL I was using or 
> perhaps some driver bug/restriction.  According to all the docs I can 
> find the vector variants have been there all along:
> https://www.opengl.org/sdk/docs/man4/index.php
>
> So now I'm wondering if the slowness was actually due to me trying 3 
> scalar pow() calls versus one vector pow() call.
>
> Oh, aha!  I think this explains part of it:
>
>  269  * This is the GLSL fragment shader source code for rendering 
> LCD-optimized
>  270  * text.  Do not be frightened; it is much easier to understand 
> than the
>  271  * equivalent ASM-like fragment program!
>
> Looks like I wrote the original version of this shader using the 
> GL_ARB_fragment_program language, which indeed only had a scalar POW 
> instruction (see section 3.11.5.20):
> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>
> And then I'm guessing that when I rewrote it in more modern GLSL, I 
> didn't notice that pow() supported vectors.  Sigh.  That 3D texture 
> LUT was a lot of work for a whole lot of nothing.
>
> In any case, you might want to rewrite the comment at lines 277-283 to 
> suit the new code.  Same goes for the comment at line 315:
>
>     // gamma adjust the dest color using the invgamma LUT
>
> Also, I noticed that the restrictions in 
> OGLContext_IsLCDShaderSupportAvailable() could be loosened since you 
> only need 2 texture units now.  Just in the extremely unlikely case 
> that anyone's running this stuff on ancient hardware :)
>
> Thanks,
> Chris
>
>
> Andrew Brygin wrote:
>> Hello Phil,
>>
>> could you please take a look to updated version of the fix?
>>
>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>
>> * OGLTextRenderer.c
>> It was discovered, that in some cases lcd glyphs had visible 'dark
>> border' around.
>> This border appeared due to the gamma correction in lcd shader, which
>> uses lookup
>> on 3D texture instead of using 'pow' routine. The texture is populated
>> with significant
>> granularity (16 points per edge), what is a root cause of rough
>> interpolation of color values.
>> Suggested change is to eliminate the interpolation and use 'pow' routine
>> directly.
>> It gives more accurate color values, and does not introduce significant
>> performance hit
>> (see benchmark summary below).
>> However, this part of the fix affects not only macosx, but any platform
>> where OGL text
>> shader can be used, so it probably worth to split into a separate fix.
>>
>> Summary:
>> lcd-ogl-3Dlookup:
>> Number of tests: 4
>> Overall average: 42.68027553311743
>> Best spread: 3.49% variance
>> Worst spread: 29.59% variance
>> (Basis for results comparison)
>>
>> lcd-ogl-pow:
>> Number of tests: 4
>> Overall average: 42.468941501367084
>> Best spread: 2.51% variance
>> Worst spread: 29.44% variance
>> Comparison to basis:
>> Best result: 103.28% of basis
>> Worst result: 97.36% of basis
>> Number of wins: 1
>> Number of ties: 2
>> Number of losses: 1
>>
>> Thanks,
>> Andrew
>>
>>



From alexandr.scherbatiy at oracle.com  Thu Mar 26 15:32:25 2015
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 26 Mar 2015 18:32:25 +0300
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
Message-ID: <55142689.2010900@oracle.com>

On 3/26/2015 3:49 PM, Hendrik Schreiber wrote:
> Hey there,
>
> I'm in the process of moving some custom code to take advantage of the fairly new MultiResolutionImage capabilities.
> Loading multi resolution stuff works nicely, but I fear drawing is a bit of a problem.
>
> In my old mechanism, I would
>
> - load images using the toolkit
> - create a screen-compatible BufferedImage via graphicsConfiguration.createCompatibleImage(...)
> - draw the image into said buffer
> - and then paint the screen-compatible buffer when needed (typically in some Icon implementation)
>
> The assumption here is that drawing the screen-compatible image is much faster than the toolkit image (which isn't necessarily screen-compatible, usually TYPE_INT_ARGB instead of TYPE_INT_ARGB_PRE).
>
> AFAIK, there are no published java.* APIs for MultiResolutionImages.
>
> So if I understand this correctly, there is currently no officially supported, high performance way to draw MultiResolutionImages.
>
> Therefore, in the spirit of https://bugs.openjdk.java.net/browse/JDK-8059943, I'd like to suggest, to either move sun.awt.image.MultiResolutionImage to some java.* package, so that one can write an implementation that is fast.
     There is an open discussion about it which you could join: 
http://mail.openjdk.java.net/pipermail/2d-dev/2015-March/005187.html
     JDK-8029339 Custom MultiResolution image support on HiDPI displays
         https://bugs.openjdk.java.net/browse/JDK-8029339

    Thanks,
     Alexandr.
> Or provide a standard way to ensure that Toolkit-loaded images are screen-compatible. Perhaps a little tweak in sun.awt.image.ImageRepresentation or the code that calls it is all that's needed (i.e. a change of the default ColorModel in ToolkitImage). Or is that not possible because of compatibility reasons?
>
> Does that sound reasonable? Am I missing something?
>
> Thanks,
>
> -hendrik



From hs at tagtraum.com  Thu Mar 26 16:15:59 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 26 Mar 2015 17:15:59 +0100
Subject: [OpenJDK 2D-Dev] <AWT Dev> Review request for 8029339 Custom
	MultiResolution image support on HiDPI displays
In-Reply-To: <5502E763.7080008@oracle.com>
References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com>
	<5502E763.7080008@oracle.com>
Message-ID: <48589035-5937-41EB-B4F4-F6E2741C52D8@tagtraum.com>


> On Mar 13, 2015, at 14:34, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
>  Could you review the proposed API based on MultiresolutionImage interface:
>    http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/

Not that it counts much, but to me the proposed API looks good in that it provides us with multiple ways to create custom MultiResolutionImages ourselves. Either via BaseMultiResolutionImage or by implementing the public MultiResolutionImage interface directly.

-hendrik

<slight-rant>
Personally, it irks me a little that we have an MRI, an AbstractMRI, and a BaseMRI (that's how you know it's Java code...). Fewer classes would be nice, but I guess one can't have it all. At least I don't have a great suggestion how to make this easy for developers while at the same time honoring DRY.
</slight-rant>



From hs at tagtraum.com  Thu Mar 26 16:21:27 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Thu, 26 Mar 2015 17:21:27 +0100
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
	screen compatible
In-Reply-To: <55142689.2010900@oracle.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
	<55142689.2010900@oracle.com>
Message-ID: <8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>


> On Mar 26, 2015, at 16:32, Alexander Scherbatiy <alexandr.scherbatiy at oracle.com> wrote:
> 
> On 3/26/2015 3:49 PM, Hendrik Schreiber wrote:
[...]

>> 
>> Therefore, in the spirit of https://bugs.openjdk.java.net/browse/JDK-8059943, I'd like to suggest, to either move sun.awt.image.MultiResolutionImage to some java.* package, so that one can write an implementation that is fast.
>    There is an open discussion about it which you could join: http://mail.openjdk.java.net/pipermail/2d-dev/2015-March/005187.html
>    JDK-8029339 Custom MultiResolution image support on HiDPI displays
>        https://bugs.openjdk.java.net/browse/JDK-8029339

Thanks for the pointer.

>> 
>> Or provide a standard way to ensure that Toolkit-loaded images are screen-compatible. Perhaps a little tweak in sun.awt.image.ImageRepresentation or the code that calls it is all that's needed (i.e. a change of the default ColorModel in ToolkitImage). Or is that not possible because of compatibility reasons?

Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all want that?
Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be more flexible?

Cheers,

-hendrik

From Alan.Bateman at oracle.com  Thu Mar 26 16:43:36 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 Mar 2015 16:43:36 +0000
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <55143390.7060208@oracle.com>
References: <54E7ABB8.7010901@oracle.com>
	<54E7B587.70904@oracle.com>	<54E8499F.7060706@oracle.com>
	<55074BDE.1050602@oracle.com>	<550B14BF.3040209@oracle.com>
	<550B91D3.6000406@oracle.com> <550C9375.8070404@oracle.com>
	<55133B36.5040109@oracle.com> <5513BF28.30002@oracle.com>
	<55143390.7060208@oracle.com>
Message-ID: <55143738.9080507@oracle.com>

On 26/03/2015 16:28, Xueming Shen wrote:
>
> An alternative is to simply grip the names and build a small internal 
> mapping for those used
> by the fonts, it's a limited/small/fixed list, I assume. That might be 
> look better than the current
> hacky one.
So a small name -> historical name map? If that is possible then it 
would be cleaner.

-Alan


From xueming.shen at oracle.com  Thu Mar 26 16:28:00 2015
From: xueming.shen at oracle.com (Xueming Shen)
Date: Thu, 26 Mar 2015 09:28:00 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <5513BF28.30002@oracle.com>
References: <54E7ABB8.7010901@oracle.com>
	<54E7B587.70904@oracle.com>	<54E8499F.7060706@oracle.com>
	<55074BDE.1050602@oracle.com>	<550B14BF.3040209@oracle.com>
	<550B91D3.6000406@oracle.com> <550C9375.8070404@oracle.com>
	<55133B36.5040109@oracle.com> <5513BF28.30002@oracle.com>
Message-ID: <55143390.7060208@oracle.com>

On 3/26/15 1:11 AM, Alan Bateman wrote:
> On 25/03/2015 22:48, Phil Race wrote:
>> Updated webrev http://cr.openjdk.java.net/~prr/8035302.2/
>>
>> - removed the jdk.charsets export to java.desktop from modules.xml
>>
>> - removed the COMPOUND_TEXT support which likely has not been used 
>> since Motif support was removed
> This looks good to me. The code in FontDescriptor to get the 
> historical name is indeed odd, I don't know if Sherman has any other 
> suggestions for this.
>
> Is there anything that can be salvaged from the tests? That is, are 
> there are existing fonts tests that will exercise these charsets like 
> the old tests in sun/nio/cs ?
>
> -Alan
>
>

An alternative is to simply grip the names and build a small internal 
mapping for those used
by the fonts, it's a limited/small/fixed list, I assume. That might be 
look better than the current
hacky one.

-sherman


From james.graham at oracle.com  Thu Mar 26 21:48:46 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 26 Mar 2015 14:48:46 -0700
Subject: [OpenJDK 2D-Dev] Review request for 8029339 Custom
 MultiResolution image support on HiDPI displays
In-Reply-To: <5502E763.7080008@oracle.com>
References: <54C10E06.6090407@oracle.com> <54DE956C.9040105@oracle.com>
	<5502E763.7080008@oracle.com>
Message-ID: <55147EBE.3010002@oracle.com>

Hi Alexander,

MRI.java:

Who is the intended audience for the recommendation in the interface to 
cache image variants?  Are we asking the developers who call the methods 
on the interface to cache the answers?  That would be unwise because the 
list of variants may change over time for some MRIs.  Are we speaking to 
the implementer?  If so, then I think that it is unnecessary to remind 
implementers of basic implementation strategies like "cache complicated 
objects".

How about this wording for the getRV() method? - "Gets a specific image 
that is the best variant to represent this logical image at the 
indicated size and screen resolution."

Perhaps we should clarify in the doc comments for the dimension 
arguments in getRV() that the dimensions are measured in pixels?

line 56 - delete blank line between doc comment and method declaration

Also, it is probably overkill to document that the interface 
getVariants() method returns an unmodifiable list.  Responsible 
implementations would probably use an unmodifiable list, but I don't 
think it should be required by the interface.  We do need to specify 
that it isn't required to be modifiable so that a caller doesn't expect 
to be able to modify it, but that is a looser spec.  How about "Gets a 
readable list of all resolution variants.  Note that many 
implementations might return an unmodifiable list."?

AbstractMIR.java:

"provides a default implementation for the MRI" or "provides default 
implementations of several methods in the <MRI> interface and the 
<Image> class"?  Actually, I'll note that it provides none of the 
implementations of the MRI methods so maybe it should be "provides 
default implementations of several <Image> methods for classes that want 
to implement the <MRI> interface"?

In the doc example - wrap the list to make it unmodifiable

The doc example could be made 2 or 3 lines shorter by simply assuming 
the base image is in index 0 (it's just an example so I'm not sure the 
flexibility needs to be a part of the example).

getGraphics is allowed by the Image interface to return null.  Actually, 
the exact wording is that it can only be called for "offscreen images" 
and a MRI is technically not "an offscreen image".  Perhaps we should 
return null here since modifying the base image is unlikely to modify 
the variants and arguably it would be required by the wording in the 
method docs (even if the base image was an offscreen, the MRI produced 
from it stops being an offscreen)?

Are all of the empty "@Inherit" comments needed?  I thought inheritance 
was the default?

BaseMRI.java:

"This class is [an] array-based implementation of the {AMRI} class" 
(missing "an" and "the")

We should probably include the comment about the sorting of the images 
in the class comments as well as document that the algorithm is a simple 
scan from the beginning for the first image large enough (and default == 
last image).  The algorithm also might not work very well if the images 
are not monotonically both wider and taller.  How about adding this to 
the class comments:

"The implementation will return the first image variant in the array 
that is large enough to satisfy the rendering request.  For best effect 
the array of images should be sorted with each image being both wider 
and taller than the previous image.  The base image need not be the 
first image in the array."

getVariants() - you need to return an unmodifiable list.  asList() 
returns a list that "writes back" to the array.  You need to use 
Collections.unmodifiableList(Arrays.asList(array)).

RenderingHints.java:

Where do we process this hint?  Don't we need to pass it to the 
getVariant() method?

I don't understand the hint values other than the one that always uses 
the base image.  Default I guess gives us the ability to use the Mac 
algorithm of "next larger size" on Mac and "based on Screen DPI" on 
Windows, but the 3rd value "ON" is so vague as to not have any meaning. 
  Perhaps we should just delete it, but then do we just always do the 
Mac method?  Or do we vaguely have our internal images have a 
platform-specific method and the Abstract/Base classes just do what they 
want with no control from the user?  In FX we are also still struggling 
with this issue and we may likely just do what the Mac does in all 
cases, but perhaps AWT needs to "behave like the platform" more?  If we 
are going to have actual values, then we need to have them do something, 
which means:

- SG2D needs to track the hint just like we do the other hints that 
affect our processing
- MRI.getVariant() needs to have the hint as an argument
- BaseMRI should probably do something with that hint
- hint values should include:
     - ..._DEFAULT - implementation gets to decide
     - ..._BASE - always use the base image
     - ..._SIZE_FIT - Mac algorithm of smallest image that is big enough
     - ..._DPI_FIT - choose based on DPI of the screen, ignoring transform

line 978 - missing blank line between fields

SG2D.java:

- The interface says that you will be passing in the "logical DPI" of 
the display, but here you are actually passing in the screen's scale factor.

BaseMRITest.java:

- testBaseMRI also passes in a scale rather than a DPI to the MRI method.

- How does the modification test pass when the implementation doesn't 
use unmodifiable lists?

MRITest.java:

- also uses scale rather than DPI in several places

		...jim

On 3/13/15 6:34 AM, Alexander Scherbatiy wrote:
>
>    Hello,
>
>    Could you review the proposed API based on MultiresolutionImage
> interface:
>      http://cr.openjdk.java.net/~alexsch/8029339/webrev.06/
>
>   - return unmodifiable list comment is added to the
> getResolutionVariants() method javadoc in MultiresolutionImage interface
>   - base image size arguments are removed form the
> getResolutionVariant(...) method in MultiresolutionImage interface
>   - BaseMultiResolutionImage class that allows to create a
> multi-resolution image based on resolution variant array is added
>   - the test for the BaseMultiResolutionImage is added
>
>   Thanks,
>   Alexandr.
>
> On 2/14/2015 3:23 AM, Jim Graham wrote:
>> The second solution looks good.  I'd make it standard practice
>> (perhaps even mentioned in the documentation) to return unmodifiable
>> lists from the getVariants() method.  The Collections class provides
>> easy methods to create these lists, and it sends a clear message to
>> the caller that the list was provided for them to read, but not write
>> to.  Otherwise they may add a new image to the list you provided them
>> and wonder why it wasn't showing up.  Also, an unmodifiable list can
>> be cached and reused for subsequent calls without having to create a
>> new list every time.
>>
>> In getResolutionVariant() was there a reason why the base dimensions
>> were provided as float?  The destination dimensions make sense as
>> float since they could be the result of a scale, but the source
>> dimensions are typically getWidth/getHeight() on the base image.  A
>> related question would be if they are needed at all, since the
>> implementation should probably already be aware of what the base image
>> is and what its dimensions are.  I'm guessing they are provided
>> because the implementation in SG2D already knows them and it makes it
>> easier to forward the implementation on to a shared (static?) method?
>>
>> With respect to default implementations, I take it that the BaseMRI is
>> along the pattern that we see in Swing for Base classes.  Would it be
>> helpful to provide an implementation (in addition or instead) that
>> allows a developer to take a bunch of images and quickly make an MRI
>> without having to override anything?  The implementations of
>> getBaseImage() and getResolutionVariants() are pretty straightforward
>> and a fairly reasonable default algorithm can be provided for
>> getRV(dimensions).  This question is more of an idle question for my
>> own curiosity than a stumbling block...
>>
>>             ...jim
>>
>> On 1/22/2015 6:49 AM, Alexander Scherbatiy wrote:
>>>
>>>    Hi Phil,
>>>
>>>    I have prepared two versions of the proposed API:
>>>
>>>    I) Resolution variants are added directly to the Image:
>>>     http://cr.openjdk.java.net/~alexsch/8029339/list/webrev.00
>>>
>>>    II)  MultiResolutionImage interface is used:
>>>      http://cr.openjdk.java.net/~alexsch/8029339/webrev.05
>>>
>>>    It could help to decide which way should be chosen for the the
>>> multi-resolution image support.
>>>
>>>    Below are some comments:
>>>
>>>    1. High level goal:
>>>       Introduce an API that allows to create and handle an image with
>>> resolution variants.
>>>
>>>    2. What is not subject of the provided API
>>>      - Scale naming convention for high-resolution images
>>>      - Providing pixel scale factor for the screen/window
>>>
>>>    3. Use cases
>>>     3.1 Loading and drawing high-resolution icons in IntelliJ IDEA
>>>       A high-resolution image is loaded from resources and stored in
>>> JBHiDPIScaledImage class  which is a subclass of the buffered image.
>>>       The high-resolution image is used to create a disabled icon in the
>>> IconLoader.getDisabledIcon(icon) method.
>>> https://github.com/JetBrains/intellij-community/blob/master/platform/util/src/com/intellij/openapi/util/IconLoader.java
>>>
>>>
>>>
>>>     3.2 Loading and drawing high-resolution icons in NetBeans
>>>       NetBeans does not have support for the high-resolution icons
>>> loading.
>>>       It loads an icon from the file system using
>>> Toolkit.getDefaultToolkit().getImage(url) method or from resources
>>>       by  ImageReader  and store it in ToolTipImage class which is
>>> subclass of the buffered image.
>>>       ImageUtilities.createDisabledIcon(icon) method creates a disabled
>>> icon by applying  RGBImageFilter to the icon.
>>> http://hg.netbeans.org/main/file/97dcf49eb4a7/openide.util/src/org/openide/util/ImageUtilities.java
>>>
>>>
>>>
>>>     3.3 Loading system icons in JDK 1.8
>>>       JDK requests icons from the native system for system L&Fs and
>>> applies filters for them.
>>>       See for example AquaUtils.generateLightenedImage() method:
>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/e6f48c4fad38/src/java.desktop/macosx/classes/com/apple/laf/AquaUtils.java
>>>
>>>
>>>
>>>    4. HiDPI support for Images on different OSes
>>>
>>>      4.1 Mac OS X
>>>        Cocoa API contains NSImage that allows to work with image
>>> representations: add/remove/get all representations.
>>>        It picks up an image with necessary resolution based on the
>>> screen backing store pixel scale factor and applied transforms.
>>> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/Reference/Reference.html
>>>
>>>
>>>
>>>      4.2 Linux
>>>        GTK+ 3 API has gtkcssimagescaled lib (it seems that it is not
>>> public/stable)
>>>        that parses the -gtk-scaled css property and draws a GtkCssImage
>>> according to the given scale factor.
>>>
>>>        I have not found information about the HiDPI support in Xlib.
>>>
>>>      4.3 Windows
>>>        I have only found the tutorial that suggests to select and draw a
>>> bitmap using the queried DPI
>>>        and scale the coordinates for drawing a rectangular frame
>>> http://msdn.microsoft.com/en-us/library/dd464659%28v=vs.85%29.aspx
>>>
>>>        Windows also provides the horizontal and vertical DPI of the
>>> desktop
>>> http://msdn.microsoft.com/en-us/library/windows/apps/dd371316
>>>
>>>    5. Pseudo API
>>>       Below are some ways which illustrates how multi-resolution images
>>> can be created and used.
>>>
>>>      5.1 Resolution variants are stored directly in Image class.
>>>      To query a resolution variant it needs to compare the resolution
>>> variant width/height
>>>      with the requested high-resolution size.
>>>      ------------
>>>      public abstract class Image {
>>>
>>>          public void addResolutionVariant(Image image) {...}
>>>          public List<Image> getResolutionVariants() {...}
>>>      }
>>>      ------------
>>>      // create a disabled image with resolution variants
>>>
>>>      Image disabledImage = getDisabledImage(image);
>>>
>>>      for (Image rv : image.getResolutionVariants()) {
>>> disabledImage.addResolutionVariant(getDisabledImage(rv));
>>>      }
>>>      ------------
>>>      This approach requires that all resolution variants have been
>>> created even not of them are really used.
>>>
>>>      5.2  Resolution variants are stored in a separate object that
>>> allows to create them by demand.
>>>      To query a resolution variant it needs to compare the resolution
>>> variant scale factor
>>>      with the requested scale (that can include both screen DPI scale
>>> and applied transforms).
>>>      ------------
>>>      public abstract class Image {
>>>
>>>          public static interface ResolutionVariant {
>>>              Image getImage();
>>>              float getScaleFactor();
>>>          }
>>>
>>>          public void addResolutionVariant(ResolutionVariant
>>> resolutionVariant) {...}
>>>          public List<ResolutionVariant> getResolutionVariants() {...}
>>>      }
>>>      ------------
>>>      // create a disabled image with resolution variants
>>>      Image disabledImage = getDisabledImage(image);
>>>
>>>      for (Image.ResolutionVariant rv : image.getResolutionVariants()) {
>>>          disabledImage.addResolutionVariant(new
>>> Image.ResolutionVariant() {
>>>
>>>              public Image getImage() {
>>>                  return getDisabledImage(rv.getImage());
>>>              }
>>>
>>>              public float getScaleFactor() {
>>>                  return rv.getScaleFactor();
>>>              }
>>>          });
>>>      }
>>>      ------------
>>>
>>>      It does not have problem if a predefined set of images is provided
>>> (like image.png and image at 2x.png on the file system).
>>>      This does not cover cases where a resolution variant can be created
>>> using the exact requested size (like loading icons from the native
>>> system).
>>>      A resolution variant can be queried based on a scale factor and
>>> applied transforms.
>>>
>>>      5.3 The provided example allows to create a resolution variant
>>> using the requested high-resolution image size.
>>>      ------------
>>>      public interface MultiResolutionImage {
>>>          Image getResolutionVariant(float width, float height);
>>>      }
>>>      ------------
>>>      // create a multi-resolution image
>>>      Image mrImage = new AbstractMultiResolutionImage() {
>>>
>>>              public Image getResolutionVariant(float width, float
>>> height) {
>>>                  // create and return a resolution variant with exact
>>> requested width/height size
>>>              }
>>>
>>>              protected Image getBaseImage() {
>>>                  return baseImage;
>>>              }
>>>          };
>>>      ------------
>>>      // create a disabled image with resolution variants
>>>      Image disabledImage = null;
>>>      if (image instanceof MultiResolutionImage) {
>>>          final MultiResolutionImage mrImage = (MultiResolutionImage)
>>> image;
>>>          disabledImage = new AbstractMultiResolutionImage(){
>>>
>>>              public Image getResolutionVariant(float width, float
>>> height) {
>>>                  return
>>> getDisabledImage(mrImage.getResolutionVariant(width, height));
>>>              }
>>>
>>>              protected Image getBaseImage() {
>>>                  return getDisabledImage(mrImage);
>>>              }
>>>          };
>>>      } else {
>>>          disabledImage = getDisabledImage(image);
>>>      }
>>>      ------------
>>>
>>>    Thanks,
>>>    Alexandr.
>


From james.graham at oracle.com  Thu Mar 26 21:52:01 2015
From: james.graham at oracle.com (Jim Graham)
Date: Thu, 26 Mar 2015 14:52:01 -0700
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
	<55142689.2010900@oracle.com>
	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>
Message-ID: <55147F81.2020707@oracle.com>



On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
> Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all want that?
> Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be more flexible?

Toolkit images manage their own internal storage formats.  We shouldn't 
be requiring applications to adapt them for a display.  If we are 
managing the internal formats wrong then that is a bug to be fixed, not 
a reason for a new API or a new mechanism...

			...jim


From hs at tagtraum.com  Fri Mar 27 10:48:43 2015
From: hs at tagtraum.com (Hendrik Schreiber)
Date: Fri, 27 Mar 2015 11:48:43 +0100
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
	screen compatible
In-Reply-To: <55147F81.2020707@oracle.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
	<55142689.2010900@oracle.com>
	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>
	<55147F81.2020707@oracle.com>
Message-ID: <7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>


> On Mar 26, 2015, at 22:52, Jim Graham <james.graham at oracle.com> wrote:
> On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
>> Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all want that?
>> Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be more flexible?
> 
> Toolkit images manage their own internal storage formats.  We shouldn't be requiring applications to adapt them for a display.  If we are managing the internal formats wrong then that is a bug to be fixed, not a reason for a new API or a new mechanism...

Agreed and thanks for the comment.

I dug a little deeper to get a better understanding of what's going on.

As Jim pointed out, the ToolKit uses ImageDecoders to decode formats like Gif, PNG, Jpeg, XBM.
To this issue the only one that's really relevant is PNG, as it supports a full alpha channel (not sure about XBM).

Looking at the PNGImageDecoder's code, it uses ColorModel.getRGBdefault() as its color model with isAlphaPreMultiplied() == false for RGB, RGBA and GrayscaleA.

If my understanding of the current drawing pipeline is correct, RGBA without premultiplication is slow as premultiplication is done on-the-fly when drawing?at least for OS X and OpenGL, as pointed out in https://bugs.openjdk.java.net/browse/JDK-8059943

So to me it would make sense, if we changed the PNGImageDecoder's code so that for RGBA and GrayscaleA we use the premultiplied ColorModel. I believe the necessary code changes would be small. E.g. in PNGImageDecoder.produceImage():

case COLOR|ALPHA|(8<<3):
    wPixels[col+rowOffset] =
         ((rowByteBuffer[spos  ]&0xFF)<<16)
       | ((rowByteBuffer[spos+1]&0xFF)<< 8)
       | ((rowByteBuffer[spos+2]&0xFF)    )
       | ((rowByteBuffer[spos+3]&0xFF)<<24);
    spos+=4;
    break;

would change into something like this:

case COLOR|ALPHA|(8<<3):
    final int alpha = rowByteBuffer[spos+3]&0xFF
    wPixels[col+rowOffset] =
         (((rowByteBuffer[spos  ]&0xFF)*alpha/0xFF)<<16)
       | (((rowByteBuffer[spos+1]&0xFF)*alpha/0xFF)<< 8)
       | (((rowByteBuffer[spos+2]&0xFF)*alpha/0xFF)    )
       | alpha<<24;
    spos+=4;
    break;

Of course the color model would also need to be set to a different value (isAlphaPreMultiplied() == true).

Assuming that most folks use PNGs with transparency for their buttons and other UI graphics, this should make drawing of those items faster. And when it comes to MultiResolutionImages, one could use the ones produced by the Toolkit and wouldn't have to create premultiplied version manually somehow (which is what sparked my interest in this).

What is beyond me is the question, whether premultiplying has any disadvantages. I am aware of none, but that does not mean a lot.

Cheers,

-hendrik

From andrew.brygin at oracle.com  Fri Mar 27 14:50:25 2015
From: andrew.brygin at oracle.com (Andrew Brygin)
Date: Fri, 27 Mar 2015 17:50:25 +0300
Subject: [OpenJDK 2D-Dev] [9] Review request for 8023794: [macosx] LCD
 Rendering hints seems not working without FRACTIONALMETRICS=ON
In-Reply-To: <5514029A.1090101@oracle.com>
References: <CA+3bSS-SWXEzmcCDttDb8Odp_sozPxv_A0k4zAZvPQ+uU4Ka=A@mail.gmail.com>	<53BD5E45.4000805@oracle.com>	<9A5D5D1C-F58F-4DFC-B327-9A9DB18B155E@gmail.com>	<54297B00.5020604@oracle.com>	<6B49FF00-8A8F-41DF-A574-B9537C1A2B94@gmail.com>	<5437EE69.3090606@oracle.com>	<54380F42.7060705@oracle.com>	<54381FFC.5000507@oracle.com>	<5438465D.5070503@oracle.com>	<54384C03.5020006@oracle.com>	<543ADF1B.9020802@oracle.com>	<543BC85F.8050202@oracle.com>	<543C62AC.2010907@oracle.com>	<544A92CC.10406@oracle.com>	<544AB09D.5060805@oracle.com>
	<548B21D2.8080701@oracle.com>	<5512CB71.30908@oracle.com>
	<5512EF51.7070907@plausible.coop> <5514029A.1090101@oracle.com>
Message-ID: <55156E31.7080803@oracle.com>

There is a minor update in the fix: it does not worth to blend 
black-on-white
and white-on-black glyphs for the case of AA glyphs, because it makes no 
difference.
CGGlyphImages.m, lines 294 - 325, 755 - 763, and 787 - 794:

http://cr.openjdk.java.net/~bae/8023794/9/webrev.08

I have also modified the AntialiasDemo a bit in order to render the
sample text in different colors, and in order to render into a volatile
image as well:
http://cr.openjdk.java.net/~bae/8023794/demo/AntialiasDemo.java

It could be used to assess the change in glyph generation.

Thanks,
Andrew

On 3/26/2015 3:59 PM, Andrew Brygin wrote:
> Hi Chris,
>
>  thank you for the comments and explanation. I have updated the 
> OGLContext_IsLCDShaderSupportAvailable()
>  and comments in OGLTextRenderer.c accordingly:
>
> http://cr.openjdk.java.net/~bae/8023794/9/webrev.07/
>
>  Good to know that you keep an eye on the OGL pipeline :)
>
> Thanks,
> Andrew
>
> On 3/25/2015 8:24 PM, Chris Campbell wrote:
>> Hi Andrew,
>>
>> That's a good find re: pow().  In the comment at lines 277-283 I 
>> mentioned that there was only a scalar variant of pow().  I wonder if 
>> that was a limitation in some early version of GLSL I was using or 
>> perhaps some driver bug/restriction.  According to all the docs I can 
>> find the vector variants have been there all along:
>> https://www.opengl.org/sdk/docs/man4/index.php
>>
>> So now I'm wondering if the slowness was actually due to me trying 3 
>> scalar pow() calls versus one vector pow() call.
>>
>> Oh, aha!  I think this explains part of it:
>>
>>  269  * This is the GLSL fragment shader source code for rendering 
>> LCD-optimized
>>  270  * text.  Do not be frightened; it is much easier to understand 
>> than the
>>  271  * equivalent ASM-like fragment program!
>>
>> Looks like I wrote the original version of this shader using the 
>> GL_ARB_fragment_program language, which indeed only had a scalar POW 
>> instruction (see section 3.11.5.20):
>> https://www.opengl.org/registry/specs/ARB/fragment_program.txt
>>
>> And then I'm guessing that when I rewrote it in more modern GLSL, I 
>> didn't notice that pow() supported vectors.  Sigh.  That 3D texture 
>> LUT was a lot of work for a whole lot of nothing.
>>
>> In any case, you might want to rewrite the comment at lines 277-283 
>> to suit the new code.  Same goes for the comment at line 315:
>>
>>     // gamma adjust the dest color using the invgamma LUT
>>
>> Also, I noticed that the restrictions in 
>> OGLContext_IsLCDShaderSupportAvailable() could be loosened since you 
>> only need 2 texture units now.  Just in the extremely unlikely case 
>> that anyone's running this stuff on ancient hardware :)
>>
>> Thanks,
>> Chris
>>
>>
>> Andrew Brygin wrote:
>>> Hello Phil,
>>>
>>> could you please take a look to updated version of the fix?
>>>
>>> http://cr.openjdk.java.net/~bae/8023794/9/webrev.06/
>>>
>>> * OGLTextRenderer.c
>>> It was discovered, that in some cases lcd glyphs had visible 'dark
>>> border' around.
>>> This border appeared due to the gamma correction in lcd shader, which
>>> uses lookup
>>> on 3D texture instead of using 'pow' routine. The texture is populated
>>> with significant
>>> granularity (16 points per edge), what is a root cause of rough
>>> interpolation of color values.
>>> Suggested change is to eliminate the interpolation and use 'pow' 
>>> routine
>>> directly.
>>> It gives more accurate color values, and does not introduce significant
>>> performance hit
>>> (see benchmark summary below).
>>> However, this part of the fix affects not only macosx, but any platform
>>> where OGL text
>>> shader can be used, so it probably worth to split into a separate fix.
>>>
>>> Summary:
>>> lcd-ogl-3Dlookup:
>>> Number of tests: 4
>>> Overall average: 42.68027553311743
>>> Best spread: 3.49% variance
>>> Worst spread: 29.59% variance
>>> (Basis for results comparison)
>>>
>>> lcd-ogl-pow:
>>> Number of tests: 4
>>> Overall average: 42.468941501367084
>>> Best spread: 2.51% variance
>>> Worst spread: 29.44% variance
>>> Comparison to basis:
>>> Best result: 103.28% of basis
>>> Worst result: 97.36% of basis
>>> Number of wins: 1
>>> Number of ties: 2
>>> Number of losses: 1
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>



From bourges.laurent at gmail.com  Fri Mar 27 16:33:40 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Fri, 27 Mar 2015 17:33:40 +0100
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <54FA57B8.60201@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54DF8F7F.5040700@redhat.com>
	<CAGUMyaTC+DFkHvAb7with3372kvU9wJzQGrLgxSCEjDeqxhSQA@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
Message-ID: <CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>

Jim,

Here is a new Path2d patch:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D.2/

Changes:
- Fix ArrayIndexOutOfBounds in ptCrossing / rectCrossing when coords array
is zero-sized (0 capacity constructor): bug present in jdk8
- new tests:
Path2dEmpty to test this bug
Path2dCopyConstructor to test my changes on the copy constructor following
your instructions

Maybe we should create a new bug and split this patch in 2 separated ones ?

Laurent

Le 7 mars 2015 02:43, "Jim Graham" <james.graham at oracle.com> a ?crit :
>
> First, the test cases that I asked for were to verify that a path that
was cloned was still operational.  I see no tests that verify that the
returned objects will still function, only tests that examine internal data
structures for a metric that may not be appropriate in the future.
>
> On 3/6/15 11:06 AM, Phil Race wrote:
>>
>> So the test should go in the anonymous package and avoid accessing
>> internals.
>> It should be possible to use just public API  to verify the arrays  of a
>> shape
>> being cloned are trimmed .
>
>
> We should not be testing if the cloned arrays are trimmed.  We don't care
from a testing standpoint.  It is an implementation detail of a performance
feature and we should not write any test that says "Object A should do its
work by doing X, Y, and Z".
>
> If we want to test performance then we should write a benchmark that
tests how long it takes to do an operation.  That will likely be a manual
test, though.  It should not be examining internals to take its
measurements, though.  Benchmarks tend to only use public APIs as they
should be benchmarking operations that Java programs encounter.
>
> If we want to test if your fix will break something, then we need to test
that.  Currently your tests do not do that.  We only need public APIs to do
that.
>
> What I would like to see in the test:
>
> - Delete all of the existing tests in there.  None of them are
appropriate to our testing goals.
>
> - Write tests that create paths in various forms and run them through the
following sub-tests:
>      - each of the following should be tested on a fresh clone...
>      - get a PathIterator and iterate it through until it is done
>        (optional - compare to the expected segments that were in the
original)
>      - get a flattened PathIterator using "getPathIterator(flatness,)"
and make sure it works
>        (optional - compare to original path if the original was already
flat)
>        (but, also run it on a path with curves to make sure flattening
engine didn't break)
>      - add various kinds of segments to the cloned path
>      - get the bounds of the cloned path
>      - use the transform() method on the cloned path
>      - call intersects(point), intersects(rect) and contains(rect) on a
cloned path
>      - call getCurrentPoint() on the cloned path
>
> - Perform each of the above tests on a (set of) clone(s) of the following
paths:
>      - each of the following executed on both a Float and a Double
instance...
>      - an empty path
>      - a path with just a moveto
>      - a path with a moveto+some lines
>      - a path with a moveto+some curves
>
> The way I tend to write tests like this is to use cascading methods like:
>
> void testEqual(Path2D pathA, Path2D path2D pathB) {
>     // Grab 2 path iterators and test for equality with float coords[]
> }
>
> void test(Path2D p2d, boolean isEmpty) {
>     testEqual(new Path2D.Float(p2d), p2d);
>     testEqual(new Path2D.Double(p2d), p2d);
>     testEqual(new GeneralPath(p2d), p2d);
>
>     testIterator(new Path2D.Float(p2d));
>     testIterator(new Path2D.Double(p2d));
>     testIterator((Path2D) p2d.clone());
>
>     testFlattening(... 3 clone variants ...);
>
>     testAddMove(... 3 clone variants ...);
>     // These should expect exception if empty
>     testAddLine(... 3 clone variants ..., isEmpty);
>     testAddQuad(... 3 clone variants ..., isEmpty);
> }
>
> interface PathFactory {
>     Path2D makePath();
> }
>
> void test(PathFactory pf) {
>     test(pf.makePath(), true);
>     test(addMove(pf.makePath()), false);
>     test(addLines(pf.makePath()), false);
>     test(addCurves(pf.makePath())), false);
> }
>
> @Test
> void testFloatPaths() {
>     test(() -> new Path2D.Float());
> }
>
> @Test
> void testDoublePaths() {
>     test(() -> new Path2D.Double());
> }
>
> @Test
> void testGeneralPath() {
>     test(() -> new GeneralPath());
> }
>
>                         ...jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150327/9b8612ec/attachment.html>

From james.graham at oracle.com  Fri Mar 27 21:39:04 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 27 Mar 2015 14:39:04 -0700
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
	<55142689.2010900@oracle.com>
	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>
	<55147F81.2020707@oracle.com>
	<7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
Message-ID: <5515CDF8.3060504@oracle.com>

Hi Hendrik,

You also need to look at the texture caching that goes on.  Decoders 
bring the image into a RAM representation and that can sometimes be used 
directly and so it's format might matter, but we typically upload image 
data into textures in VRAM and it is that format which is critical for 
typical performance.  The format of the RAM data mainly relates to how 
expensive it is to upload the data to VRAM in most cases.

Also, the RAM data produced by the Decoders may also be used to feed 
ImageConsumer objects which may be written to operate optimally on data 
in the "default RGB format" which is ARGB_nonPRE.  If we suddenly 
started producing and supplying PRE data to those objects many of them 
may have to punt to method calls on the ColorModel to do their work 
(hopefully they do check the incoming ColorModel so that they would at 
least notice the difference)...

			...jim

On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
>
>> On Mar 26, 2015, at 22:52, Jim Graham <james.graham at oracle.com> wrote:
>> On 3/26/15 9:21 AM, Hendrik Schreiber wrote:
>>> Nevertheless, I wouldn't mind some feedback regarding converting ToolKitImages easily to something that can be drawn faster (TYPE_INT_ARGB_PRE). Don't we all want that?
>>> Or asked the other way around: Why isn't TYPE_INT_ARGB_PRE the default? To be more flexible?
>>
>> Toolkit images manage their own internal storage formats.  We shouldn't be requiring applications to adapt them for a display.  If we are managing the internal formats wrong then that is a bug to be fixed, not a reason for a new API or a new mechanism...
>
> Agreed and thanks for the comment.
>
> I dug a little deeper to get a better understanding of what's going on.
>
> As Jim pointed out, the ToolKit uses ImageDecoders to decode formats like Gif, PNG, Jpeg, XBM.
> To this issue the only one that's really relevant is PNG, as it supports a full alpha channel (not sure about XBM).
>
> Looking at the PNGImageDecoder's code, it uses ColorModel.getRGBdefault() as its color model with isAlphaPreMultiplied() == false for RGB, RGBA and GrayscaleA.
>
> If my understanding of the current drawing pipeline is correct, RGBA without premultiplication is slow as premultiplication is done on-the-fly when drawing?at least for OS X and OpenGL, as pointed out in https://bugs.openjdk.java.net/browse/JDK-8059943
>
> So to me it would make sense, if we changed the PNGImageDecoder's code so that for RGBA and GrayscaleA we use the premultiplied ColorModel. I believe the necessary code changes would be small. E.g. in PNGImageDecoder.produceImage():
>
> case COLOR|ALPHA|(8<<3):
>      wPixels[col+rowOffset] =
>           ((rowByteBuffer[spos  ]&0xFF)<<16)
>         | ((rowByteBuffer[spos+1]&0xFF)<< 8)
>         | ((rowByteBuffer[spos+2]&0xFF)    )
>         | ((rowByteBuffer[spos+3]&0xFF)<<24);
>      spos+=4;
>      break;
>
> would change into something like this:
>
> case COLOR|ALPHA|(8<<3):
>      final int alpha = rowByteBuffer[spos+3]&0xFF
>      wPixels[col+rowOffset] =
>           (((rowByteBuffer[spos  ]&0xFF)*alpha/0xFF)<<16)
>         | (((rowByteBuffer[spos+1]&0xFF)*alpha/0xFF)<< 8)
>         | (((rowByteBuffer[spos+2]&0xFF)*alpha/0xFF)    )
>         | alpha<<24;
>      spos+=4;
>      break;
>
> Of course the color model would also need to be set to a different value (isAlphaPreMultiplied() == true).
>
> Assuming that most folks use PNGs with transparency for their buttons and other UI graphics, this should make drawing of those items faster. And when it comes to MultiResolutionImages, one could use the ones produced by the Toolkit and wouldn't have to create premultiplied version manually somehow (which is what sparked my interest in this).
>
> What is beyond me is the question, whether premultiplying has any disadvantages. I am aware of none, but that does not mean a lot.
>
> Cheers,
>
> -hendrik
>


From james.graham at oracle.com  Fri Mar 27 21:50:17 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 27 Mar 2015 14:50:17 -0700
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>
	<55142689.2010900@oracle.com>
	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>
	<55147F81.2020707@oracle.com>
	<7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
Message-ID: <5515D099.9020808@oracle.com>

On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
> If my understanding of the current drawing pipeline is correct, RGBA without premultiplication is slow as premultiplication is done on-the-fly when drawing?at least for OS X and OpenGL, as pointed out in https://bugs.openjdk.java.net/browse/JDK-8059943

That's an odd bug.  I'll note that it points out that we had missing 
loops in the OpenGL pipeline to directly deal with the non-PRE data and 
it links to a bug that adds those loops for more direct handling.  It's 
also not clear why those BufferedImage objects weren't cached.  If you 
create a BI and render to it and then blit from it a bunch of times it 
should be cached in VRAM and the format shouldn't matter, but if you are 
constantly rendering to the BI, then our cache never has time to set up 
- and if you grab the data buffer for that BI, then it will never be 
cached.  But the buffers we use in the ImageRepresentations should be 
static and should be cached.

I'm not saying that I have all of the answers as to whether or not 
changing the PNG decoder to use PRE buffers would help, I'm just trying 
to delineate all of the considerations that affect whether this is a 
practical issue or not.  We'd need test cases to test if any of the 
mechanisms I'm describing are doing their job or not...

			...jim


From james.graham at oracle.com  Fri Mar 27 22:38:31 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 27 Mar 2015 15:38:31 -0700
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
Message-ID: <5515DBE7.9000207@oracle.com>

Hi Laurent,

Looks great.  Some comments on the test:

- A couple of methods have "/**" even though the comment is just 
informational to the programmer and not representing an API.  It looks 
like "/**" is the standard practice for the @test comment at the top of 
the class even though jtreg isn't spec'd to require it, but elsewhere 
it's just noise.

- In general tests shouldn't print out a lot of noise (see "verbosity" 
in http://openjdk.java.net/jtreg/writetests.html).  Ideally an automated 
test would produce no output if it is successful, but some of our 
automated tests do print out a short summary (mostly if they were 
stress-bashers).  Some of them can be run in "verbose mode" to print out 
details in case an engineer is diagnosing a failure and wants to know 
what failed and why - I saw a few in the AffineTransform directory that 
had a static boolean verbose that was set if there was an argument 
handed to main() for instance.  A verbose option can help when running 
the test in manual mode for debugging.

- I'd add a testAddCubic() and testAddClose() to the tests.  It looks 
like the "testAddQuad" method does add both types of curve, but the 
cubic curve is added after the quad so we don't get a case that adds a 
cubic to a freshly cloned path - which is the main state in question to 
be tested here.

- equalsArray has some tests in it that don't make a lot of sense since 
you created the arrays and so you know that they aren't == or null or 
the wrong length.  I'd rather see a "number of coords" parameter added 
to the method, get rid of the ==/null/length tests and only test the 
number of coords that were appropriate to the segment type.  Technically 
you are testing entries in the arrays that weren't required to be equal 
by the PathIterator contract, but in practice it would be odd for the 
iterator to scribble random values into the unused entries (not 
disallowed, but odd).

- What am I missing on the difference between the two test files?  Can 
they be combined into a single test file?

			...jim

On 3/27/15 9:33 AM, Laurent Bourg?s wrote:
> Jim,
>
> Here is a new Path2d patch:
> http://cr.openjdk.java.net/~lbourges/path2D/Path2D.2/
>
> Changes:
> - Fix ArrayIndexOutOfBounds in ptCrossing / rectCrossing when coords
> array is zero-sized (0 capacity constructor): bug present in jdk8
> - new tests:
> Path2dEmpty to test this bug
> Path2dCopyConstructor to test my changes on the copy constructor
> following your instructions
>
> Maybe we should create a new bug and split this patch in 2 separated ones ?
>
> Laurent
>
> Le 7 mars 2015 02:43, "Jim Graham" <james.graham at oracle.com
> <mailto:james.graham at oracle.com>> a ?crit :
>>
>> First, the test cases that I asked for were to verify that a path that was cloned was still operational.  I see no tests that verify that the returned objects will still function, only tests that examine internal data structures for a metric that may not be appropriate in the future.
>>
>> On 3/6/15 11:06 AM, Phil Race wrote:
>>>
>>> So the test should go in the anonymous package and avoid accessing
>>> internals.
>>> It should be possible to use just public API  to verify the arrays  of a
>>> shape
>>> being cloned are trimmed .
>>
>>
>> We should not be testing if the cloned arrays are trimmed.  We don't care from a testing standpoint.  It is an implementation detail of a performance feature and we should not write any test that says "Object A should do its work by doing X, Y, and Z".
>>
>> If we want to test performance then we should write a benchmark that tests how long it takes to do an operation.  That will likely be a manual test, though.  It should not be examining internals to take its measurements, though.  Benchmarks tend to only use public APIs as they should be benchmarking operations that Java programs encounter.
>>
>> If we want to test if your fix will break something, then we need to test that.  Currently your tests do not do that.  We only need public APIs to do that.
>>
>> What I would like to see in the test:
>>
>> - Delete all of the existing tests in there.  None of them are appropriate to our testing goals.
>>
>> - Write tests that create paths in various forms and run them through the following sub-tests:
>>      - each of the following should be tested on a fresh clone...
>>      - get a PathIterator and iterate it through until it is done
>>        (optional - compare to the expected segments that were in the original)
>>      - get a flattened PathIterator using "getPathIterator(flatness,)" and make sure it works
>>        (optional - compare to original path if the original was already flat)
>>        (but, also run it on a path with curves to make sure flattening engine didn't break)
>>      - add various kinds of segments to the cloned path
>>      - get the bounds of the cloned path
>>      - use the transform() method on the cloned path
>>      - call intersects(point), intersects(rect) and contains(rect) on a cloned path
>>      - call getCurrentPoint() on the cloned path
>>
>> - Perform each of the above tests on a (set of) clone(s) of the following paths:
>>      - each of the following executed on both a Float and a Double instance...
>>      - an empty path
>>      - a path with just a moveto
>>      - a path with a moveto+some lines
>>      - a path with a moveto+some curves
>>
>> The way I tend to write tests like this is to use cascading methods like:
>>
>> void testEqual(Path2D pathA, Path2D path2D pathB) {
>>     // Grab 2 path iterators and test for equality with float coords[]
>> }
>>
>> void test(Path2D p2d, boolean isEmpty) {
>>     testEqual(new Path2D.Float(p2d), p2d);
>>     testEqual(new Path2D.Double(p2d), p2d);
>>     testEqual(new GeneralPath(p2d), p2d);
>>
>>     testIterator(new Path2D.Float(p2d));
>>     testIterator(new Path2D.Double(p2d));
>>     testIterator((Path2D) p2d.clone());
>>
>>     testFlattening(... 3 clone variants ...);
>>
>>     testAddMove(... 3 clone variants ...);
>>     // These should expect exception if empty
>>     testAddLine(... 3 clone variants ..., isEmpty);
>>     testAddQuad(... 3 clone variants ..., isEmpty);
>> }
>>
>> interface PathFactory {
>>     Path2D makePath();
>> }
>>
>> void test(PathFactory pf) {
>>     test(pf.makePath(), true);
>>     test(addMove(pf.makePath()), false);
>>     test(addLines(pf.makePath()), false);
>>     test(addCurves(pf.makePath())), false);
>> }
>>
>> @Test
>> void testFloatPaths() {
>>     test(() -> new Path2D.Float());
>> }
>>
>> @Test
>> void testDoublePaths() {
>>     test(() -> new Path2D.Double());
>> }
>>
>> @Test
>> void testGeneralPath() {
>>     test(() -> new GeneralPath());
>> }
>>
>>                         ...jim
>


From Sergey.Bylokhov at oracle.com  Sat Mar 28 00:31:42 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Sat, 28 Mar 2015 03:31:42 +0300
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <5515D099.9020808@oracle.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>	<55142689.2010900@oracle.com>	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>	<55147F81.2020707@oracle.com>	<7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
	<5515D099.9020808@oracle.com>
Message-ID: <5515F66E.8020503@oracle.com>

28.03.15 0:50, Jim Graham wrote:
> On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
>
> That's an odd bug.  I'll note that it points out that we had missing 
> loops in the OpenGL pipeline to directly deal with the non-PRE data 
> and it links to a bug that adds those loops for more direct handling.
Actually not, the second bug adds a loop which transform non-PRE surface 
to the PRE surface on the fly in software and scale it via OGL(before 
that, conversion and scale were done in software via transformhelper). 
In the JDK-8059943 we save one blit, which transform non_PRE BI to PRE. 
Plus it saves one more blit when we try to cache non_PRE BI into vram 
because this operation will be done via OGLGeneralBlit which also 
convert non-PRE to PRE on the fly.
> It's also not clear why those BufferedImage objects weren't cached.  
> If you create a BI and render to it and then blit from it a bunch of 
> times it should be cached in VRAM and the format shouldn't matter, but 
> if you are constantly rendering to the BI, then our cache never has 
> time to set up - and if you grab the data buffer for that BI, then it 
> will never be cached.  But the buffers we use in the 
> ImageRepresentations should be static and should be cached.
>
> I'm not saying that I have all of the answers as to whether or not 
> changing the PNG decoder to use PRE buffers would help, I'm just 
> trying to delineate all of the considerations that affect whether this 
> is a practical issue or not.  We'd need test cases to test if any of 
> the mechanisms I'm describing are doing their job or not...
>
>             ...jim


-- 
Best regards, Sergey.



From james.graham at oracle.com  Sat Mar 28 01:10:31 2015
From: james.graham at oracle.com (Jim Graham)
Date: Fri, 27 Mar 2015 18:10:31 -0700
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <5515F66E.8020503@oracle.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>	<55142689.2010900@oracle.com>	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>	<55147F81.2020707@oracle.com>	<7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
	<5515D099.9020808@oracle.com> <5515F66E.8020503@oracle.com>
Message-ID: <5515FF87.7060204@oracle.com>

Thanks Sergey,

Have you been following the rest of this thread?  Any thoughts on how 
much the lack of PRE pixel format in the PNG loader might be hurting us?

			...jim

On 3/27/15 5:31 PM, Sergey Bylokhov wrote:
> 28.03.15 0:50, Jim Graham wrote:
>> On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
>>
>> That's an odd bug.  I'll note that it points out that we had missing
>> loops in the OpenGL pipeline to directly deal with the non-PRE data
>> and it links to a bug that adds those loops for more direct handling.
> Actually not, the second bug adds a loop which transform non-PRE surface
> to the PRE surface on the fly in software and scale it via OGL(before
> that, conversion and scale were done in software via transformhelper).
> In the JDK-8059943 we save one blit, which transform non_PRE BI to PRE.
> Plus it saves one more blit when we try to cache non_PRE BI into vram
> because this operation will be done via OGLGeneralBlit which also
> convert non-PRE to PRE on the fly.
>> It's also not clear why those BufferedImage objects weren't cached. If
>> you create a BI and render to it and then blit from it a bunch of
>> times it should be cached in VRAM and the format shouldn't matter, but
>> if you are constantly rendering to the BI, then our cache never has
>> time to set up - and if you grab the data buffer for that BI, then it
>> will never be cached.  But the buffers we use in the
>> ImageRepresentations should be static and should be cached.
>>
>> I'm not saying that I have all of the answers as to whether or not
>> changing the PNG decoder to use PRE buffers would help, I'm just
>> trying to delineate all of the considerations that affect whether this
>> is a practical issue or not.  We'd need test cases to test if any of
>> the mechanisms I'm describing are doing their job or not...
>>
>>             ...jim
>
>


From bourges.laurent at gmail.com  Sun Mar 29 14:40:29 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Sun, 29 Mar 2015 16:40:29 +0200
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <5515DBE7.9000207@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<CAKjRUT70rRoTfSE3Hr2-igYA-puymWYrVSZo=V4=WsfchZ8+Uw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
	<5515DBE7.9000207@oracle.com>
Message-ID: <CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>

Dear Jim,

Here is the new webrev:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D.3/

> Looks great.

Thanks, I hope this patch is ready to go in.

> - A couple of methods have "/**" even though the comment is just
informational to the programmer and not representing an API.  It looks like
"/**" is the standard practice for the @test comment at the top of the
class even though jtreg isn't spec'd to require it, but elsewhere it's just
noise.

I removed javadoc and superfluous comments.

> - In general tests shouldn't print out a lot of noise (see "verbosity" in
http://openjdk.java.net/jtreg/writetests.html).  Ideally an automated test
would produce no output if it is successful, but some of our automated
tests do print out a short summary (mostly if they were stress-bashers).
Some of them can be run in "verbose mode" to print out details in case an
engineer is diagnosing a failure and wants to know what failed and why - I
saw a few in the AffineTransform directory that had a static boolean
verbose that was set if there was an argument handed to main() for
instance.  A verbose option can help when running the test in manual mode
for debugging.

Ok, I added the verbose flag as indicated.

> - I'd add a testAddCubic() and testAddClose() to the tests.  It looks
like the "testAddQuad" method does add both types of curve, but the cubic
curve is added after the quad so we don't get a case that adds a cubic to a
freshly cloned path - which is the main state in question to be tested here.

Done.

> - equalsArray has some tests in it that don't make a lot of sense since
you created the arrays and so you know that they aren't == or null or the
wrong length.  I'd rather see a "number of coords" parameter added to the
method, get rid of the ==/null/length tests and only test the number of
coords that were appropriate to the segment type.  Technically you are
testing entries in the arrays that weren't required to be equal by the
PathIterator contract, but in practice it would be odd for the iterator to
scribble random values into the unused entries (not disallowed, but odd).

Fixed: I only check the correct subpart according to the segment type.

> - What am I missing on the difference between the two test files?  Can
they be combined into a single test file?

Big one: I figured out a bug in Path2d happening with 0 capacity:
rectCrossing and ptCrossing fail.

Finally I merged both tests into the same bugid that may be backported
later to jdk8...

Regards,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150329/c1e17cc7/attachment.html>

From james.graham at oracle.com  Mon Mar 30 19:18:19 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 30 Mar 2015 12:18:19 -0700
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
	<5515DBE7.9000207@oracle.com>
	<CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>
Message-ID: <5519A17B.5000807@oracle.com>

Hi Laurent,

Test program, line 490 - MOVETO has 2 coordinates associated with it.

Test program, line 492 - perhaps we should throw an exception on default 
since it indicates a problem with the iterator

Other than that, it looks good...

On 3/29/15 7:40 AM, Laurent Bourg?s wrote:
>> - What am I missing on the difference between the two test files?  Can they be combined into a single test file?
>
> Big one: I figured out a bug in Path2d happening with 0 capacity:
> rectCrossing and ptCrossing fail.

I'm guessing that is why there are the new shortcut returns on the 
intersects/contains methods in Path2D?  I see it now...

			...jim


From Sergey.Bylokhov at oracle.com  Mon Mar 30 19:28:15 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 30 Mar 2015 22:28:15 +0300
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <5515FF87.7060204@oracle.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>	<55142689.2010900@oracle.com>	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>	<55147F81.2020707@oracle.com>	<7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
	<5515D099.9020808@oracle.com> <5515F66E.8020503@oracle.com>
	<5515FF87.7060204@oracle.com>
Message-ID: <5519A3CF.8070205@oracle.com>

28.03.15 4:10, Jim Graham wrote:
> Thanks Sergey,
>
> Have you been following the rest of this thread?  Any thoughts on how 
> much the lack of PRE pixel format in the PNG loader might be hurting us?
It depends. Not the best format can slow down us from x2 to x10 and 
more(before we cache the image). On osx the best format is argb_pre, but 
it is unclear what is the best format on other platforms(especially on 
windows where we can switch loops gdi<-->d3d).
>
>             ...jim
>
> On 3/27/15 5:31 PM, Sergey Bylokhov wrote:
>> 28.03.15 0:50, Jim Graham wrote:
>>> On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
>>>
>>> That's an odd bug.  I'll note that it points out that we had missing
>>> loops in the OpenGL pipeline to directly deal with the non-PRE data
>>> and it links to a bug that adds those loops for more direct handling.
>> Actually not, the second bug adds a loop which transform non-PRE surface
>> to the PRE surface on the fly in software and scale it via OGL(before
>> that, conversion and scale were done in software via transformhelper).
>> In the JDK-8059943 we save one blit, which transform non_PRE BI to PRE.
>> Plus it saves one more blit when we try to cache non_PRE BI into vram
>> because this operation will be done via OGLGeneralBlit which also
>> convert non-PRE to PRE on the fly.
>>> It's also not clear why those BufferedImage objects weren't cached. If
>>> you create a BI and render to it and then blit from it a bunch of
>>> times it should be cached in VRAM and the format shouldn't matter, but
>>> if you are constantly rendering to the BI, then our cache never has
>>> time to set up - and if you grab the data buffer for that BI, then it
>>> will never be cached.  But the buffers we use in the
>>> ImageRepresentations should be static and should be cached.
>>>
>>> I'm not saying that I have all of the answers as to whether or not
>>> changing the PNG decoder to use PRE buffers would help, I'm just
>>> trying to delineate all of the considerations that affect whether this
>>> is a practical issue or not.  We'd need test cases to test if any of
>>> the mechanisms I'm describing are doing their job or not...
>>>
>>>             ...jim
>>
>>


-- 
Best regards, Sergey.



From james.graham at oracle.com  Mon Mar 30 21:00:08 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 30 Mar 2015 14:00:08 -0700
Subject: [OpenJDK 2D-Dev] Provide a way to make MultiResolutionImage
 screen compatible
In-Reply-To: <5519A3CF.8070205@oracle.com>
References: <D6CB1CC4-4D39-4668-A8F7-A9C8B3C19E8E@tagtraum.com>	<55142689.2010900@oracle.com>	<8BF5C978-A676-4A13-876C-1A8BC7C8C2A4@tagtraum.com>	<55147F81.2020707@oracle.com>	<7EB3FC60-83B7-40C3-AFDE-04DE3CD85A0D@tagtraum.com>
	<5515D099.9020808@oracle.com> <5515F66E.8020503@oracle.com>
	<5515FF87.7060204@oracle.com> <5519A3CF.8070205@oracle.com>
Message-ID: <5519B958.5080607@oracle.com>

Hi Sergey,

Slow us down where?

Toolkit images should end up cached in textures loaded onto the video 
card in a format that the GPU understands directly, aren't they?

So, are you referring to slowing down in the upload to the texture which 
happens only once for a toolkit image?  Or will it somehow cause the 
resulting cached uploaded texture to underperform once it is living on 
the GPU?  Or are there common operations on Toolkit images where we do 
not use a cached texture?

			...jim

On 3/30/15 12:28 PM, Sergey Bylokhov wrote:
> 28.03.15 4:10, Jim Graham wrote:
>> Thanks Sergey,
>>
>> Have you been following the rest of this thread?  Any thoughts on how
>> much the lack of PRE pixel format in the PNG loader might be hurting us?
> It depends. Not the best format can slow down us from x2 to x10 and
> more(before we cache the image). On osx the best format is argb_pre, but
> it is unclear what is the best format on other platforms(especially on
> windows where we can switch loops gdi<-->d3d).
>>
>>             ...jim
>>
>> On 3/27/15 5:31 PM, Sergey Bylokhov wrote:
>>> 28.03.15 0:50, Jim Graham wrote:
>>>> On 3/27/15 3:48 AM, Hendrik Schreiber wrote:
>>>>
>>>> That's an odd bug.  I'll note that it points out that we had missing
>>>> loops in the OpenGL pipeline to directly deal with the non-PRE data
>>>> and it links to a bug that adds those loops for more direct handling.
>>> Actually not, the second bug adds a loop which transform non-PRE surface
>>> to the PRE surface on the fly in software and scale it via OGL(before
>>> that, conversion and scale were done in software via transformhelper).
>>> In the JDK-8059943 we save one blit, which transform non_PRE BI to PRE.
>>> Plus it saves one more blit when we try to cache non_PRE BI into vram
>>> because this operation will be done via OGLGeneralBlit which also
>>> convert non-PRE to PRE on the fly.
>>>> It's also not clear why those BufferedImage objects weren't cached. If
>>>> you create a BI and render to it and then blit from it a bunch of
>>>> times it should be cached in VRAM and the format shouldn't matter, but
>>>> if you are constantly rendering to the BI, then our cache never has
>>>> time to set up - and if you grab the data buffer for that BI, then it
>>>> will never be cached.  But the buffers we use in the
>>>> ImageRepresentations should be static and should be cached.
>>>>
>>>> I'm not saying that I have all of the answers as to whether or not
>>>> changing the PNG decoder to use PRE buffers would help, I'm just
>>>> trying to delineate all of the considerations that affect whether this
>>>> is a practical issue or not.  We'd need test cases to test if any of
>>>> the mechanisms I'm describing are doing their job or not...
>>>>
>>>>             ...jim
>>>
>>>
>
>


From bourges.laurent at gmail.com  Mon Mar 30 21:31:51 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Mon, 30 Mar 2015 23:31:51 +0200
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <5519A17B.5000807@oracle.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
	<5515DBE7.9000207@oracle.com>
	<CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>
	<5519A17B.5000807@oracle.com>
Message-ID: <CAKjRUT5AO0r2pwWVfyxRoToj3XOnJCuh+KbTKK3_=oTuABmWMA@mail.gmail.com>

Jim,

Test program, line 490 - MOVETO has 2 coordinates associated with it.
>

Well spotted: I did it too quickly, sorry.

Test program, line 492 - perhaps we should throw an exception on default
> since it indicates a problem with the iterator
>

Ok.


> Other than that, it looks good...
>

Thanks, I will tomorrow prepare a new webrev.

 - What am I missing on the difference between the two test files?  Can
>>> they be combined into a single test file?
>>>
>>
>> Big one: I figured out a bug in Path2d happening with 0 capacity:
>> rectCrossing and ptCrossing fail.
>>
>
> I'm guessing that is why there are the new shortcut returns on the
> intersects/contains methods in Path2D?  I see it now...
>

Exactly: that test fails on JDK 1.8.0_60.

Should we submit another bug to JDK8 ?
Or at least, ask to backport this bug once fixed.

Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150330/5a2784cb/attachment.html>

From james.graham at oracle.com  Mon Mar 30 22:15:44 2015
From: james.graham at oracle.com (Jim Graham)
Date: Mon, 30 Mar 2015 15:15:44 -0700
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <CAKjRUT5AO0r2pwWVfyxRoToj3XOnJCuh+KbTKK3_=oTuABmWMA@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
	<5515DBE7.9000207@oracle.com>
	<CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>
	<5519A17B.5000807@oracle.com>
	<CAKjRUT5AO0r2pwWVfyxRoToj3XOnJCuh+KbTKK3_=oTuABmWMA@mail.gmail.com>
Message-ID: <5519CB10.7050800@oracle.com>

Hi Laurent,

On 3/30/15 2:31 PM, Laurent Bourg?s wrote:
>         Big one: I figured out a bug in Path2d happening with 0 capacity:
>         rectCrossing and ptCrossing fail.
>
>
>     I'm guessing that is why there are the new shortcut returns on the
>     intersects/contains methods in Path2D?  I see it now...
>
>
> Exactly: that test fails on JDK 1.8.0_60.
>
> Should we submit another bug to JDK8 ?
> Or at least, ask to backport this bug once fixed.

It should be a clean backport so that makes sense to get it fixed there 
too...

			...jim


From bourges.laurent at gmail.com  Tue Mar 31 14:33:24 2015
From: bourges.laurent at gmail.com (=?ISO-8859-1?Q?Laurent_Bourg=E8s?=)
Date: Tue, 31 Mar 2015 16:33:24 +0200
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <CAKjRUT5AO0r2pwWVfyxRoToj3XOnJCuh+KbTKK3_=oTuABmWMA@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>
	<54E5CA9A.3090801@oracle.com>
	<CAGUMyaTi0Pief5jtRnp_Nr2b4P1rCnj7j1EcfQniibSrpDi0Sw@mail.gmail.com>
	<54E5F25F.2020303@oracle.com> <1424361976.4253.41.camel@localhost>
	<54E67B0A.8080508@oracle.com>
	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>
	<54E7846E.6000703@oracle.com>
	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>
	<54ECB5CD.8080602@oracle.com> <54ECB8B8.2010806@oracle.com>
	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>
	<54ED1FF2.3040209@oracle.com>
	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>
	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>
	<54F9FA9A.1060705@oracle.com> <54FA57B8.60201@oracle.com>
	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>
	<5515DBE7.9000207@oracle.com>
	<CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>
	<5519A17B.5000807@oracle.com>
	<CAKjRUT5AO0r2pwWVfyxRoToj3XOnJCuh+KbTKK3_=oTuABmWMA@mail.gmail.com>
Message-ID: <CAKjRUT6ki9s3SZsiUU__KHT+wom6+Of7Cy+JC8T+SQvnHcbW0g@mail.gmail.com>

Jim,


> Test program, line 490 - MOVETO has 2 coordinates associated with it.
>>
>
> Well spotted: I did it too quickly, sorry.
>
> Test program, line 492 - perhaps we should throw an exception on default
>> since it indicates a problem with the iterator
>>
>
> Ok.
>

Here is the new webrev:
http://cr.openjdk.java.net/~lbourges/path2D/Path2D.4/

I fixed the getLength(type) method:

 482     static int getLength(int type) {
 483         switch(type) {
 484             case PathIterator.SEG_CUBICTO:
 485                 return 6;
 486             case PathIterator.SEG_QUADTO:
 487                 return 4;* 488             case PathIterator.SEG_LINETO:
 489             case PathIterator.SEG_MOVETO:
 490                 return 2;
* 491             case PathIterator.SEG_CLOSE:
 492                 return 0;* 493             default:
 494                 throw new IllegalStateException("Invalid type: " + type);
* 495         }
 496     }


If it is good, could you push this patch in both graphics-rasterizer
and java2d repositories ?

or do you prefer I push this patch into graphics-rasterizer and later
it will be merged into java2d and possibly backported to JDK8 ?


Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20150331/0bdb4698/attachment.html>

From philip.race at oracle.com  Tue Mar 31 21:16:02 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 31 Mar 2015 14:16:02 -0700
Subject: [OpenJDK 2D-Dev] RFR: 8035302: Eliminate dependency on
 sun.nio.cs from AWT and Motif code
In-Reply-To: <55143738.9080507@oracle.com>
References: <54E7ABB8.7010901@oracle.com>
	<54E7B587.70904@oracle.com>	<54E8499F.7060706@oracle.com>
	<55074BDE.1050602@oracle.com>	<550B14BF.3040209@oracle.com>
	<550B91D3.6000406@oracle.com> <550C9375.8070404@oracle.com>
	<55133B36.5040109@oracle.com> <5513BF28.30002@oracle.com>
	<55143390.7060208@oracle.com> <55143738.9080507@oracle.com>
Message-ID: <551B0E92.7070107@oracle.com>

Its a fixed set, but what I have here is using a public means
to grab the same information previously obtained from the same internal
source by internal means.
I do not see it as worth my time to create and test and maintain a map
when this should work fine and should be at least as robust as a map.

-phil.

On 03/26/2015 09:43 AM, Alan Bateman wrote:
> On 26/03/2015 16:28, Xueming Shen wrote:
>>
>> An alternative is to simply grip the names and build a small internal 
>> mapping for those used
>> by the fonts, it's a limited/small/fixed list, I assume. That might 
>> be look better than the current
>> hacky one.
> So a small name -> historical name map? If that is possible then it 
> would be cleaner.
>
> -Alan



From philip.race at oracle.com  Tue Mar 31 21:51:59 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 31 Mar 2015 14:51:59 -0700
Subject: [OpenJDK 2D-Dev] [OpenJDK Rasterizer] Path2D optimizations
In-Reply-To: <CAKjRUT6ki9s3SZsiUU__KHT+wom6+Of7Cy+JC8T+SQvnHcbW0g@mail.gmail.com>
References: <CAKjRUT4DubAF2h-EGOEdjvWGkMfrqjMtVzbfp44-CJ4U0+ijAw@mail.gmail.com>	<54E67B0A.8080508@oracle.com>	<CAKjRUT668AxH85H3ZPahFx0c4tTuo=pf4ubHP19kkXNOWMvO8g@mail.gmail.com>	<54E7846E.6000703@oracle.com>	<CAKjRUT6Ks115_uKZ1byEmyoG_Ts1n_U_Pw4c6__C=g4FocE-Fg@mail.gmail.com>	<54ECB5CD.8080602@oracle.com>	<54ECB8B8.2010806@oracle.com>	<CAKjRUT4NtKfP+p_-mp5G-ewkBpL4AQSYB+4HWjBq59vrvr6diw@mail.gmail.com>	<54ED1FF2.3040209@oracle.com>	<CAKjRUT4JyAnv8TdPYm3JMH6rVHpz_AYonL0hnEXzbvxLQXyuHQ@mail.gmail.com>	<CAKjRUT5DMFQ_49smYnzD7pLF+63D5UQnFhV0rJ33oSBy7u+NeQ@mail.gmail.com>	<54F9FA9A.1060705@oracle.com>	<54FA57B8.60201@oracle.com>	<CAKjRUT4-23GVwnzz+qyqURGtV_sOvCjtahavND7Gy5K2tHO4tw@mail.gmail.com>	<5515DBE7.9000207@oracle.com>	<CAKjRUT6+ODXc7jckPM0PP_A9w+sgCEmP4dPu26u85DF6xZVitg@mail.gmail.com>	<5519A17B.5000807@oracle.com>	<CAKjRUT5AO0r2pwWVfyxRoToj3XOnJCuh+KbTKK3_=oTuABmWMA@mail.gmail.com>
	<CAKjRUT6ki9s3SZsiUU__KHT+wom6+Of7Cy+JC8T+SQvnHcbW0g@mail.gmail.com>
Message-ID: <551B16FF.5040109@oracle.com>

Hi,

This looks like something it would be good to push to the
http://hg.openjdk.java.net/jdk9/client/jdk repo first.
That can then be backported to 8u60.

Then we'll sync it into graphics-rasterizer as part of a normal JDK 
forest sync.

The only catch is you aren't a JDK 9 committer so you can prepare
a patch, or even a changeset,  but can't do the actual push although
preparing this patch will help get you there. So Jim, or I, or someone
else who is a committer can push it for you.

-phil.

On 3/31/2015 7:33 AM, Laurent Bourg?s wrote:
> Jim,
>
>
>         Test program, line 490 - MOVETO has 2 coordinates associated
>         with it.
>
>
>     Well spotted: I did it too quickly, sorry.
>
>         Test program, line 492 - perhaps we should throw an exception
>         on default since it indicates a problem with the iterator
>
>
>     Ok.
>
>
> Here is the new webrev:
> http://cr.openjdk.java.net/~lbourges/path2D/Path2D.4/ 
> <http://cr.openjdk.java.net/%7Elbourges/path2D/Path2D.4/>
>
> I fixed the getLength(type) method:
>   482     static int getLength(int type) {
>   483         switch(type) {
>   484             case PathIterator.SEG_CUBICTO:
>   485                 return 6;
>   486             case PathIterator.SEG_QUADTO:
>   487                 return 4;
> *  488             case PathIterator.SEG_LINETO:
>   489             case PathIterator.SEG_MOVETO:
>   490                 return 2;
> *  491             case PathIterator.SEG_CLOSE:
>   492                 return 0;
> *  493             default:
>   494                 throw new IllegalStateException("Invalid type: " + type);
> *  495         }
>   496     }
>
> If it is good, could you push this patch in both graphics-rasterizer and java2d repositories ?
>
> or do you prefer I push this patch intographics-rasterizer and later it will be merged into java2d and possibly backported to JDK8 ?
>
> Laurent