On Mon, 30 Aug 2021 19:23:57 GMT, Сергей Цыпанов
wrote:
>> Just a very tiny clean-up.
>>
>> There are some places in JDK code base where we call
>> `Enum.class.getEnumConstants()` to get all the values of the referenced
>> `enum`. This is excessive, less-readable and slower than just calling
On Fri, 13 Aug 2021 03:51:23 GMT, Jonathan Gibbons wrote:
> Please review a relatively simple update to have doclnt check for empty
> "descriptions" -- the body of a doc comment, before the block tags.
>
> It is already the case that doclint checks for missing/empty descriptions in
> block
On Fri, 16 Jul 2021 21:39:56 GMT, Vest
wrote:
>> This is the last part of Post JEP 411 refactoring that makes
>> `@SuppressWarnings("removal")` more fine grained. This fix deals with all
>> client libs annotations that cover more than 10K bytes of code.
>
>
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>>
On Mon, 17 May 2021 10:18:54 GMT, Ajit Ghaisas wrote:
> This PR reverts to OpenGL as the default Java2D rendering pipeline for macOS.
>
> Note : from JBS description :
> In JDK 17 build 19 under bug id
> [JDK-8265304](https://bugs.openjdk.java.net/browse/JDK-8265304) we switched
> to Metal as
On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote:
> This PR makes Metal as the default Java2D rendering pipeline for macOS.
>
> Note : from JBS description :
> The plan of record has always been that for JDK 17 the new Metal pipeline
> will be OFF by default and must be explicitly enabled
On Fri, 2 Apr 2021 11:44:52 GMT, Alexey Ushakov wrote:
>> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT
>> property. MTLLayer.h header cleanup.
>
> Alexey Ushakov has updated the pull request incrementally with one additional
> commit since the last revision:
>
>
On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick wrote:
>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
>
On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick wrote:
> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
src/java.desktop/share/classes/java/applet/package-info.java line 39:
> 37: * applet development environment.
> 38: *
> 39: * @deprecated. This package
On Thu, 11 Mar 2021 18:00:15 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal
On Wed, 10 Mar 2021 10:51:08 GMT, Ajit Ghaisas wrote:
>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering
>> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the
>> Apple Metal
On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski wrote:
> General comment - I am not sure I like the `MTL` prefix acronym in names (ex.
> `sun.java2d.metal.MTLVolatileSurfaceManager`).
>
> I think you tried to match the `CGL`, but that is a real acronym that stands
> for "Core Graphics Layer"
On Mon, 8 Feb 2021 13:40:22 GMT, Ajit Ghaisas wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894:
>>
>>> 892: SHADERS_SUPPORT_DIR :=
>>> $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui
>>> 893: SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air
>>> 894: SHADERS_LIB :=
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
>
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
>
On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas wrote:
> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering
> Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple
> Metal API.
>
On Mon, 1 Feb 2021 18:33:32 GMT, Gerard Ziemski wrote:
>> Marked as reviewed by gziemski (Committer).
>
> The changes look good to me, but please see my comment from my review about
> documenting `NormalizedPathNSStringFromJavaString()` API.
The following commit was integrated to jdk master
On Tue, 2 Feb 2021 00:30:07 GMT, Phil Race wrote:
>> src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 53:
>>
>>> 51: @implementation ThreadUtilities
>>> 52:
>>> 53: + (void)initialize {
>>
>> I think we need to check how this new modes will work when the AWT is
>> embedded
On Fri, 15 Jan 2021 23:06:21 GMT, Sergey Bylokhov wrote:
>> One more idea:
>> should I rename all Dxxx classes to xxx to make code more obvious, readable ?
>>
>> However, renaming DMarlinRenderingEngine to MarlinRenderingEngine may lead
>> confusion with previous versions and may be a
On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick wrote:
>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request incrementally with one additional
> commit since the last revision:
>
> JDK-8189198: Add "forRemoval = true" to Applet APIs
On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman wrote:
>> Andy Herrick has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains six additional
>> commits
On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote:
> JDK-8189198: Add "forRemoval = true" to Applet APIs
@andyherrick can you enter the `/csr needed` command? I would, but it needs to
be done by either the author of the PR or a Reviewer.
-
PR:
On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick wrote:
>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> preliminary changes for JDK-8189198 for evaluation
The following field, which is currently deprecated (not for removal) should
probably also be marked as deprecated for removal::
On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson wrote:
>> This is a review request for the bug particularly fixed some time ago:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>>
>> In that review request it was found that the old fix does not work well in
>> all cases,
On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote:
> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
>
> In that review request it was found that the old fix does not work well in
> all cases,
On Fri, 2 Oct 2020 17:48:39 GMT, Phil Race wrote:
> Running a test build with the doclint warning found this missed case
>
> A CSR has been created https://bugs.openjdk.java.net/browse/JDK-8253946
Marked as reviewed by kcr (Author).
-
PR: https://git.openjdk.java.net/jdk/pull/488
It is an anti-pattern to rely on an implicit default constructor in a
publicly exported class in a library. There are (at least) three good
reasons to avoid this:
1. The default constructor will have no API docs
2. You could end up with a public constructor in a class where you don't
want a
On Tue, 15 Sep 2020 22:18:09 GMT, Kevin Rushforth wrote:
> This adds the following extensions to the list of source files that git
> jcheck will check for whitespace errors:
>
> .cc, .hh, .m, .mm
>
> All files with the above extensions are now white-space clean after the
This adds the following extensions to the list of source files that git jcheck
will check for whitespace errors:
.cc, .hh, .m, .mm
All files with the above extensions are now white-space clean after the fix for
[JDK-8240487](https://bugs.openjdk.java.net/browse/JDK-8240487). This will help
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
>> The code in java.base was updated to use String::isEmpty in JDK 12
>> (JDK-8215281). There was follow-up in JDK 13 to do
>> the same in the java.desktop module (JDK-8223237). Changing the remaining
>> usages make sense although I see
On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy
wrote:
>> @doom369 jcheck requires an associated issue
>
> @mrserb hello. Thanks for the review. Any further actions required from me?
Before this Enhancement can be formally reviewed, you will need a JBS bug ID.
If you are already working
On Wed, 9 Sep 2020 23:17:21 GMT, Sergey Bylokhov wrote:
>> This the only test which was created to check different types of
>> interpolation.
>> It checks the rendering to the VolatileImage and uses BufferedImage as a
>> gold image.
>> But it does not take into account that rendering to the
On Tue, 8 Sep 2020 21:54:43 GMT, Sergey Bylokhov wrote:
> This the only test which was created to check different types of
> interpolation.
> It checks the rendering to the VolatileImage and uses BufferedImage as a gold
> image.
> But it does not take into account that rendering to the
On 8/25/2020 4:17 PM, Sergey Bylokhov wrote:
On 25.08.2020 16:08, Kevin Rushforth wrote:
I haven't tested an FX app yet, but since this changes the plist
properties, I want to see whether or not FX apps are impacted.
It should be affected because the first variation of the fix was
pushed
app yet, but since this changes the plist
properties, I want to see whether or not FX apps are impacted.
-- Kevin
On 8/25/2020 4:01 PM, Sergey Bylokhov wrote:
On 25.08.2020 15:40, Philip Race wrote:
On 8/25/20, 12:27 PM, Sergey Bylokhov wrote:
On 25.08.2020 05:43, Kevin Rushforth wrote:
Does
Does this only apply when the MacBook is running on battery, or will
this affect performance even when the laptop is plugged in? If the
latter, I wonder what Apple's rationale is for including a discrete
graphics card that isn't used most of the time.
-- Kevin
On 8/24/2020 11:27 PM, Sergey
Looks good to me. I verified that the only changes are whitespace
changes, and that after applying the patch there are no more whitespace
errors.
+1
-- Kevin
On 8/5/2020 6:46 PM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8240487
Webrev:
Looks good.
+1
-- Kevin
On 6/19/2020 3:23 PM, Philip Race wrote:
Bug : https://bugs.openjdk.java.net/browse/JDK-8244818
Webrev : http://cr.openjdk.java.net/~prr/8244818/
Please review this fix for JDK 15 :
This crash was reported recently but we'd not been able to reproduce
it until we
that. -phil.
On 6/11/2020 11:13 AM, Kevin Rushforth wrote:
+1
The updated LargeWindowPaintTest fails for me without the fix without
my having to manually set uiScale. It passes with the fix.
Interestingly enough, I finally saw the problem that Jay reported
with AlphaPrintTest: without the fix
es with patch.
AlphaPrintTest shows instructions without patch also.
@Phil : I think its better if we test at uiScale=1(larger memory
footprint). Please clarify.
Thanks,
Jay
On 11-Jun-2020, at 5:53 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>
wrote:
Do you have a Hi-DPI mac
1-Jun-2020, at 5:53 PM, Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
Do you have a Hi-DPI machine? I do, and had to run with
"-Dsun.java2d.uiScale=1" in order to see the failure with
LargeWindowPaintTest.
For AlphaPrintTest, the test deliberately ensures that
Do you have a Hi-DPI machine? I do, and had to run with
"-Dsun.java2d.uiScale=1" in order to see the failure with
LargeWindowPaintTest.
For AlphaPrintTest, the test deliberately ensures that you print before
saying whether it passes or not. FWIW, I verified that the printing test
on my
+1
Code changes look good.
I verified that the bug happens on my Windows 10 laptop with SwingSet2
and with the LargeWindowPaintTest without the patch, and everything
looks good with the patch.
-- Kevin
On 6/10/2020 1:48 PM, Philip Race wrote:
Bug:
Hi Prasanta,
No, the reason for the warning / garbled JavaFX printing in this Java2D
bug (JDK-8244621) is *similar to* that of FX bug JDK-8234916, but in no
way is one of them caused by the other.
-- Kevin
On 6/1/2020 5:21 AM, Prasanta Sadhukhan wrote:
Hi Phil,
I was reading somewhere
+1
In case you want to fix it before you push, you have trailing whitespace
in the file (jcheck won't complain since it doesn't check .m files, so
no worries if you don't).
-- Kevin
On 5/21/2020 1:56 PM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8244621
Webrev :
+1
-- Kevin
On 4/4/2020 8:16 PM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8220150
Webrev : http://cr.openjdk.java.net/~prr/8220150/
We are being returned grey glyphs when asking for B
The same is true for LCD, although they are a little different and not
the main
://cr.openjdk.java.net/~prr/8231556.2/
-phil.
On 12/19/19 11:50 AM, Kevin Rushforth wrote:
Are the parentheses in the right place here?
+ return
+ (this.fullName.equals(other.fullName)) &&
+ (this.platName == null && other.platName == null) ||
+ (this.platName != null && this.platNa
Are the parentheses in the right place here?
+ return
+ (this.fullName.equals(other.fullName)) &&
+ (this.platName == null && other.platName == null) ||
+ (this.platName != null && this.platName.equals(other.platName));
This is equivalent to:
+ return
+ (
/19 5:17 PM, Sergey Bylokhov wrote:
+1
On 10/29/19 1:55 pm, Kevin Rushforth wrote:
+1
-- Kevin
On 10/29/2019 12:51 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8232154
Webrev: http://cr.openjdk.java.net/~prr/8232154/
This is updating the header files we use to build
+1
-- Kevin
On 10/29/2019 12:51 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8232154
Webrev: http://cr.openjdk.java.net/~prr/8232154/
This is updating the header files we use to build the OpenGL code on
all platforms.
It is quite a large update since we were many,
Looks good.
+1
-- Kevin
On 8/6/2019 12:28 AM, Laurent Bourgès wrote:
Ping:
Could someone do a second review ?
Laurent
Le ven. 2 août 2019 à 17:01, Laurent Bourgès
mailto:bourges.laur...@gmail.com>> a écrit :
Thanks Philip,
I am waiting for another approval,
Cheers,
As long as you've addressed all Phil's concerns, it looks OK to me.
-- Kevin
On 6/20/2019 5:57 AM, Jayathirth Rao wrote:
Hi Alexey,
Thanks for the review.
Removed new trace definitions and there references. Webrev without
traces : http://cr.openjdk.java.net/~jdv/8225160/webrev.02/
My testing of the fix on Windows (with the corresponding FX fix) looks
good. A couple comments / questions:
DialogOwner.java:
* The docs should probably say what the behavior is if the application
does not have the alwaysOnTop permission. I presume that the attribute
will be silently ignored
I filed https://bugs.openjdk.java.net/browse/JDK-8202743 to track
getting this fix into JavaFX.
-- Kevin
On 5/4/2018 5:30 AM, Laurent Bourgès wrote:
Sergey,
Please review this simple fix to the Dasher problem:
JBS: https://bugs.openjdk.java.net/browse/JDK-8202580
webrev:
I started looking the FX patch on Friday. I hope to finish my review today.
-- Kevin
Philip Race wrote:
Yes, I approved the 2D patch. I have not yet looked at the FX version.
-phil
On 12/10/17, 12:39 PM, Laurent Bourgès wrote:
Phil,
Thanks for your review.
I suppose you approved the
I can confirm the same behavior that Jon sees with Firefox 57 on Windows 7.
The link scrolls to the right place with the link and does
not with the link.
-- Kevin
Jonathan Gibbons wrote:
Semyon,
Using the files I previously posted, I confirm that I see the same
display problem on a
ew after JavaOne
where we will be able to discuss in a face to face meeting about
Marlin & MarlinFX changes for JDK10.
I hope the 2d / jfx groups have other Graphics Guru to help, as
good as Jim Graham.
Cheers,
Laurent
Le 6 sept. 2017 16:23, "Kevin Rush
Changes look good to me. I verified that they can go in in either order.
-- Kevin
Phil Race wrote:
Hi,
Two bug ids, two webrevs and a cross-post since JDK needs to provide a
qualified export to JavaFX so it can access any fonts that may be
provided
with the JDK.
FX bug:
supporting (without artifacts) subpixel rendering
to transparent surfaces.
Bug 8087201 is about speeding up subpixel rendering.
On 2 August 2016 at 00:39, Kevin Rushforth <kevin.rushfo...@oracle.com
<mailto:kevin.rushfo...@oracle.com>> wrote:
Are you sure you have the
Are you sure you have the right Bug ID? That bug (which is not publicly
visible), is closed as a duplicate of 8087201, which was fixed in JDK 9
and 8u66 over a year ago.
-- Kevin
Torgeir Veimo wrote:
Is there any more work done on JDK bug 8078516?
--
-Tor
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
PS. I'll be pushing the FX part of the fix today. So we should
consider the current interface frozen for now.
Yes, please!
-- Kevin
Anthony Petrov wrote:
On 5/23/2014 3:12 PM, Anton V. Tarasov wrote:
On 23.05.2014 14:47, Anthony Petrov wrote:
1. The host bounds are not related to the
62 matches
Mail list logo
