From philip.race at oracle.com Thu Aug 1 22:13:17 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 01 Aug 2019 15:13:17 -0700 Subject: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region In-Reply-To: References: Message-ID: <5D4363FD.9000007@oracle.com> +1 from me. Looks the same as the FX fix modulo some moving things around. -phil. On 7/29/19, 12:56 AM, Laurent Bourg?s wrote: > Hi, > > Please review this bug fix for the Marlin renderer (introduced in > JDK11.0.2): > JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ > > > This patch is very close to MarlinFX patch integrated last week in > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789 > > Changes: > - Stroker: fixed closePath() to preserve last position and its outcode > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to > preserve last position and its outcode > - Dasher: better precision handling (comparison float value with epsilon) > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to > avoid false positives on long stroked curves (quad / cubic) + lowered > thresholds > > Cheers, > Laurent From bourges.laurent at gmail.com Fri Aug 2 15:01:54 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 2 Aug 2019 17:01:54 +0200 Subject: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region In-Reply-To: <5D4363FD.9000007@oracle.com> References: <5D4363FD.9000007@oracle.com> Message-ID: Thanks Philip, I am waiting for another approval, Cheers, Laurent Le ven. 2 ao?t 2019 ? 00:13, Philip Race a ?crit : > +1 from me. Looks the same as the FX fix modulo some moving things around. > > -phil. > > On 7/29/19, 12:56 AM, Laurent Bourg?s wrote: > > Hi, > > > > Please review this bug fix for the Marlin renderer (introduced in > > JDK11.0.2): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 > > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ > > > > > > This patch is very close to MarlinFX patch integrated last week in > > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789 > > > > Changes: > > - Stroker: fixed closePath() to preserve last position and its outcode > > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to > > preserve last position and its outcode > > - Dasher: better precision handling (comparison float value with epsilon) > > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to > > avoid false positives on long stroked curves (quad / cubic) + lowered > > thresholds > > > > Cheers, > > Laurent > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Fri Aug 2 23:56:13 2019 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 2 Aug 2019 16:56:13 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [13] Review Request: 8225372 accessibility errors in tables in java.desktop files Message-ID: Hello. The accessibility checker found similar issues in the private methods in java.awt.geom.Path2D class. The spec for these methods is exposed via serialization form. So we need to fix it as well: http://cr.openjdk.java.net/~serb/8225372/webrev.02 ----- Sergey.Bylokhov at oracle.com wrote: > Hi, Alexey. > > Thank you for review, the new version is here: > Fix: http://cr.openjdk.java.net/~serb/8225372/webrev.01 > Doc: > http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/module-summary.html > > See comments inline: > > On 14/06/2019 09:19, Alexey Ivanov wrote: > > *GridBagLayout.java* > > Does it make sense to use nested lists for valid values> It could > make the presentation clearer rather than a paragraph followed by a > list. > > We can: > http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/java/awt/GridBagLayout.html > But I am not sure that it looks better due to the current default > styles for nested
  • > > > The value ?center? is invalid for ?float? property in CSS, so it > must be removed, including style attribute of element. > > I dropped all incorrect "float" attributes whenever possible. > > > *DesktopProperties.html* > > I'm still unsure we should suppress rendering in bold, should > we not? > > I changed the code to use default style as-is. > > > *Modality.html* > > The table in examples could be replaced by a series of
      style="float: left"> element with , followed by

      > > Then goes
      . > > I would probably add titles to the examples to make the distinction > between the examples clearer. If each example is preceded by >

      Example #

      , then style="clear: left" can be applied to it. > > If this sounds reasonable, I can file a new bug to handle this. This > way we'll get rid of presentation table. > > I think that the final result will be quite similar to the existing > table? > We can change the order of columns, so the a11y tool will read the > text of the image(Example 1/Example 2/etc) and then the current > description of the example. > http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/java/awt/doc-files/Modality.html > > > > > *NumericShaper.html* > > The table has only one row group, so you have to add row groups: > > elements create the row group that will be associated with > ?Arabic? row group header. > > fixed. > > > *gif_metadata.html* > > As you mention, some tables don't have meaningful row header. And > it's not required in this case. > > Adding the additional index column which does not make the table > clearer does not make any sense to me. We already have column headers > (yes, scope="col" should be added), and that resolves the missing > header problem, doesn't it? > > > > See ?Tables with one header? article in Web Accessibility Tutorial: > > > https://www.w3.org/WAI/tutorials/tables/one-header/#table-with-ambiguous-data > > The current document checker requires both row and columns headers. We > can fix the checker, but I do not see an issue with "index", these > tables look like a grid which contains enumerated data. > > > *tiff_metadata.html* > > Compression type headers should be in (lines 516?518) and > other table content in > > > > In case of Mapping the Standard Metadata Format to TIFF Native Image > Metadata, the first column could probably be the row header. I'm not > sure. > > I added index to all these tables, otherwise, the tables looks > non-unified. > > > > > The extra row in this table, lines 869?872 could be removed > completely. > > Fixed. > > > > > *BoxLayout.java* > > It would suggest more semantic mark-up for "Example" (lines 39?44): > >

      Example: > >

      > > instead of changing only text presentation by ?font-weight: bold? > property on

      element. > > This is applicable to other similar cases. > > [1] has new semantics since HTML5; [2] can also be > used, however, in this case this snipped does not represent anything > of certain importance.> > > style attribute on element has invalid value of ?bottom? for > property ?float?, so it must be removed. > > Fixed. > > > > > [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b > > [2] > https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong > > > > > > *componentProperties.html* > > The same as DesktopProperties.html: should we suppress rendering > in bold? > > > > JFileChooser, JInternalFrame, JInternalFrameTitlePane, JProgressBar, > JSlider, JTabbedPane, Text Properties tables lack element > around the header row. Because of the style applied, the header row is > not rendered in bold. So suppressing bold rendering proved to be > useful. > > > > On 12/06/2019 06:29, Sergey Bylokhov wrote: > >> Hello. > >> Please review the fix for JDK 13. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225372 > >> Fix: http://cr.openjdk.java.net/~serb/8225372/webrev.00 > >> Doc: > http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/module-summary.html > >> > >> In the fix, some(most) of the issues which were reported by the > accessibility checker were fixed. > >> > >> Changes description: > >> > >> ?- In the simplest case, the "scope=col/row" attribute was added to > the tables: > >> > http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html.sdiff.html > >> > >> ?- The tables which are used for a layout were replaced by the >
      .(In fact, this is just emulation of
      ): > >> > http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/swing/JScrollPane.java.sdiff.html > >> > >> ?- Some tables do not have the meaningful cell to be row header, so > I have added an additional column "index" and use it cells as row > header: > >> > http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html.sdiff.html > >> > >> ?- In one place I have added a special role to the table > "role=presentation" because the table was used just for layout and its > content can be read without information about this table: > >> > http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/java/awt/doc-files/Modality.html#Examples > >> > >> ?- In some cases I have dropped the table, and replace it by the > list of elements: > >> > http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java.sdiff.html > >> ???? New: > http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/javax/print/attribute/standard/Finishings.html > >> ???? Old: > https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/standard/Finishings.html > >> > >> Note that I cannot fix two reported issues: > >> ?? Take a look to the "Common dialog" and "HTML Content of example > above" on the links below: > >> > http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/javax/swing/JOptionPane.html > >> > http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/javax/swing/text/html/HTMLDocument.html > >> > >> I tried to mark these tables as "role=presentation" or > "aria-hidden=true", but it does not work because Javadoc tool > generates HTML4 and these attributes are supported by the HTML5. > >> > > > -- > Best regards, Sergey. From bourges.laurent at gmail.com Tue Aug 6 07:28:23 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 6 Aug 2019 09:28:23 +0200 Subject: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region In-Reply-To: References: <5D4363FD.9000007@oracle.com> Message-ID: Ping: Could someone do a second review ? Laurent Le ven. 2 ao?t 2019 ? 17:01, Laurent Bourg?s a ?crit : > Thanks Philip, > > I am waiting for another approval, > Cheers, > Laurent > > Le ven. 2 ao?t 2019 ? 00:13, Philip Race a > ?crit : > >> +1 from me. Looks the same as the FX fix modulo some moving things around. >> >> -phil. >> >> On 7/29/19, 12:56 AM, Laurent Bourg?s wrote: >> > Hi, >> > >> > Please review this bug fix for the Marlin renderer (introduced in >> > JDK11.0.2): >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 >> > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ >> > >> > >> > This patch is very close to MarlinFX patch integrated last week in >> > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789 >> > >> > Changes: >> > - Stroker: fixed closePath() to preserve last position and its outcode >> > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to >> > preserve last position and its outcode >> > - Dasher: better precision handling (comparison float value with >> epsilon) >> > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to >> > avoid false positives on long stroked curves (quad / cubic) + lowered >> > thresholds >> > >> > Cheers, >> > Laurent >> > > > -- > -- > Laurent Bourg?s > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Tue Aug 6 23:30:33 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 6 Aug 2019 16:30:33 -0700 Subject: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region In-Reply-To: References: <5D4363FD.9000007@oracle.com> Message-ID: <5620184f-cf1a-fc1a-9ac9-74023c5a3a53@oracle.com> 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 > > a ?crit?: > > Thanks Philip, > > I am waiting for another approval, > Cheers, > Laurent > > Le?ven. 2 ao?t 2019 ??00:13, Philip Race > a ?crit?: > > +1 from me. Looks the same as the FX fix modulo some moving > things around. > > -phil. > > On 7/29/19, 12:56 AM, Laurent Bourg?s wrote: > > Hi, > > > > Please review this bug fix for the Marlin renderer > (introduced in > > JDK11.0.2): > > JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 > > webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ > > > > > > > This patch is very close to MarlinFX patch integrated last > week in > > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789 > > > > Changes: > > - Stroker: fixed closePath() to preserve last position and > its outcode > > - TransformingPathConsumer2D: fixed > PathClipFilter.closePath() to > > preserve last position and its outcode > > - Dasher: better precision handling (comparison float value > with epsilon) > > - ClipShapeTest: use preliminary curve subdivision (length > > 50px) to > > avoid false positives on long stroked curves (quad / cubic) > + lowered > > thresholds > > > > Cheers, > > Laurent > > > > -- > -- > Laurent Bourg?s > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Aug 7 08:37:13 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 7 Aug 2019 10:37:13 +0200 Subject: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region In-Reply-To: <5620184f-cf1a-fc1a-9ac9-74023c5a3a53@oracle.com> References: <5D4363FD.9000007@oracle.com> <5620184f-cf1a-fc1a-9ac9-74023c5a3a53@oracle.com> Message-ID: Kevin & Philip, Thank you for your reviews, I pushed the fix: http://hg.openjdk.java.net/jdk/client/rev/13178f7e75d5 Laurent Le mer. 7 ao?t 2019 ? 01:30, Kevin Rushforth a ?crit : > 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 > a ?crit : > >> Thanks Philip, >> >> I am waiting for another approval, >> Cheers, >> Laurent >> >> Le ven. 2 ao?t 2019 ? 00:13, Philip Race a >> ?crit : >> >>> +1 from me. Looks the same as the FX fix modulo some moving things >>> around. >>> >>> -phil. >>> >>> On 7/29/19, 12:56 AM, Laurent Bourg?s wrote: >>> > Hi, >>> > >>> > Please review this bug fix for the Marlin renderer (introduced in >>> > JDK11.0.2): >>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 >>> > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ >>> > >>> > >>> > This patch is very close to MarlinFX patch integrated last week in >>> > OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789 >>> > >>> > Changes: >>> > - Stroker: fixed closePath() to preserve last position and its outcode >>> > - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to >>> > preserve last position and its outcode >>> > - Dasher: better precision handling (comparison float value with >>> epsilon) >>> > - ClipShapeTest: use preliminary curve subdivision (length > 50px) to >>> > avoid false positives on long stroked curves (quad / cubic) + lowered >>> > thresholds >>> > >>> > Cheers, >>> > Laurent >>> >> >> >> -- >> -- >> Laurent Bourg?s >> > > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Aug 7 17:56:10 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 7 Aug 2019 10:56:10 -0700 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> <8437E201-1D13-442F-91E7-49CEC6E0E625@mathworks.com> Message-ID: Sergey, This fix seems OK to me. Can you please do whatever re-evaluation you meant as I'd like to pull it into jdk/client for Alexey (since he does not have current commit rights). -phil. On 3/8/18 2:59 PM, Sergey Bylokhov wrote: > Hi, Bill. > Thank you for confirmation. > > On 08/03/2018 14:08, Bill York wrote: >> 3. Is there a plan to get this bug fix into the JRE distributed by >> Oracle? > > I will reevaluate the fix for inclusion in jdk11. > > From sergey.bylokhov at oracle.com Thu Aug 8 16:29:06 2019 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 8 Aug 2019 09:29:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS Message-ID: <1c774110-8d09-4005-8e25-cce3c46bb6ed@default> I am looking into it. ----- philip.race at oracle.com wrote: > Sergey, > > This fix seems OK to me. Can you please do whatever re-evaluation you > meant > as I'd like to pull it into jdk/client for Alexey (since he does not > have current commit rights). > > -phil. > > On 3/8/18 2:59 PM, Sergey Bylokhov wrote: > > Hi, Bill. > > Thank you for confirmation. > > > > On 08/03/2018 14:08, Bill York wrote: > >> 3. Is there a plan to get this bug fix into the JRE distributed by > > >> Oracle? > > > > I will reevaluate the fix for inclusion in jdk11. > > > > From Sergey.Bylokhov at oracle.com Mon Aug 12 09:29:46 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 12 Aug 2019 02:29:46 -0700 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> <8437E201-1D13-442F-91E7-49CEC6E0E625@mathworks.com> Message-ID: <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> Hi, Phil, Alexey. I recheck this bug, and here is some of my thought: 1. We have two java classes: - GLX/CGL/WGL/GraphicsConfig which maintain the native structure WGL/GLX/CGL/GraphicsConfigInfo - GLX/CGL/WGL/SurfaceData which maintain the native structure CGL/GLXS/WGL/SDOps 2. The native structures should be disposed of by the "Disposer" machinery 3. The native part XXXSDOps has a pointer to the CGL/GraphicsConfigInfo 4. To prevent the usage of dangling pointer to the XXXGraphicsConfigInfo, the java part of XXXSDOps has a strong reference to the java part of XXXGraphicsConfigInfo The assumption at point 4 is not correct, it is possible that the native part of the XXXGraphicsConfigInfo could be disposed before XXXSDOps, and we will get a crash when we will try to dispose the XXXSDOps. Long time ago when it was implemented it works fine, because we never dispose the graphics configs, we read them on-start and use till the end of the application, even now we use this approach on Linux(JDK-8076313). So this bug existed on Linux, Windows and migrated to the macOS platform, but only on macOS and windows we can get a crash. I have rechecked the usage of the pointer from XXXSDOps to XXXGraphicsConfigInfo which caused a crash and think that we can get rid it, but it will required to change bunch of code on all platforms, so as a minimal fix I suggest this one: http://cr.openjdk.java.net/~serb/8146238/webrev.00 Just to store the reference to the GC till the moment it will not be used by the SurfaceData. On 8/7/19 10:56 am, Phil Race wrote: > Sergey, > > This fix seems OK to me. Can you please do whatever re-evaluation you meant > as I'd like to pull it into jdk/client for Alexey (since he does not have current commit rights). > > -phil. > > On 3/8/18 2:59 PM, Sergey Bylokhov wrote: >> Hi, Bill. >> Thank you for confirmation. >> >> On 08/03/2018 14:08, Bill York wrote: >>> 3. Is there a plan to get this bug fix into the JRE distributed by Oracle? >> >> I will reevaluate the fix for inclusion in jdk11. >> >> > -- Best regards, Sergey. From matthias.baesken at sap.com Mon Aug 12 12:36:58 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 12 Aug 2019 12:36:58 +0000 Subject: [OpenJDK 2D-Dev] FW: RFR [XS] 8229023: make java/awt/print/PrinterJob/SameService.java Windows-only , was : question regarding test java/awt/PrinterJob/SameService.java (tests that print services are not re-created) Message-ID: Forwarding to 2d-dev because this might be the better list for this issue .... ----------------------------------------- Hello, please review the following small test adjustment . It makes the test java/awt/print/PrinterJob/SameService.java Windows-only. Reason is that in some cases the print service is recreated on Linux . ( we observed this in ~ 30 % of test runs on one of our test machines ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8229023 http://cr.openjdk.java.net/~mbaesken/webrevs/8229023.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Aug 15 00:22:06 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Aug 2019 17:22:06 -0700 Subject: [OpenJDK 2D-Dev] FW: RFR [XS] 8229023: make java/awt/print/PrinterJob/SameService.java Windows-only , was : question regarding test java/awt/PrinterJob/SameService.java (tests that print services are not re-created) In-Reply-To: References: Message-ID: Hi, Matthias. Did you check what is the root cause of the problem? Why the new service sometimes recreated? It seems that in the code we tried to cache them per appcontext in the PrintServiceLookup.getAllLookupServices(), no? It sounds like JDK-6446094, but this time on Linux, by the way, what about macOS? On 8/12/19 5:36 am, Baesken, Matthias wrote: > Forwarding to 2d-dev because? this might be the ?better list for this issue ?. > > ----------------------------------------- > > Hello,? please review the following small? test adjustment . > > It makes the?? test? ?java/awt/print/PrinterJob/SameService.java?? Windows-only. > > Reason is that in some cases the print service? is recreated on Linux . > > ( we observed this in ~ 30 % of test runs on one of our test machines ) > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8229023 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229023.0/ > > Thanks, Matthias > -- Best regards, Sergey. From matthias.baesken at sap.com Thu Aug 15 06:45:22 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 15 Aug 2019 06:45:22 +0000 Subject: [OpenJDK 2D-Dev] FW: RFR [XS] 8229023: make java/awt/print/PrinterJob/SameService.java Windows-only , was : question regarding test java/awt/PrinterJob/SameService.java (tests that print services are not re-created) In-Reply-To: References: Message-ID: Hi Sergey, we only observed the recreation issue on Linux . It might be some kind of race there (showed up only a few times ). We've never seen it on MacOSX . So far , I do not know very much about why it occurred . Best regards, Matthias > > Hi, Matthias. > > Did you check what is the root cause of the problem? Why the new service > sometimes recreated? > It seems that in the code we tried to cache them per appcontext in the > PrintServiceLookup.getAllLookupServices(), no? > > It sounds like JDK-6446094, but this time on Linux, by the way, what about > macOS? > > > On 8/12/19 5:36 am, Baesken, Matthias wrote: > > Forwarding to 2d-dev because? this might be the ?better list for this issue .. > > > > ----------------------------------------- > > > > Hello,? please review the following small? test adjustment . > > > > It makes > the?? test? ?java/awt/print/PrinterJob/SameService.java?? Windows-only. > > > > Reason is that in some cases the print service? is recreated on Linux . > > > > ( we observed this in ~ 30 % of test runs on one of our test machines ) > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8229023 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229023.0/ > > > > Thanks, Matthias > > > > > -- > Best regards, Sergey. From alexey.ivanov at oracle.com Fri Aug 16 12:23:34 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 16 Aug 2019 13:23:34 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: <178f2ca9-ea7d-b170-da36-e73966400a6a@oracle.com> References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> <5D1BE51D.9050202@oracle.com> <178f2ca9-ea7d-b170-da36-e73966400a6a@oracle.com> Message-ID: Hi Phil, Sergey, Do you have any other comments? The latest webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ Does anybody have any additional comments? I looked through the code once again, and I think there should be no null values in the array returned by getPrinterNames() unless ::EnumPrinters could return null printer names. The documentation for EnumPrinters [1] and for PRINTER_INFO_4 [2] does not mention if pPrinterName can be null or not. Anyway the custom comparator does handle null values in the printer list if there are any. Regards, Alexey [1] https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters [2] https://docs.microsoft.com/en-us/windows/win32/printdocs/printer-info-4 On 03/07/2019 19:46, Alexey Ivanov wrote: > Hi Phil, > > Thank you for your review! That's a valid point! > > Please see the updated webrev: > http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ > > I implemented a custom comparator which handles null values in the > printer list. > > However, I wonder if the list of printers can ever contain a null > value. The method refreshServices() does not check if printers[p] is > null. > > On 03/07/2019 00:13, Philip Race wrote: >> I thought we had the checks for null in doCompare there for a reason. >> Arrays.sort won't be very happy with a null element. >> >> You said in the first review email of the v0 webrev : >> >> > Arrays.equals() accepts null parameters and null elements in the >> arrays and always returns the correct result. >> >> but that webrev didn't use Arrays.sort and that requirement seems to >> have been forgotten >> when adding it. >> >> ?public class Sort { >> ? public static void main(String[] args) { >> ??? String[] a1 = { "a", null, "a" }; >> ??? java.util.Arrays.sort(a1); >> ? } >> } >> >> java Sort >> Exception in thread "main" java.lang.NullPointerException >> ??? at >> java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:320) >> ??? at java.util.ComparableTimSort.sort(ComparableTimSort.java:188) >> ??? at java.util.Arrays.sort(Arrays.java:1246) >> ??? at Sort.main(Sort.java:4) >> >> >> -phil. From philip.race at oracle.com Fri Aug 16 19:34:41 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 16 Aug 2019 12:34:41 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> <5D1BE51D.9050202@oracle.com> <178f2ca9-ea7d-b170-da36-e73966400a6a@oracle.com> Message-ID: Approved. -phil. On 8/16/19 5:23 AM, Alexey Ivanov wrote: > Hi Phil, Sergey, > > Do you have any other comments? > The latest webrev: > http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ > > Does anybody have any additional comments? > > > I looked through the code once again, and I think there should be no > null values in the array returned by getPrinterNames() unless > ::EnumPrinters could return null printer names. The documentation for > EnumPrinters [1] and for PRINTER_INFO_4 [2] does not mention if > pPrinterName can be null or not. > > Anyway the custom comparator does handle null values in the printer > list if there are any. > > Regards, > Alexey > > [1] https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters > [2] > https://docs.microsoft.com/en-us/windows/win32/printdocs/printer-info-4 > > On 03/07/2019 19:46, Alexey Ivanov wrote: >> Hi Phil, >> >> Thank you for your review! That's a valid point! >> >> Please see the updated webrev: >> http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ >> >> I implemented a custom comparator which handles null values in the >> printer list. >> >> However, I wonder if the list of printers can ever contain a null >> value. The method refreshServices() does not check if printers[p] is >> null. >> >> On 03/07/2019 00:13, Philip Race wrote: >>> I thought we had the checks for null in doCompare there for a reason. >>> Arrays.sort won't be very happy with a null element. >>> >>> You said in the first review email of the v0 webrev : >>> >>> > Arrays.equals() accepts null parameters and null elements in the >>> arrays and always returns the correct result. >>> >>> but that webrev didn't use Arrays.sort and that requirement seems to >>> have been forgotten >>> when adding it. >>> >>> ?public class Sort { >>> ? public static void main(String[] args) { >>> ??? String[] a1 = { "a", null, "a" }; >>> ??? java.util.Arrays.sort(a1); >>> ? } >>> } >>> >>> java Sort >>> Exception in thread "main" java.lang.NullPointerException >>> ??? at >>> java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:320) >>> ??? at java.util.ComparableTimSort.sort(ComparableTimSort.java:188) >>> ??? at java.util.Arrays.sort(Arrays.java:1246) >>> ??? at Sort.main(Sort.java:4) >>> >>> >>> -phil. > From Sergey.Bylokhov at oracle.com Fri Aug 16 22:18:42 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 16 Aug 2019 15:18:42 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> <5D1BE51D.9050202@oracle.com> <178f2ca9-ea7d-b170-da36-e73966400a6a@oracle.com> Message-ID: +1 On 8/16/19 12:34 pm, Phil Race wrote: > Approved. > > -phil. > > On 8/16/19 5:23 AM, Alexey Ivanov wrote: >> Hi Phil, Sergey, >> >> Do you have any other comments? >> The latest webrev: >> http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ >> >> Does anybody have any additional comments? >> >> >> I looked through the code once again, and I think there should be no null values in the array returned by getPrinterNames() unless ::EnumPrinters could return null printer names. The documentation for EnumPrinters [1] and for PRINTER_INFO_4 [2] does not mention if pPrinterName can be null or not. >> >> Anyway the custom comparator does handle null values in the printer list if there are any. >> >> Regards, >> Alexey >> >> [1] https://docs.microsoft.com/en-us/windows/win32/printdocs/enumprinters >> [2] https://docs.microsoft.com/en-us/windows/win32/printdocs/printer-info-4 >> >> On 03/07/2019 19:46, Alexey Ivanov wrote: >>> Hi Phil, >>> >>> Thank you for your review! That's a valid point! >>> >>> Please see the updated webrev: >>> http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ >>> >>> I implemented a custom comparator which handles null values in the printer list. >>> >>> However, I wonder if the list of printers can ever contain a null value. The method refreshServices() does not check if printers[p] is null. >>> >>> On 03/07/2019 00:13, Philip Race wrote: >>>> I thought we had the checks for null in doCompare there for a reason. >>>> Arrays.sort won't be very happy with a null element. >>>> >>>> You said in the first review email of the v0 webrev : >>>> >>>> > Arrays.equals() accepts null parameters and null elements in the arrays and always returns the correct result. >>>> >>>> but that webrev didn't use Arrays.sort and that requirement seems to have been forgotten >>>> when adding it. >>>> >>>> ?public class Sort { >>>> ? public static void main(String[] args) { >>>> ??? String[] a1 = { "a", null, "a" }; >>>> ??? java.util.Arrays.sort(a1); >>>> ? } >>>> } >>>> >>>> java Sort >>>> Exception in thread "main" java.lang.NullPointerException >>>> ??? at java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:320) >>>> ??? at java.util.ComparableTimSort.sort(ComparableTimSort.java:188) >>>> ??? at java.util.Arrays.sort(Arrays.java:1246) >>>> ??? at Sort.main(Sort.java:4) >>>> >>>> >>>> -phil. >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Aug 19 19:03:15 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 19 Aug 2019 12:03:15 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8229810 NullPointerException getting bounds of GraphicsConfiguration Message-ID: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8229810 Fix: http://cr.openjdk.java.net/~serb/8229810/webrev.00 The root cause is a lack of synchronization in CGraphicsEnvironment, we create the GraphicsDevice under a special lock which is used to access the list of devices: http://hg.openjdk.java.net/jdk/client/file/39f133168348/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#l184 but initialize the device w/o this lock. http://hg.openjdk.java.net/jdk/client/file/39f133168348/src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java#l187 So it is possible that we create the device, add it to the list of devices, and before we initialize it the user could access the not fully initialized object. The bug exists from the jdk7, but it was hidden because all fields in CGraphicsDevice were primitives, so the app just used invalid data. In JDK-8211992 the object field "bounds" was added and now we can get NPE if this field was not initialized. As a fix, I suggest to always initialize the graphics device in the constructor. Note that we cannot move "displayChanged" which will notify devices and all listeners in awt/swing in the CGraphicsEnvironment under the lock, it will cause various deadlocks in the a different listeners. -- Best regards, Sergey. From philip.race at oracle.com Thu Aug 22 16:55:01 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 22 Aug 2019 09:55:01 -0700 Subject: [OpenJDK 2D-Dev] Project Lanai (Was Metal Rendering Pipeline for macOS) Message-ID: <2245fafb-539b-53fe-212c-e33d0c1c27fc@oracle.com> All, I expect most of you know but the work that has been going on in a branch of the OpenJDK sandbox to prototype a Java2D metal rendering pipeline for macOS now is its own OpenJDK project called "Lanai". The vote and the result were announced here : https://mail.openjdk.java.net/pipermail/announce/2019-July/thread.html And the project now has its own mailing list which we will use for future metal discussions : https://mail.openjdk.java.net/pipermail/lanai-dev/2019-August/thread.html Please subscribe to that list if you wish to follow metal discussions. The first email there provides pointers to the project page, wiki, and repo. And as you can see from the second mail on that list, the contents of the sandbox were pushed to the new project repo and so the sandbox branch "metal-prototype-branch" is now considered "closed" - and will actually be closed imminently. -phil. From philip.race at oracle.com Fri Aug 23 18:46:48 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 23 Aug 2019 11:46:48 -0700 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> <8437E201-1D13-442F-91E7-49CEC6E0E625@mathworks.com> <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> Message-ID: The fix creates a new JNI GlobalRef pointing to the GraphicsConfig That is then explicitly released in the dispose method of the SurfaceData called when it is collected. The dispose method also then frees the native component now that we are truly done with it So the risk here is that I have been trying to look for is to be sure that we don't have any reference back to the SurfaceData from the GraphicsConfig since it would never get collected in such a case. So far I think we are safe. Did you also check for this ? I have built and tested this doing add/remove monitors, sleep/wake, switch users and no crashes as yet. -phil. On 8/12/19 2:29 AM, Sergey Bylokhov wrote: > Hi, Phil, Alexey. > > I recheck this bug, and here is some of my thought: > ?1. We have two java classes: > ??? - GLX/CGL/WGL/GraphicsConfig which maintain the native structure > WGL/GLX/CGL/GraphicsConfigInfo > ??? - GLX/CGL/WGL/SurfaceData which maintain the native structure > CGL/GLXS/WGL/SDOps > ?2. The native structures should be disposed of by the "Disposer" > machinery > ?3. The native part XXXSDOps has a pointer to the CGL/GraphicsConfigInfo > ?4. To prevent the usage of dangling pointer to the > XXXGraphicsConfigInfo, the java part of XXXSDOps has a strong > reference to the java part of XXXGraphicsConfigInfo > > The assumption at point 4 is not correct, it is possible that the > native part of the XXXGraphicsConfigInfo could be disposed before > XXXSDOps, and we will get a crash when we will try to dispose the > XXXSDOps. > > Long time ago when it was implemented it works fine, because we never > dispose the graphics configs, we read them on-start and use till the > end of the application, even now we use this approach on > Linux(JDK-8076313). > > So this bug existed on Linux, Windows and migrated to the macOS > platform, but only on macOS and windows we can get a crash. > > > I have rechecked the usage of the pointer from XXXSDOps to > XXXGraphicsConfigInfo which caused a crash and think that we can get > rid it, but it will required to change bunch of code on all platforms, > so as a minimal fix I suggest this one: > http://cr.openjdk.java.net/~serb/8146238/webrev.00 > Just to store the reference to the GC till the moment it will not be > used by the SurfaceData. > > > On 8/7/19 10:56 am, Phil Race wrote: >> Sergey, >> >> This fix seems OK to me. Can you please do whatever re-evaluation you >> meant >> as I'd like to pull it into jdk/client for Alexey (since he does not >> have current commit rights). >> >> -phil. >> >> On 3/8/18 2:59 PM, Sergey Bylokhov wrote: >>> Hi, Bill. >>> Thank you for confirmation. >>> >>> On 08/03/2018 14:08, Bill York wrote: >>>> 3. Is there a plan to get this bug fix into the JRE distributed by >>>> Oracle? >>> >>> I will reevaluate the fix for inclusion in jdk11. >>> >>> >> > > From alexey.ushakov at jetbrains.com Sat Aug 24 12:09:51 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Sat, 24 Aug 2019 15:09:51 +0300 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> <8437E201-1D13-442F-91E7-49CEC6E0E625@mathworks.com> <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> Message-ID: <510F56E6-0178-4C60-A38F-063124EBDCDB@jetbrains.com> Hi Sergey, The proposed solution looks good for me. Best Regards, Alexey > On 12 Aug 2019, at 12:29, Sergey Bylokhov wrote: > > Hi, Phil, Alexey. > > I recheck this bug, and here is some of my thought: > 1. We have two java classes: > - GLX/CGL/WGL/GraphicsConfig which maintain the native structure WGL/GLX/CGL/GraphicsConfigInfo > - GLX/CGL/WGL/SurfaceData which maintain the native structure CGL/GLXS/WGL/SDOps > 2. The native structures should be disposed of by the "Disposer" machinery > 3. The native part XXXSDOps has a pointer to the CGL/GraphicsConfigInfo > 4. To prevent the usage of dangling pointer to the XXXGraphicsConfigInfo, the java part of XXXSDOps has a strong reference to the java part of XXXGraphicsConfigInfo > > The assumption at point 4 is not correct, it is possible that the native part of the XXXGraphicsConfigInfo could be disposed before XXXSDOps, and we will get a crash when we will try to dispose the XXXSDOps. > > Long time ago when it was implemented it works fine, because we never dispose the graphics configs, we read them on-start and use till the end of the application, even now we use this approach on Linux(JDK-8076313). > > So this bug existed on Linux, Windows and migrated to the macOS platform, but only on macOS and windows we can get a crash. > > > I have rechecked the usage of the pointer from XXXSDOps to XXXGraphicsConfigInfo which caused a crash and think that we can get rid it, but it will required to change bunch of code on all platforms, so as a minimal fix I suggest this one: > http://cr.openjdk.java.net/~serb/8146238/webrev.00 > Just to store the reference to the GC till the moment it will not be used by the SurfaceData. > > > On 8/7/19 10:56 am, Phil Race wrote: >> Sergey, >> This fix seems OK to me. Can you please do whatever re-evaluation you meant >> as I'd like to pull it into jdk/client for Alexey (since he does not have current commit rights). >> -phil. >> On 3/8/18 2:59 PM, Sergey Bylokhov wrote: >>> Hi, Bill. >>> Thank you for confirmation. >>> >>> On 08/03/2018 14:08, Bill York wrote: >>>> 3. Is there a plan to get this bug fix into the JRE distributed by Oracle? >>> >>> I will reevaluate the fix for inclusion in jdk11. >>> >>> > > > -- > Best regards, Sergey. From philip.race at oracle.com Sat Aug 24 17:27:22 2019 From: philip.race at oracle.com (Phil Race) Date: Sat, 24 Aug 2019 10:27:22 -0700 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: <510F56E6-0178-4C60-A38F-063124EBDCDB@jetbrains.com> References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> <8437E201-1D13-442F-91E7-49CEC6E0E625@mathworks.com> <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> <510F56E6-0178-4C60-A38F-063124EBDCDB@jetbrains.com> Message-ID: Sergey, Since you proposed this version of the fix, do you want to push it ? -phil. On 8/24/19 5:09 AM, Alexey Ushakov wrote: > Hi Sergey, > > The proposed solution looks good for me. > > Best Regards, > Alexey > > >> On 12 Aug 2019, at 12:29, Sergey Bylokhov wrote: >> >> Hi, Phil, Alexey. >> >> I recheck this bug, and here is some of my thought: >> 1. We have two java classes: >> - GLX/CGL/WGL/GraphicsConfig which maintain the native structure WGL/GLX/CGL/GraphicsConfigInfo >> - GLX/CGL/WGL/SurfaceData which maintain the native structure CGL/GLXS/WGL/SDOps >> 2. The native structures should be disposed of by the "Disposer" machinery >> 3. The native part XXXSDOps has a pointer to the CGL/GraphicsConfigInfo >> 4. To prevent the usage of dangling pointer to the XXXGraphicsConfigInfo, the java part of XXXSDOps has a strong reference to the java part of XXXGraphicsConfigInfo >> >> The assumption at point 4 is not correct, it is possible that the native part of the XXXGraphicsConfigInfo could be disposed before XXXSDOps, and we will get a crash when we will try to dispose the XXXSDOps. >> >> Long time ago when it was implemented it works fine, because we never dispose the graphics configs, we read them on-start and use till the end of the application, even now we use this approach on Linux(JDK-8076313). >> >> So this bug existed on Linux, Windows and migrated to the macOS platform, but only on macOS and windows we can get a crash. >> >> >> I have rechecked the usage of the pointer from XXXSDOps to XXXGraphicsConfigInfo which caused a crash and think that we can get rid it, but it will required to change bunch of code on all platforms, so as a minimal fix I suggest this one: >> http://cr.openjdk.java.net/~serb/8146238/webrev.00 >> Just to store the reference to the GC till the moment it will not be used by the SurfaceData. >> >> >> On 8/7/19 10:56 am, Phil Race wrote: >>> Sergey, >>> This fix seems OK to me. Can you please do whatever re-evaluation you meant >>> as I'd like to pull it into jdk/client for Alexey (since he does not have current commit rights). >>> -phil. >>> On 3/8/18 2:59 PM, Sergey Bylokhov wrote: >>>> Hi, Bill. >>>> Thank you for confirmation. >>>> >>>> On 08/03/2018 14:08, Bill York wrote: >>>>> 3. Is there a plan to get this bug fix into the JRE distributed by Oracle? >>>> I will reevaluate the fix for inclusion in jdk11. >>>> >>>> >> >> -- >> Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Aug 24 22:22:17 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sat, 24 Aug 2019 15:22:17 -0700 Subject: [OpenJDK 2D-Dev] bug 8146238 - Java Queue Flusher on MacOS In-Reply-To: References: <1EE971F1-5C0B-4C31-9B22-571258989BD0@contoso.com> <3d6e6a58-6665-ad20-47f3-63152be52852@oracle.com> <87619E58-AB61-47E8-9E2F-89D92AB8BD61@mathworks.com> <2254817D-1678-431E-BBDB-B0657CBDC7E6@jetbrains.com> <8437E201-1D13-442F-91E7-49CEC6E0E625@mathworks.com> <183e0d75-3aa3-7ca6-bae5-60f489ac2e7c@oracle.com> <510F56E6-0178-4C60-A38F-063124EBDCDB@jetbrains.com> Message-ID: I'll push it soon On 8/24/19 10:27 am, Phil Race wrote: > Sergey, > > Since you proposed this version of the fix, do you want to push it ? > > -phil. > > > On 8/24/19 5:09 AM, Alexey Ushakov wrote: >> Hi Sergey, >> >> The proposed solution looks good for me. >> >> Best Regards, >> Alexey >> >> >>> On 12 Aug 2019, at 12:29, Sergey Bylokhov wrote: >>> >>> Hi, Phil, Alexey. >>> >>> I recheck this bug, and here is some of my thought: >>> 1. We have two java classes: >>> ??? - GLX/CGL/WGL/GraphicsConfig which maintain the native structure WGL/GLX/CGL/GraphicsConfigInfo >>> ??? - GLX/CGL/WGL/SurfaceData which maintain the native structure CGL/GLXS/WGL/SDOps >>> 2. The native structures should be disposed of by the "Disposer" machinery >>> 3. The native part XXXSDOps has a pointer to the CGL/GraphicsConfigInfo >>> 4. To prevent the usage of dangling pointer to the XXXGraphicsConfigInfo, the java part of XXXSDOps has a strong reference to the java part of XXXGraphicsConfigInfo >>> >>> The assumption at point 4 is not correct, it is possible that the native part of the XXXGraphicsConfigInfo could be disposed before XXXSDOps, and we will get a crash when we will try to dispose the XXXSDOps. >>> >>> Long time ago when it was implemented it works fine, because we never dispose the graphics configs, we read them on-start and use till the end of the application, even now we use this approach on Linux(JDK-8076313). >>> >>> So this bug existed on Linux, Windows and migrated to the macOS platform, but only on macOS and windows we can get a crash. >>> >>> >>> I have rechecked the usage of the pointer from XXXSDOps to XXXGraphicsConfigInfo which caused a crash and think that we can get rid it, but it will required to change bunch of code on all platforms, so as a minimal fix I suggest this one: >>> http://cr.openjdk.java.net/~serb/8146238/webrev.00 >>> Just to store the reference to the GC till the moment it will not be used by the SurfaceData. >>> >>> >>> On 8/7/19 10:56 am, Phil Race wrote: >>>> Sergey, >>>> This fix seems OK to me. Can you please do whatever re-evaluation you meant >>>> as I'd like to pull it into jdk/client for Alexey (since he does not have current commit rights). >>>> -phil. >>>> On 3/8/18 2:59 PM, Sergey Bylokhov wrote: >>>>> Hi, Bill. >>>>> Thank you for confirmation. >>>>> >>>>> On 08/03/2018 14:08, Bill York wrote: >>>>>> 3. Is there a plan to get this bug fix into the JRE distributed by Oracle? >>>>> I will reevaluate the fix for inclusion in jdk11. >>>>> >>>>> >>> >>> -- >>> Best regards, Sergey. > -- Best regards, Sergey. From philip.race at oracle.com Tue Aug 27 15:57:42 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 27 Aug 2019 08:57:42 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8229800 : WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll Message-ID: <9d0ebaf8-8689-de39-e9ff-f5d3eda1d478@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8229800 webrev : http://cr.openjdk.java.net/~prr/8229800/ Since JDK 9, awt.dll has linked against d2d1.dll - a Direct2D library - in order to call a method to get the screen dpi on Windows 7 and earlier. It appears that Windows Core Server used to include this library but recent versions do not. As a result an app that loads AWT - even in headless mode - is DOA with an unsatisfied link on start up and no work around is possible. Windows Core Server is meant to be used for server applications and the use case here is just that but the hard compile time dependency on d2d1.dll means that even if this code isn't reached, used, or needed the app is still DOA. There may be other ways to get the screen DPI on Windows - I don't know why the hidpi support chose this approach - but the safest change appears to be to dynamically locate this library at run time. The callers of the internal GetScreenDpi function are already prepared for it to "fail" and fall back to a default of 96 DPI. I have implemented this approach and verified it on Window 7 - which is where it is needed. A regression test is difficult since setting values like -Dsun.java2d.uiScale mean we over-ride and don't request this setting and 96 dpi is the fallback so you could only test this as part of overall true hidpi testing. And the focus of this bug - the absence of a hard link against d2d1.dll and whether overall headless works is best tested by running any headless app on Windows Core Server. One wrinkle in the code is that the lookup of the function name needs to use the "C" binding so the signature is adjusted to match that. The bug is marked tck-red because of the DOA, but the proposal is to just document that for JDK 13 GA this configuration isn't supported and get the fix first into JDK 14 and then backport to 13.0.1 which gives us a bit more time to verify the fix. It seems unlikely that this configuration is critical for immediate adoption of 13 since it has taken 11 months for this issue to be reported. -phil. From jayathirth.d.v at oracle.com Tue Aug 27 17:34:24 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Tue, 27 Aug 2019 23:04:24 +0530 Subject: [OpenJDK 2D-Dev] RFR: 8229800 : WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll In-Reply-To: <9d0ebaf8-8689-de39-e9ff-f5d3eda1d478@oracle.com> References: <9d0ebaf8-8689-de39-e9ff-f5d3eda1d478@oracle.com> Message-ID: <1202A6EE-FEB8-497A-9041-088895BF840A@oracle.com> Hi Phil, I went through the changes and I see that we are doing similar dynamic loading of d2d1.dll as we are doing for shcore.dll and loading code looks good. Also I confirmed that among the overloaded functions of D2D1CreateFactory, the one with 4 arguments is the generic one. I have not verified build and logic by importing the code, but overall change looks good to me. Thanks, Jay > On 27-Aug-2019, at 9:27 PM, Phil Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8229800 > webrev : http://cr.openjdk.java.net/~prr/8229800/ > > Since JDK 9, awt.dll has linked against d2d1.dll - a Direct2D library - in order to > call a method to get the screen dpi on Windows 7 and earlier. > > It appears that Windows Core Server used to include this library but recent > versions do not. > > As a result an app that loads AWT - even in headless mode - is DOA with > an unsatisfied link on start up and no work around is possible. > > Windows Core Server is meant to be used for server applications and > the use case here is just that but the hard compile time dependency > on d2d1.dll means that even if this code isn't reached, used, or needed > the app is still DOA. > > There may be other ways to get the screen DPI on Windows - I don't know > why the hidpi support chose this approach - but the safest change appears > to be to dynamically locate this library at run time. > > The callers of the internal GetScreenDpi function are already prepared > for it to "fail" and fall back to a default of 96 DPI. > > I have implemented this approach and verified it on Window 7 - which > is where it is needed. A regression test is difficult since setting values > like -Dsun.java2d.uiScale mean we over-ride and don't request this > setting and 96 dpi is the fallback so you could only test this as part > of overall true hidpi testing. And the focus of this bug - the absence > of a hard link against d2d1.dll and whether overall headless works > is best tested by running any headless app on Windows Core Server. > > One wrinkle in the code is that the lookup of the function name > needs to use the "C" binding so the signature is adjusted to match that. > > The bug is marked tck-red because of the DOA, but the proposal > is to just document that for JDK 13 GA this configuration isn't supported > and get the fix first into JDK 14 and then backport to 13.0.1 which gives > us a bit more time to verify the fix. It seems unlikely that this configuration > is critical for immediate adoption of 13 since it has taken 11 months for > this issue to be reported. > > -phil. > > > From Sergey.Bylokhov at oracle.com Wed Aug 28 02:56:18 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 27 Aug 2019 19:56:18 -0700 Subject: [OpenJDK 2D-Dev] RFR: 8229800 : WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll In-Reply-To: <1202A6EE-FEB8-497A-9041-088895BF840A@oracle.com> References: <9d0ebaf8-8689-de39-e9ff-f5d3eda1d478@oracle.com> <1202A6EE-FEB8-497A-9041-088895BF840A@oracle.com> Message-ID: +1 On 8/27/19 10:34 am, Jayathirth Rao wrote: > Hi Phil, > > I went through the changes and I see that we are doing similar dynamic loading of d2d1.dll as we are doing for shcore.dll and loading code looks good. > Also I confirmed that among the overloaded functions of D2D1CreateFactory, the one with 4 arguments is the generic one. > > I have not verified build and logic by importing the code, but overall change looks good to me. > > Thanks, > Jay > >> On 27-Aug-2019, at 9:27 PM, Phil Race wrote: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8229800 >> webrev : http://cr.openjdk.java.net/~prr/8229800/ >> >> Since JDK 9, awt.dll has linked against d2d1.dll - a Direct2D library - in order to >> call a method to get the screen dpi on Windows 7 and earlier. >> >> It appears that Windows Core Server used to include this library but recent >> versions do not. >> >> As a result an app that loads AWT - even in headless mode - is DOA with >> an unsatisfied link on start up and no work around is possible. >> >> Windows Core Server is meant to be used for server applications and >> the use case here is just that but the hard compile time dependency >> on d2d1.dll means that even if this code isn't reached, used, or needed >> the app is still DOA. >> >> There may be other ways to get the screen DPI on Windows - I don't know >> why the hidpi support chose this approach - but the safest change appears >> to be to dynamically locate this library at run time. >> >> The callers of the internal GetScreenDpi function are already prepared >> for it to "fail" and fall back to a default of 96 DPI. >> >> I have implemented this approach and verified it on Window 7 - which >> is where it is needed. A regression test is difficult since setting values >> like -Dsun.java2d.uiScale mean we over-ride and don't request this >> setting and 96 dpi is the fallback so you could only test this as part >> of overall true hidpi testing. And the focus of this bug - the absence >> of a hard link against d2d1.dll and whether overall headless works >> is best tested by running any headless app on Windows Core Server. >> >> One wrinkle in the code is that the lookup of the function name >> needs to use the "C" binding so the signature is adjusted to match that. >> >> The bug is marked tck-red because of the DOA, but the proposal >> is to just document that for JDK 13 GA this configuration isn't supported >> and get the fix first into JDK 14 and then backport to 13.0.1 which gives >> us a bit more time to verify the fix. It seems unlikely that this configuration >> is critical for immediate adoption of 13 since it has taken 11 months for >> this issue to be reported. >> >> -phil. >> >> >> > -- Best regards, Sergey. From alexey.ivanov at oracle.com Wed Aug 28 12:33:11 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 28 Aug 2019 13:33:11 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8229800 : WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll In-Reply-To: References: <9d0ebaf8-8689-de39-e9ff-f5d3eda1d478@oracle.com> <1202A6EE-FEB8-497A-9041-088895BF840A@oracle.com> Message-ID: Looks good to me too. Regards, Alexey On 28/08/2019 03:56, Sergey Bylokhov wrote: > +1 > > On 8/27/19 10:34 am, Jayathirth Rao wrote: >> Hi Phil, >> >> I went through the changes and I see that we are doing similar >> dynamic loading of d2d1.dll as we are doing for shcore.dll and >> loading code looks good. >> Also I confirmed that among the overloaded functions of >> D2D1CreateFactory, the one with 4 arguments is the generic one. >> >> I have not verified build and logic by importing the code, but >> overall change looks good to me. >> >> Thanks, >> Jay >> >>> On 27-Aug-2019, at 9:27 PM, Phil Race wrote: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8229800 >>> webrev : http://cr.openjdk.java.net/~prr/8229800/ >>> >>> Since JDK 9, awt.dll has linked against d2d1.dll - a Direct2D >>> library - in order to >>> call a method to get the screen dpi on Windows 7 and earlier. >>> >>> It appears that Windows Core Server used to include this library but >>> recent >>> versions do not. >>> >>> As a result an app that loads AWT - even in headless mode - is DOA with >>> an unsatisfied link on start up and no work around is possible. >>> >>> Windows Core Server is meant to be used for server applications and >>> the use case here is just that but the hard compile time dependency >>> on d2d1.dll means that even if this code isn't reached, used, or needed >>> the app is still DOA. >>> >>> There may be other ways to get the screen DPI on Windows - I don't know >>> why the hidpi support chose this approach - but the safest change >>> appears >>> to be to dynamically locate this library at run time. >>> >>> The callers of the internal GetScreenDpi function are already prepared >>> for it to "fail" and fall back to a default of 96 DPI. >>> >>> I have implemented this approach and verified it on Window 7 - which >>> is where it is needed. A regression test is difficult since setting >>> values >>> like -Dsun.java2d.uiScale mean we over-ride and don't request this >>> setting and 96 dpi is the fallback so you could only test this as part >>> of overall true hidpi testing. And the focus of this bug - the absence >>> of a hard link against d2d1.dll and whether overall headless works >>> is best tested by running any headless app on Windows Core Server. >>> >>> One wrinkle in the code is that the lookup of the function name >>> needs to use the "C" binding so the signature is adjusted to match >>> that. >>> >>> The bug is marked tck-red because of the DOA, but the proposal >>> is to just document that for JDK 13 GA this configuration isn't >>> supported >>> and get the fix first into JDK 14 and then backport to 13.0.1 which >>> gives >>> us a bit more time to verify the fix. It seems unlikely that this >>> configuration >>> is critical for immediate adoption of 13 since it has taken 11 >>> months for >>> this issue to be reported. >>> >>> -phil. From dmitry.batrak at jetbrains.com Thu Aug 29 10:58:13 2019 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Thu, 29 Aug 2019 13:58:13 +0300 Subject: [OpenJDK 2D-Dev] [PATCH] 8210058: Algorithmic Italic font leans opposite angle in Printing Message-ID: Hello, I'd like to submit a patch for JDK-8210058. I'm not a Committer, so I'll need someone to sponsor this change. The issue is related to the implementation of algorithmic italics in FreeType font scaler. At the moment it uses FT_GlyphSlot_Oblique, but its implementation doesn't take into account the glyph transform, previously set using FT_Set_Transform, and FreeType developers don't seem to have any interest in changing that (see https://savannah.nongnu.org/bugs/index.php?54565). The proposed solution is to include corresponding shear transform explicitly in matrix passed to FT_Set_Transform instead of using FT_GlyphSlot_Oblique. Proposed patch doesn't add any tests, as the change only impacts glyph rendering, and I couldn't think of a reliable way to test that automatically. Existing automated tests from OpenJDK pass after the fix. Issue: https://bugs.openjdk.java.net/browse/JDK-8210058 Webrev: http://cr.openjdk.java.net/~dbatrak/8210058/webrev.00/ Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: