.(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 jayathirth.d.v at oracle.com Wed Jun 12 15:37:13 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 12 Jun 2019 21:07:13 +0530 Subject: [OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework In-Reply-To: <6D493075-E519-4224-9CBC-F9B795781BF1@oracle.com> References: <2202E165-D9E9-44EE-9D99-71D81C026857@jetbrains.com> <52CE1C36-3570-40A7-BFA1-BEA884D344A1@oracle.com> <3EE8DC6F-C786-49C9-A57E-0C64C36AA025@jetbrains.com> <04ABBE2F-8243-4EF9-BC91-411483EC86D0@jetbrains.com> <325A8B6D-E370-414C-A9FE-4C06621C3D3B@oracle.com> <199ABAE9-7326-4A45-8384-9B1E5BC1C5D6@jetbrains.com> <7080CC33-FAC8-4CE3-974E-F9654E16FF19@oracle.com> <6D493075-E519-4224-9CBC-F9B795781BF1@oracle.com> Message-ID: <4FDD19E0-DC90-4037-A39B-DF2EF718BD6B@oracle.com> Hi Alexey, FYI. We are also trying to merge the latest webrev shared into Open sandbox we have under https://bugs.openjdk.java.net/browse/JDK-8225160 . It is in initial phase of merge, we will be updating the JBS bug with more details as we continue merge process. Thanks, Jay > On 11-Jun-2019, at 2:31 PM, Ajit Ghaisas wrote: > > Hi Alexey, > > Thanks for suggesting how to run basic perf test. > I did run it with and without Metal. The test run with Metal takes ~2X time to run as compared with OpenGL. > What is your observation? > > Although, the java side code changes are good, I see an issue with native Metal renderer implementation. > For rendering primitives, I see that the metal commands are being encoded for each drawXXX call in MTLRenderer.m > > Why is MetalContext.createRenderEncoderForDest is being created for each draw call? I think, it is an overhead. > Have you considered managing a VertexBuffer and encoding ?N? set of draw calls in a render pass? > > Regards, > Ajit > > >> On 17-May-2019, at 12:20 PM, Jayathirth Rao > wrote: >> >> Hi Alexey, >> >> Thanks for the clarifications. >> Build failures we are getting are mainly because of tighter compiler restrictions, I have attached error log for the same. >> Basically we have 2 log errors and one conditional error. >> >> Yes in the latest build there is refactoring of LWComponentPeer.java but I have taken care of it and build error was not because of that. >> >> And thanks for sharing test and Graphics2D supported method details. >> >> Regards, >> Jay >> >> >> >>> On 16-May-2019, at 10:39 PM, Alexey Ushakov > wrote: >>> >>> Hi Jay, >>> >>>>> I can see that now you have added the MTLTexturePool.m file. It only partially solves the build failures. >>>>> Jay & myself tried building it separately and we do still see the build failures. >>> >>> It?s strange. There wasn?t any copy/paste errors. The only reason that I can imagine that some chunks of the patch were rejected (as I actually experienced recently because of some refactoring of LWComponentPeer.java happened couple of days ago). >>> Anyway, I regenerated webrev once more (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 ) and verified it with the openjdk workspace hg.openjdk.java.net/jdk/client . >>> >>> >>>> So with current JB changes what parts of primitive and image drawing are expected to work? >>>> Please provide your inputs. >>> >>> I?ve included junit4 performance test that you can try to see what is currently supported. >>> Here is some steps to run the test provided with the webrev >>> >>> #cd openjdk_ws >>> #mkdir -p test/jdk/jbu/testdata/perf/metal/ >>> #cp webrev/raw_files/new/test/jdk/jbu/testdata/perf/metal/duke.png test/jdk/jbu/testdata/perf/metal/ >>> >>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/javac -cp .:/Users/avu/tools/junit-4.10.jar -d . test/jdk/jbu/perf/metal/MetalPerfTest.java >>> >>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/java -cp .:/Users/avu/tools/junit-4.10.jar -Dtestdata=/Users/avu/ws/openjdk/test/jdk/jbu/testdata -Djb.java2d.metal=true org.junit.runner.JUnitCore perf.metal.MetalPerfTest >>> >>> Here is the list of supported methods from Graphics2D: >>> setColor >>> fillOval >>> translate >>> setTransform >>> rotate >>> setPaint(new LinearGradientPaint()) >>> drawImage >>> fillRect >>> draw/fill (Shape) >>> >>> Best Regards, >>> Alexey >>> >>>> On 16 May 2019, at 15:08, Jayathirth Rao > wrote: >>>> >>>> Hi Alexey, >>>> >>>> We are trying to test basic calls of Graphics2D as mentioned in https://docs.oracle.com/javase/tutorial/2d/TOC.html >>>> >>>> I see that Graphics2D.drawImage() with BufferedImage as input works. Also I tried other operations like fillRect() and fillOval() and they work. I am testing with simple JFrame and adding draw calls inside overriden paint() method of a panel. >>>> >>>> So with current JB changes what parts of primitive and image drawing are expected to work? >>>> Please provide your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>>> On 16-May-2019, at 12:47 PM, Ajit Ghaisas > wrote: >>>>> >>>>> Thanks Alexey. >>>>> >>>>> I can see that now you have added the MTLTexturePool.m file. It only partially solves the build failures. >>>>> Jay & myself tried building it separately and we do still see the build failures. >>>>> >>>>> Some statements need bracketing & some copy-paste errors need correction. >>>>> We could fix these errors and have got a build. We will continue our test experiments with it. >>>>> >>>>> Meanwhile, you may want to update the patch to fix the build errors. >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>>> On 08-May-2019, at 8:56 PM, Alexey Ushakov > wrote: >>>>>> >>>>>> FYI, I?ve rebased our work on top of the latest state of http://hg.openjdk.java.net/jdk/jdk >>>>>> (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 ) >>>>>> >>>>>> Best Regards, >>>>>> Alexey >>>>>> >>>>>>> On 8 May 2019, at 16:19, Alexey Ushakov > wrote: >>>>>>> >>>>>>> Thanks for catching it, Ajit! >>>>>>> >>>>>>> Looks like it was a problem with webrev script applied to multiple git commits. I?ve updated the webrev. >>>>>>> Also, we didn?t rebase yet on the latest state of http://hg.openjdk.java.net/jdk/jdk (this work is in progress). >>>>>>> I?ll let you know when the rebase is ready. >>>>>>> >>>>>>> Best Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> On 7 May 2019, at 21:02, Ajit Ghaisas > wrote: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> I tried building this patch with latest http://hg.openjdk.java.net/jdk/jdk/ >>>>>>>> >>>>>>>> 1. Some basic copy paste errors are resulting in build failures >>>>>>>> 2. MTLTexturePool.m file is missing from the patch >>>>>>>> >>>>>>>> Can you please check & update? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ajit >>>>>>>> >>>>>>>>> On 30-Apr-2019, at 2:52 PM, Alexey Ushakov > wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Here is an update on our effort to use Metal framework for java2d rendering. >>>>>>>>> >>>>>>>>> We?ve added image rendering support and some support for LinearGradient. Also, the code has been refactored. >>>>>>>>> >>>>>>>>> Please have a look: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> As far as we know Apple has deprecated OpenGL on MacOS platform (https://developer.apple.com/macos/whats-new/ ). >>>>>>>>>> >>>>>>>>>> Unfortunately, this decision greatly affects our products that based on Java Client technologies. So, we (here at JetBrains) decided to start a project to replace OpenGL rendering on MacOS platform with a new one based on Metal. This is a huge task, so we decided to leverage current rendering architecture that is used in OpenGL rendering pipeline on Mac. >>>>>>>>>> >>>>>>>>>> That?s why we didn?t use MTKView for representing AWT windows (that probably would be a better approach in the long term). Currently we're using CAMetalLayer within AWTView. We?ve implemented flat color shape/curve rendering so far and there is a lot of work to do. So, we?re looking forward to any collaboration. >>>>>>>>>> >>>>>>>>>> In the mean time I?d like to share our current work to discuss metal pipeline architecture at the early stage of work. >>>>>>>>>> >>>>>>>>>> Here is the webrev with our on going development: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00 >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Alexey >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Fri Jun 14 16:19:05 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 14 Jun 2019 17:19:05 +0100 Subject: [OpenJDK 2D-Dev] [13] Review Request: 8225372 accessibility errors in tables in java.desktop files In-Reply-To: <7a29ed58-906a-7048-07e1-04e9fdbc0bca@oracle.com> References: <7a29ed58-906a-7048-07e1-04e9fdbc0bca@oracle.com> Message-ID: <00becf2b-b1e4-7937-4671-f829490ea200@oracle.com> Hi Sergey, *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. Line 125?

Absolute Values: ???????
- {@code GridBagConstraints.NORTH}
???
Orientation Relative Values: ???????
- {@code GridBagConstraints.PAGE_START}
???

Lines 187?191:

seems to be redundant as well as ?

Baseline Layout? that comes from former element. I think a

would be enough:

to replace the table. The value ?center? is invalid for ?float? property in CSS, so it must be removed, including style attribute of element. *DesktopProperties.html* I'm still unsure we should suppress rendering in bold, should we not? *Modality.html* The table in examples could be replaced by a series of

Example #

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. [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. > -- Regards, Alexey From alexey.ivanov at oracle.com Fri Jun 14 18:07:40 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 14 Jun 2019 19:07:40 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows Message-ID: Hi, Please review the following fix for JDK 13: bug: https://bugs.openjdk.java.net/browse/JDK-8222108 webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.00/ The main goal of this bug was to reduce the minimum refresh time for updating remote printer list to facilitate testing. While working on this bug, I've also done some refactoring. The most prominent one is replacing doCompare() with Arrays.equals(). The former gives wrong result for equal arrays if the array length is greater than 2. Thus this bug can be considered as regression. Arrays.equals() accepts null parameters and null elements in the arrays and always returns the correct result. Thank you in advance. -- Regards, Alexey From jayathirth.d.v at oracle.com Mon Jun 17 09:19:13 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Mon, 17 Jun 2019 14:49:13 +0530 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch Message-ID: Hello All, Please review the below code changes: JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 We have merged most of the code provided for review by JetBrains for JDK-8220154 to the jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox ). Corresponding webrev for the change is http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ . This webrev has JetBrains code from JDK-8220154 and our delta modification[1] over jdk/sandbox metal-prototype-branch For additional info : 1. A webrev relative to the jdk/client codebase - this has JetBrains webrev for JDK-8220154 and our delta modification http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ 2. A webrev showing our delta modifications over JetBrains webrev for JDK-8220154 http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ [1] Delta modification: At native rendering side Ajit has added delta modifications to implement FillRect and DrawParallelogram logic using JetBrains initialisation logic. Apart from how we initialise GraphicsConfig and native rendering most of the upper level logic is similar so we have taken most of the JetBrains code with MTL*** files. Also native rendering state management code from JetBrains we have merged. Comparison of code at GraphicsConfig, SurfaceData and Layer is captured under subtask : https://bugs.openjdk.java.net/browse/JDK-8225165 . Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Jun 18 20:37:30 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 18 Jun 2019 13:37:30 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: Message-ID: Hi, Alexey. I guess that the change in doCompare() passed a review because it was assumed that the code inside will take care of unordered arrays. if we will drop the doCompare() then probably we need to sort the content of the arrays before Arrays.equals()? On 14/06/2019 11:07, Alexey Ivanov wrote: > Hi, > > Please review the following fix for JDK 13: > > bug: https://bugs.openjdk.java.net/browse/JDK-8222108 > webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.00/ > > The main goal of this bug was to reduce the minimum refresh time for updating remote printer list to facilitate testing. > > While working on this bug, I've also done some refactoring. The most prominent one is replacing doCompare() with Arrays.equals(). The former gives wrong result for equal arrays if the array length is greater than 2. Thus this bug can be considered as regression. > > Arrays.equals() accepts null parameters and null elements in the arrays and always returns the correct result. > > > Thank you in advance. > -- Best regards, Sergey. From philip.race at oracle.com Wed Jun 19 00:31:14 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 18 Jun 2019 17:31:14 -0700 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: References: Message-ID: <5D098252.3040504@oracle.com> Hi, First These comments are limited to the files that are *modified* and don't address anything where you have deleted sandbox files and replaced them by JB files. And that is very hard to "diff" anyway .. but it is the biggest batch so I am not sure how to address it. Can you give a detailed explanation of what is in the "new" files vs the "old" files and how you chose one over the other ? So this is my quick take on just the modified files : http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html + -framework Metal \ + -framework MetalKit \ I thought there were no dependencies on MetalKit ? http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html +sun.java2d.metal I am sure this is wrong. That file is a list of internal packages that were present in JDK 8 http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html JFYI I am not sure I like *either* of the pieces of code here. The deleted one or the new one. By which I mean the logic of if (metal) { return MetalSM() } else { return CGLSM(); } both here, and where similar logic appears in other files. We should be installing something that always returns what we need based on choice of pipeline at start up, not doing error prone repeating of the decision. But that is something to discuss later since it isn't a merge issue. http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html +#import +#import I am failing to locate what needs these new imports ?? Same here http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html I see this pattern being added to the Trace* classes. At first it wasn't apparent from the diff it is the Trace classes, so this is something we can discuss but it may need to be measured to see if it corrupts the very data you want. { + if ((traceflags& TRACEPTIME) == 0) { tracePrimitive(target); + } + long time = System.nanoTime(); target.Blit(src, dst, comp, clip, srcx, srcy, dstx, dsty, width, height); + tracePrimitiveTime(target, System.nanoTime() - time); -phil On 6/17/19, 2:19 AM, Jayathirth Rao wrote: > Hello All, > > Please review the below code changes: > > JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 > > We have merged most of the code provided for review by JetBrains for > JDK-8220154 to the > jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox). > Corresponding webrev for the change is > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ > . This > webrev has JetBrains code from JDK-8220154 > and our delta > modification[1] over jdk/sandbox metal-prototype-branch > > For additional info : > 1. A webrev relative to the jdk/client codebase - this has JetBrains > webrev for JDK-8220154 > and our delta > modification > http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ > > > 2. A webrev showing our delta modifications over JetBrains webrev for > JDK-8220154 > http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ > > > > [1] Delta modification: At native rendering side Ajit has added delta > modifications to implement FillRect and DrawParallelogram logic using > JetBrains initialisation logic. > > Apart from how we initialise GraphicsConfig and native rendering most > of the upper level logic is similar so we have taken most of the > JetBrains code with MTL*** files. Also native rendering state > management code from JetBrains we have merged. > Comparison of code at GraphicsConfig, SurfaceData and Layer is > captured under subtask : > https://bugs.openjdk.java.net/browse/JDK-8225165 . > > Thanks, > Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Jun 19 09:08:38 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Wed, 19 Jun 2019 14:38:38 +0530 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: <5D098252.3040504@oracle.com> References: <5D098252.3040504@oracle.com> Message-ID: Hi Phil, Thanks for your inputs. 1) Removed MetalKit reference in make file 2) Removed reference to sun.java2d.metal in jdk8_packages.dat file. 3) For pipeline selection logic, I have created new sub-task JDK-8226384 4) Removed MetalKit references in imports which are not needed. 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8225160/webrev.01/ For file comparison of new and old files, I have created comparison table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf . Thanks, Jay > On 19-Jun-2019, at 6:01 AM, Philip Race wrote: > > > Hi, > > First > These comments are limited to the files that are *modified* and don't > address anything where you have deleted sandbox files and replaced them by JB files. > And that is very hard to "diff" anyway .. but it is the biggest batch so I am not > sure how to address it. > Can you give a detailed explanation of what is in the "new" files vs the "old" files > and how you chose one over the other ? > > So this is my quick take on just the modified files : > > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html > > + -framework Metal \ > + -framework MetalKit \ > I thought there were no dependencies on MetalKit ? > > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html > > +sun.java2d.metal > > I am sure this is wrong. That file is a list of internal packages > that were present in JDK 8 > > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html > JFYI I am not sure I like *either* of the pieces of code here. > The deleted one or the new one. > By which I mean the logic of > if (metal) { > return MetalSM() > } else { > return CGLSM(); > } > > both here, and where similar logic appears in other files. > We should be installing something that always returns what we need based > on choice of pipeline at start up, not doing error prone repeating of the decision. > But that is something to discuss later since it isn't a merge issue. > > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html > +#import > +#import > I am failing to locate what needs these new imports ?? > > Same here > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html > > http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html > > I see this pattern being added to the Trace* classes. > At first it wasn't apparent from the diff it is the Trace classes, > so this is something we can discuss but it may need to be measured > to see if it corrupts the very data you want. > { > + if ((traceflags & TRACEPTIME) == 0) { > tracePrimitive(target); > + } > + long time = System.nanoTime(); > target.Blit(src, dst, comp, clip, > srcx, srcy, dstx, dsty, width, height); > + tracePrimitiveTime(target, System.nanoTime() - time); > > > -phil > > > On 6/17/19, 2:19 AM, Jayathirth Rao wrote: >> >> Hello All, >> >> Please review the below code changes: >> >> JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 >> >> We have merged most of the code provided for review by JetBrains for JDK-8220154 to the jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox ). >> Corresponding webrev for the change is http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ . This webrev has JetBrains code from JDK-8220154 and our delta modification[1] over jdk/sandbox metal-prototype-branch >> >> For additional info : >> 1. A webrev relative to the jdk/client codebase - this has JetBrains webrev for JDK-8220154 and our delta modification >> http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ >> >> 2. A webrev showing our delta modifications over JetBrains webrev for JDK-8220154 >> http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ >> >> >> [1] Delta modification: At native rendering side Ajit has added delta modifications to implement FillRect and DrawParallelogram logic using JetBrains initialisation logic. >> >> Apart from how we initialise GraphicsConfig and native rendering most of the upper level logic is similar so we have taken most of the JetBrains code with MTL*** files. Also native rendering state management code from JetBrains we have merged. >> Comparison of code at GraphicsConfig, SurfaceData and Layer is captured under subtask : https://bugs.openjdk.java.net/browse/JDK-8225165 . >> >> Thanks, >> Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ushakov at jetbrains.com Wed Jun 19 18:30:04 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Wed, 19 Jun 2019 21:30:04 +0300 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: References: <5D098252.3040504@oracle.com> Message-ID: <6E341175-A628-48E1-AE9D-18B3531B59C6@jetbrains.com> Hello Jay and Phil, This changes looks good for me. > 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. Concerning the logging we can remove it. The junit microbenchmarks are enough for now to measure and compare performance of drawing. Best Regards, Alexey > On 19 Jun 2019, at 12:08, Jayathirth Rao wrote: > > Hi Phil, > > Thanks for your inputs. > 1) Removed MetalKit reference in make file > 2) Removed reference to sun.java2d.metal in jdk8_packages.dat file. > 3) For pipeline selection logic, I have created new sub-task JDK-8226384 > 4) Removed MetalKit references in imports which are not needed. > 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8225160/webrev.01/ > > For file comparison of new and old files, I have created comparison table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf . > > Thanks, > Jay > >> On 19-Jun-2019, at 6:01 AM, Philip Race > wrote: >> >> >> Hi, >> >> First >> These comments are limited to the files that are *modified* and don't >> address anything where you have deleted sandbox files and replaced them by JB files. >> And that is very hard to "diff" anyway .. but it is the biggest batch so I am not >> sure how to address it. >> Can you give a detailed explanation of what is in the "new" files vs the "old" files >> and how you chose one over the other ? >> >> So this is my quick take on just the modified files : >> >> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html >> >> + -framework Metal \ >> + -framework MetalKit \ >> I thought there were no dependencies on MetalKit ? >> >> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html >> >> +sun.java2d.metal >> >> I am sure this is wrong. That file is a list of internal packages >> that were present in JDK 8 >> >> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html >> JFYI I am not sure I like *either* of the pieces of code here. >> The deleted one or the new one. >> By which I mean the logic of >> if (metal) { >> return MetalSM() >> } else { >> return CGLSM(); >> } >> >> both here, and where similar logic appears in other files. >> We should be installing something that always returns what we need based >> on choice of pipeline at start up, not doing error prone repeating of the decision. >> But that is something to discuss later since it isn't a merge issue. >> >> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html >> +#import >> +#import >> I am failing to locate what needs these new imports ?? >> >> Same here >> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html >> >> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html >> >> I see this pattern being added to the Trace* classes. >> At first it wasn't apparent from the diff it is the Trace classes, >> so this is something we can discuss but it may need to be measured >> to see if it corrupts the very data you want. >> { >> + if ((traceflags & TRACEPTIME) == 0) { >> tracePrimitive(target); >> + } >> + long time = System.nanoTime(); >> target.Blit(src, dst, comp, clip, >> srcx, srcy, dstx, dsty, width, height); >> + tracePrimitiveTime(target, System.nanoTime() - time); >> >> >> -phil >> >> >> On 6/17/19, 2:19 AM, Jayathirth Rao wrote: >>> >>> Hello All, >>> >>> Please review the below code changes: >>> >>> JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 >>> >>> We have merged most of the code provided for review by JetBrains for JDK-8220154 to the jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox ). >>> Corresponding webrev for the change is http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ . This webrev has JetBrains code from JDK-8220154 and our delta modification[1] over jdk/sandbox metal-prototype-branch >>> >>> For additional info : >>> 1. A webrev relative to the jdk/client codebase - this has JetBrains webrev for JDK-8220154 and our delta modification >>> http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ >>> >>> 2. A webrev showing our delta modifications over JetBrains webrev for JDK-8220154 >>> http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ >>> >>> >>> [1] Delta modification: At native rendering side Ajit has added delta modifications to implement FillRect and DrawParallelogram logic using JetBrains initialisation logic. >>> >>> Apart from how we initialise GraphicsConfig and native rendering most of the upper level logic is similar so we have taken most of the JetBrains code with MTL*** files. Also native rendering state management code from JetBrains we have merged. >>> Comparison of code at GraphicsConfig, SurfaceData and Layer is captured under subtask : https://bugs.openjdk.java.net/browse/JDK-8225165 . >>> >>> Thanks, >>> Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ushakov at jetbrains.com Wed Jun 19 22:20:16 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Thu, 20 Jun 2019 01:20:16 +0300 Subject: [OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework In-Reply-To: <6D493075-E519-4224-9CBC-F9B795781BF1@oracle.com> References: <2202E165-D9E9-44EE-9D99-71D81C026857@jetbrains.com> <52CE1C36-3570-40A7-BFA1-BEA884D344A1@oracle.com> <3EE8DC6F-C786-49C9-A57E-0C64C36AA025@jetbrains.com> <04ABBE2F-8243-4EF9-BC91-411483EC86D0@jetbrains.com> <325A8B6D-E370-414C-A9FE-4C06621C3D3B@oracle.com> <199ABAE9-7326-4A45-8384-9B1E5BC1C5D6@jetbrains.com> <7080CC33-FAC8-4CE3-974E-F9654E16FF19@oracle.com> <6D493075-E519-4224-9CBC-F9B795781BF1@oracle.com> Message-ID: Hi Ajit, > Thanks for suggesting how to run basic perf test. > I did run it with and without Metal. The test run with Metal takes ~2X time to run as compared with OpenGL. > What is your observation? Yes, in some cases we have similar performance drop at the moment (testFlatBubbles, testFlatOvalRotBubbles, testWiredBubbles, testFlatQuad, testWiredQuad) Here is the results from Mac mini 2018, macOS 10.14.4 metalEnabled=0 testFlatBubbles 70 testFlatBoxBubbles 78 testImgBubbles 73 testFlatBoxRotBubbles 78 testFlatOvalRotBubbles 74 testLinGradOvalRotBubbles 46 testWiredBubbles 54 testWiredBoxBubbles 82 testLines 84 testFlatQuad 62 testWiredQuad 58 metalEnabled=1 testFlatBubbles 31 testFlatBoxBubbles 91 testImgBubbles 88 testFlatBoxRotBubbles 92 testFlatOvalRotBubbles 36 testLinGradOvalRotBubbles 37 testWiredBubbles 17 testWiredBoxBubbles - testLines 89 testFlatQuad 21 testWiredQuad 19 > Although, the java side code changes are good, I see an issue with native Metal renderer implementation. > For rendering primitives, I see that the metal commands are being encoded for each drawXXX call in MTLRenderer.m > > Why is MetalContext.createRenderEncoderForDest is being created for each draw call? I think, it is an overhead. > Have you considered managing a VertexBuffer and encoding ?N? set of draw calls in a render pass? Yes, I thought about such optimizations. They definetely should help with this performance drop. Best Regards, Alexey > On 11 Jun 2019, at 12:01, Ajit Ghaisas wrote: > > Hi Alexey, > > Thanks for suggesting how to run basic perf test. > I did run it with and without Metal. The test run with Metal takes ~2X time to run as compared with OpenGL. > What is your observation? > > Although, the java side code changes are good, I see an issue with native Metal renderer implementation. > For rendering primitives, I see that the metal commands are being encoded for each drawXXX call in MTLRenderer.m > > Why is MetalContext.createRenderEncoderForDest is being created for each draw call? I think, it is an overhead. > Have you considered managing a VertexBuffer and encoding ?N? set of draw calls in a render pass? > > Regards, > Ajit > > >> On 17-May-2019, at 12:20 PM, Jayathirth Rao > wrote: >> >> Hi Alexey, >> >> Thanks for the clarifications. >> Build failures we are getting are mainly because of tighter compiler restrictions, I have attached error log for the same. >> Basically we have 2 log errors and one conditional error. >> >> Yes in the latest build there is refactoring of LWComponentPeer.java but I have taken care of it and build error was not because of that. >> >> And thanks for sharing test and Graphics2D supported method details. >> >> Regards, >> Jay >> >> >> >>> On 16-May-2019, at 10:39 PM, Alexey Ushakov > wrote: >>> >>> Hi Jay, >>> >>>>> I can see that now you have added the MTLTexturePool.m file. It only partially solves the build failures. >>>>> Jay & myself tried building it separately and we do still see the build failures. >>> >>> It?s strange. There wasn?t any copy/paste errors. The only reason that I can imagine that some chunks of the patch were rejected (as I actually experienced recently because of some refactoring of LWComponentPeer.java happened couple of days ago). >>> Anyway, I regenerated webrev once more (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 ) and verified it with the openjdk workspace hg.openjdk.java.net/jdk/client . >>> >>> >>>> So with current JB changes what parts of primitive and image drawing are expected to work? >>>> Please provide your inputs. >>> >>> I?ve included junit4 performance test that you can try to see what is currently supported. >>> Here is some steps to run the test provided with the webrev >>> >>> #cd openjdk_ws >>> #mkdir -p test/jdk/jbu/testdata/perf/metal/ >>> #cp webrev/raw_files/new/test/jdk/jbu/testdata/perf/metal/duke.png test/jdk/jbu/testdata/perf/metal/ >>> >>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/javac -cp .:/Users/avu/tools/junit-4.10.jar -d . test/jdk/jbu/perf/metal/MetalPerfTest.java >>> >>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/java -cp .:/Users/avu/tools/junit-4.10.jar -Dtestdata=/Users/avu/ws/openjdk/test/jdk/jbu/testdata -Djb.java2d.metal=true org.junit.runner.JUnitCore perf.metal.MetalPerfTest >>> >>> Here is the list of supported methods from Graphics2D: >>> setColor >>> fillOval >>> translate >>> setTransform >>> rotate >>> setPaint(new LinearGradientPaint()) >>> drawImage >>> fillRect >>> draw/fill (Shape) >>> >>> Best Regards, >>> Alexey >>> >>>> On 16 May 2019, at 15:08, Jayathirth Rao > wrote: >>>> >>>> Hi Alexey, >>>> >>>> We are trying to test basic calls of Graphics2D as mentioned in https://docs.oracle.com/javase/tutorial/2d/TOC.html >>>> >>>> I see that Graphics2D.drawImage() with BufferedImage as input works. Also I tried other operations like fillRect() and fillOval() and they work. I am testing with simple JFrame and adding draw calls inside overriden paint() method of a panel. >>>> >>>> So with current JB changes what parts of primitive and image drawing are expected to work? >>>> Please provide your inputs. >>>> >>>> Thanks, >>>> Jay >>>> >>>>> On 16-May-2019, at 12:47 PM, Ajit Ghaisas > wrote: >>>>> >>>>> Thanks Alexey. >>>>> >>>>> I can see that now you have added the MTLTexturePool.m file. It only partially solves the build failures. >>>>> Jay & myself tried building it separately and we do still see the build failures. >>>>> >>>>> Some statements need bracketing & some copy-paste errors need correction. >>>>> We could fix these errors and have got a build. We will continue our test experiments with it. >>>>> >>>>> Meanwhile, you may want to update the patch to fix the build errors. >>>>> >>>>> Regards, >>>>> Ajit >>>>> >>>>> >>>>>> On 08-May-2019, at 8:56 PM, Alexey Ushakov > wrote: >>>>>> >>>>>> FYI, I?ve rebased our work on top of the latest state of http://hg.openjdk.java.net/jdk/jdk >>>>>> (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 ) >>>>>> >>>>>> Best Regards, >>>>>> Alexey >>>>>> >>>>>>> On 8 May 2019, at 16:19, Alexey Ushakov > wrote: >>>>>>> >>>>>>> Thanks for catching it, Ajit! >>>>>>> >>>>>>> Looks like it was a problem with webrev script applied to multiple git commits. I?ve updated the webrev. >>>>>>> Also, we didn?t rebase yet on the latest state of http://hg.openjdk.java.net/jdk/jdk (this work is in progress). >>>>>>> I?ll let you know when the rebase is ready. >>>>>>> >>>>>>> Best Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> On 7 May 2019, at 21:02, Ajit Ghaisas > wrote: >>>>>>>> >>>>>>>> Hi Alexey, >>>>>>>> >>>>>>>> I tried building this patch with latest http://hg.openjdk.java.net/jdk/jdk/ >>>>>>>> >>>>>>>> 1. Some basic copy paste errors are resulting in build failures >>>>>>>> 2. MTLTexturePool.m file is missing from the patch >>>>>>>> >>>>>>>> Can you please check & update? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Ajit >>>>>>>> >>>>>>>>> On 30-Apr-2019, at 2:52 PM, Alexey Ushakov > wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Here is an update on our effort to use Metal framework for java2d rendering. >>>>>>>>> >>>>>>>>> We?ve added image rendering support and some support for LinearGradient. Also, the code has been refactored. >>>>>>>>> >>>>>>>>> Please have a look: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Alexey >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> As far as we know Apple has deprecated OpenGL on MacOS platform (https://developer.apple.com/macos/whats-new/ ). >>>>>>>>>> >>>>>>>>>> Unfortunately, this decision greatly affects our products that based on Java Client technologies. So, we (here at JetBrains) decided to start a project to replace OpenGL rendering on MacOS platform with a new one based on Metal. This is a huge task, so we decided to leverage current rendering architecture that is used in OpenGL rendering pipeline on Mac. >>>>>>>>>> >>>>>>>>>> That?s why we didn?t use MTKView for representing AWT windows (that probably would be a better approach in the long term). Currently we're using CAMetalLayer within AWTView. We?ve implemented flat color shape/curve rendering so far and there is a lot of work to do. So, we?re looking forward to any collaboration. >>>>>>>>>> >>>>>>>>>> In the mean time I?d like to share our current work to discuss metal pipeline architecture at the early stage of work. >>>>>>>>>> >>>>>>>>>> Here is the webrev with our on going development: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00 >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Alexey >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Jun 20 12:57:07 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Thu, 20 Jun 2019 18:27:07 +0530 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: <6E341175-A628-48E1-AE9D-18B3531B59C6@jetbrains.com> References: <5D098252.3040504@oracle.com> <6E341175-A628-48E1-AE9D-18B3531B59C6@jetbrains.com> Message-ID: <9491F7D4-6960-44D5-A38E-2AD50B59047E@oracle.com> 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/ Regards, Jay > On 20-Jun-2019, at 12:00 AM, Alexey Ushakov wrote: > > Hello Jay and Phil, > > This changes looks good for me. > >> 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. > > Concerning the logging we can remove it. The junit microbenchmarks are enough for now to measure and compare performance of drawing. > > Best Regards, > Alexey > >> On 19 Jun 2019, at 12:08, Jayathirth Rao > wrote: >> >> Hi Phil, >> >> Thanks for your inputs. >> 1) Removed MetalKit reference in make file >> 2) Removed reference to sun.java2d.metal in jdk8_packages.dat file. >> 3) For pipeline selection logic, I have created new sub-task JDK-8226384 >> 4) Removed MetalKit references in imports which are not needed. >> 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8225160/webrev.01/ >> >> For file comparison of new and old files, I have created comparison table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf . >> >> Thanks, >> Jay >> >>> On 19-Jun-2019, at 6:01 AM, Philip Race > wrote: >>> >>> >>> Hi, >>> >>> First >>> These comments are limited to the files that are *modified* and don't >>> address anything where you have deleted sandbox files and replaced them by JB files. >>> And that is very hard to "diff" anyway .. but it is the biggest batch so I am not >>> sure how to address it. >>> Can you give a detailed explanation of what is in the "new" files vs the "old" files >>> and how you chose one over the other ? >>> >>> So this is my quick take on just the modified files : >>> >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html >>> >>> + -framework Metal \ >>> + -framework MetalKit \ >>> I thought there were no dependencies on MetalKit ? >>> >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html >>> >>> +sun.java2d.metal >>> >>> I am sure this is wrong. That file is a list of internal packages >>> that were present in JDK 8 >>> >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html >>> JFYI I am not sure I like *either* of the pieces of code here. >>> The deleted one or the new one. >>> By which I mean the logic of >>> if (metal) { >>> return MetalSM() >>> } else { >>> return CGLSM(); >>> } >>> >>> both here, and where similar logic appears in other files. >>> We should be installing something that always returns what we need based >>> on choice of pipeline at start up, not doing error prone repeating of the decision. >>> But that is something to discuss later since it isn't a merge issue. >>> >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html >>> +#import >>> +#import >>> I am failing to locate what needs these new imports ?? >>> >>> Same here >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html >>> >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html >>> >>> I see this pattern being added to the Trace* classes. >>> At first it wasn't apparent from the diff it is the Trace classes, >>> so this is something we can discuss but it may need to be measured >>> to see if it corrupts the very data you want. >>> { >>> + if ((traceflags & TRACEPTIME) == 0) { >>> tracePrimitive(target); >>> + } >>> + long time = System.nanoTime(); >>> target.Blit(src, dst, comp, clip, >>> srcx, srcy, dstx, dsty, width, height); >>> + tracePrimitiveTime(target, System.nanoTime() - time); >>> >>> >>> -phil >>> >>> >>> On 6/17/19, 2:19 AM, Jayathirth Rao wrote: >>>> >>>> Hello All, >>>> >>>> Please review the below code changes: >>>> >>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 >>>> >>>> We have merged most of the code provided for review by JetBrains for JDK-8220154 to the jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox ). >>>> Corresponding webrev for the change is http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ . This webrev has JetBrains code from JDK-8220154 and our delta modification[1] over jdk/sandbox metal-prototype-branch >>>> >>>> For additional info : >>>> 1. A webrev relative to the jdk/client codebase - this has JetBrains webrev for JDK-8220154 and our delta modification >>>> http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ >>>> >>>> 2. A webrev showing our delta modifications over JetBrains webrev for JDK-8220154 >>>> http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ >>>> >>>> >>>> [1] Delta modification: At native rendering side Ajit has added delta modifications to implement FillRect and DrawParallelogram logic using JetBrains initialisation logic. >>>> >>>> Apart from how we initialise GraphicsConfig and native rendering most of the upper level logic is similar so we have taken most of the JetBrains code with MTL*** files. Also native rendering state management code from JetBrains we have merged. >>>> Comparison of code at GraphicsConfig, SurfaceData and Layer is captured under subtask : https://bugs.openjdk.java.net/browse/JDK-8225165 . >>>> >>>> Thanks, >>>> Jay >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu Jun 20 19:52:00 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 20 Jun 2019 12:52:00 -0700 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: <9491F7D4-6960-44D5-A38E-2AD50B59047E@oracle.com> References: <5D098252.3040504@oracle.com> <6E341175-A628-48E1-AE9D-18B3531B59C6@jetbrains.com> <9491F7D4-6960-44D5-A38E-2AD50B59047E@oracle.com> Message-ID: <16b248a8-8e5a-9cb5-adba-b2eeaf3101de@oracle.com> 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/ > > Regards, > Jay > >> On 20-Jun-2019, at 12:00 AM, Alexey Ushakov >> > >> wrote: >> >> Hello Jay and Phil, >> >> This changes looks good for me. >> >>> 5) Time tracing for primitive drawing was present in JetBrain?s code >>> so we took it. It may hamper overall performance while drawing, if >>> it is not needed we can remove it. >> >> Concerning the logging we can remove it. The junit microbenchmarks >> are enough for now to measure and compare performance of drawing. >> >> Best Regards, >> Alexey >> >>> On 19 Jun 2019, at 12:08, Jayathirth Rao >> > wrote: >>> >>> Hi Phil, >>> >>> Thanks for your inputs. >>> 1) Removed MetalKit reference in make file >>> 2) Removed reference to sun.java2d.metal in jdk8_packages.dat file. >>> 3) For pipeline selection logic, I have created new sub-task >>> JDK-8226384 >>> 4) Removed MetalKit references in imports which are not needed. >>> 5) Time tracing for primitive drawing was present in JetBrain?s code >>> so we took it. It may hamper overall performance while drawing, if >>> it is not needed we can remove it. >>> >>> Please find updated webrev for review: >>> http://cr.openjdk.java.net/~jdv/8225160/webrev.01/ >>> >>> For file comparison of new and old files, I have created comparison >>> table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf. >>> >>> Thanks, >>> Jay >>> >>>> On 19-Jun-2019, at 6:01 AM, Philip Race >>> > wrote: >>>> >>>> Hi, First These comments are limited to the files that are >>>> *modified* and don't address anything where you have deleted >>>> sandbox files and replaced them by JB files. And that is very hard >>>> to "diff" anyway .. but it is the biggest batch so I am not sure >>>> how to address it. Can you give a detailed explanation of what is >>>> in the "new" files vs the "old" files and how you chose one over >>>> the other ? So this is my quick take on just the modified files : >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html >>>> + -framework Metal \ >>>> + -framework MetalKit \ >>>> I thought there were no dependencies on MetalKit ? >>>> >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html >>>> >>>> +sun.java2d.metal I am sure this is wrong. That file is a list of >>>> internal packages that were present in JDK 8 >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html >>>> JFYI I am not sure I like *either* of the pieces of code here. >>>> The deleted one or the new one. >>>> By which I mean the logic of >>>> if (metal) { >>>> ? return MetalSM() >>>> } else { >>>> ? return CGLSM(); >>>> } >>>> >>>> both here, and where similar logic appears in other files. >>>> We should be installing something that always returns what we need >>>> based >>>> on choice of pipeline at start up, not doing error prone repeating >>>> of the decision. >>>> But that is something to discuss later since it isn't a merge issue. >>>> >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html >>>> +#import >>>> +#import >>>> I am failing to locate what needs these new imports ?? >>>> >>>> Same here >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html >>>> >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html >>>> >>>> I see this pattern being added to the Trace* classes. >>>> At first it wasn't apparent from the diff it is the Trace classes, >>>> so this is something we can discuss but it may need to be measured >>>> to see if it corrupts the very data you want. >>>> { >>>> + if ((traceflags & TRACEPTIME) == 0) { >>>> tracePrimitive(target); >>>> + } >>>> + long time = System.nanoTime(); >>>> target.Blit(src, dst, comp, clip, >>>> srcx, srcy, dstx, dsty, width, height); >>>> + tracePrimitiveTime(target, System.nanoTime() - time); -phil >>>> >>>> >>>> On 6/17/19, 2:19 AM, Jayathirth Rao wrote: >>>>> Hello All, >>>>> >>>>> Please review the below code changes: >>>>> >>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 >>>>> >>>>> We have merged most of the code provided for review by JetBrains >>>>> for JDK-8220154 >>>>> to the jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox). >>>>> Corresponding webrev for the change is >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ >>>>> ?. This >>>>> webrev?has JetBrains code from JDK-8220154 >>>>> ?and our delta >>>>> modification[1] over jdk/sandbox metal-prototype-branch >>>>> >>>>> For additional info : >>>>> 1. A webrev relative to the jdk/client codebase - this has >>>>> JetBrains webrev for JDK-8220154 >>>>> and our delta >>>>> modification >>>>> http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ >>>>> >>>>> >>>>> >>>>> 2. A webrev showing our delta modifications over JetBrains webrev >>>>> for JDK-8220154 >>>>> http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ >>>>> >>>>> >>>>> >>>>> [1] Delta modification: At native rendering side Ajit has added >>>>> delta modifications to implement FillRect and DrawParallelogram >>>>> logic using JetBrains initialisation logic. >>>>> >>>>> Apart from how we initialise GraphicsConfig and native rendering >>>>> most of the upper level logic is similar so we have taken most of >>>>> the JetBrains code with MTL*** files. Also native rendering state >>>>> management code from JetBrains we have merged. >>>>> Comparison of code at GraphicsConfig, SurfaceData and Layer is >>>>> captured under subtask : >>>>> https://bugs.openjdk.java.net/browse/JDK-8225165?. >>>>> >>>>> Thanks, >>>>> Jay >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jun 20 20:51:18 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 20 Jun 2019 13:51:18 -0700 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: <16b248a8-8e5a-9cb5-adba-b2eeaf3101de@oracle.com> References: <5D098252.3040504@oracle.com> <6E341175-A628-48E1-AE9D-18B3531B59C6@jetbrains.com> <9491F7D4-6960-44D5-A38E-2AD50B59047E@oracle.com> <16b248a8-8e5a-9cb5-adba-b2eeaf3101de@oracle.com> Message-ID: <5D0BF1C6.6020504@oracle.com> I'm OK with this. We will doubtless incrementally revisit everything before we are done. -phil. On 6/20/19, 12:52 PM, Kevin Rushforth wrote: > 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/ >> >> >> Regards, >> Jay >> >>> On 20-Jun-2019, at 12:00 AM, Alexey Ushakov >>> > >>> wrote: >>> >>> Hello Jay and Phil, >>> >>> This changes looks good for me. >>> >>>> 5) Time tracing for primitive drawing was present in JetBrain?s >>>> code so we took it. It may hamper overall performance while >>>> drawing, if it is not needed we can remove it. >>> >>> Concerning the logging we can remove it. The junit microbenchmarks >>> are enough for now to measure and compare performance of drawing. >>> >>> Best Regards, >>> Alexey >>> >>>> On 19 Jun 2019, at 12:08, Jayathirth Rao >>> > wrote: >>>> >>>> Hi Phil, >>>> >>>> Thanks for your inputs. >>>> 1) Removed MetalKit reference in make file >>>> 2) Removed reference to sun.java2d.metal in jdk8_packages.dat file. >>>> 3) For pipeline selection logic, I have created new sub-task >>>> JDK-8226384 >>>> 4) Removed MetalKit references in imports which are not needed. >>>> 5) Time tracing for primitive drawing was present in JetBrain?s >>>> code so we took it. It may hamper overall performance while >>>> drawing, if it is not needed we can remove it. >>>> >>>> Please find updated webrev for review: >>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.01/ >>>> >>>> >>>> For file comparison of new and old files, I have created comparison >>>> table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf >>>> . >>>> >>>> Thanks, >>>> Jay >>>> >>>>> On 19-Jun-2019, at 6:01 AM, Philip Race >>>> > wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> First >>>>> These comments are limited to the files that are *modified* and don't >>>>> address anything where you have deleted sandbox files and replaced them by JB files. >>>>> And that is very hard to "diff" anyway .. but it is the biggest batch so I am not >>>>> sure how to address it. >>>>> Can you give a detailed explanation of what is in the "new" files vs the "old" files >>>>> and how you chose one over the other ? >>>>> >>>>> So this is my quick take on just the modified files : >>>>> >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html >>>>> >>>>> + -framework Metal \ >>>>> + -framework MetalKit \ >>>>> I thought there were no dependencies on MetalKit ? >>>>> >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html >>>>> >>>>> +sun.java2d.metal >>>>> >>>>> I am sure this is wrong. That file is a list of internal packages >>>>> that were present in JDK 8 >>>>> >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html >>>>> JFYI I am not sure I like *either* of the pieces of code here. >>>>> The deleted one or the new one. >>>>> By which I mean the logic of >>>>> if (metal) { >>>>> return MetalSM() >>>>> } else { >>>>> return CGLSM(); >>>>> } >>>>> >>>>> both here, and where similar logic appears in other files. >>>>> We should be installing something that always returns what we need >>>>> based >>>>> on choice of pipeline at start up, not doing error prone repeating >>>>> of the decision. >>>>> But that is something to discuss later since it isn't a merge issue. >>>>> >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html >>>>> +#import >>>>> +#import >>>>> I am failing to locate what needs these new imports ?? >>>>> >>>>> Same here >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html >>>>> >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html >>>>> >>>>> I see this pattern being added to the Trace* classes. >>>>> At first it wasn't apparent from the diff it is the Trace classes, >>>>> so this is something we can discuss but it may need to be measured >>>>> to see if it corrupts the very data you want. >>>>> { >>>>> + if ((traceflags& TRACEPTIME) == 0) { >>>>> tracePrimitive(target); >>>>> + } >>>>> + long time = System.nanoTime(); >>>>> target.Blit(src, dst, comp, clip, >>>>> srcx, srcy, dstx, dsty, width, height); >>>>> + tracePrimitiveTime(target, System.nanoTime() - time); >>>>> >>>>> >>>>> -phil >>>>> >>>>> >>>>> On 6/17/19, 2:19 AM, Jayathirth Rao wrote: >>>>>> Hello All, >>>>>> >>>>>> Please review the below code changes: >>>>>> >>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 >>>>>> >>>>>> We have merged most of the code provided for review by JetBrains >>>>>> for JDK-8220154 >>>>>> to the >>>>>> jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox). >>>>>> Corresponding webrev for the change is >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ >>>>>> . This >>>>>> webrev has JetBrains code from JDK-8220154 >>>>>> and our delta >>>>>> modification[1] over jdk/sandbox metal-prototype-branch >>>>>> >>>>>> For additional info : >>>>>> 1. A webrev relative to the jdk/client codebase - this has >>>>>> JetBrains webrev for JDK-8220154 >>>>>> and our delta >>>>>> modification >>>>>> http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ >>>>>> >>>>>> >>>>>> >>>>>> 2. A webrev showing our delta modifications over JetBrains webrev >>>>>> for JDK-8220154 >>>>>> http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ >>>>>> >>>>>> >>>>>> >>>>>> [1] Delta modification: At native rendering side Ajit has added >>>>>> delta modifications to implement FillRect and DrawParallelogram >>>>>> logic using JetBrains initialisation logic. >>>>>> >>>>>> Apart from how we initialise GraphicsConfig and native rendering >>>>>> most of the upper level logic is similar so we have taken most of >>>>>> the JetBrains code with MTL*** files. Also native rendering state >>>>>> management code from JetBrains we have merged. >>>>>> Comparison of code at GraphicsConfig, SurfaceData and Layer is >>>>>> captured under subtask : >>>>>> https://bugs.openjdk.java.net/browse/JDK-8225165 . >>>>>> >>>>>> Thanks, >>>>>> Jay >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Fri Jun 21 09:17:39 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Fri, 21 Jun 2019 14:47:39 +0530 Subject: [OpenJDK 2D-Dev] RFR 8225160: Merge JDK-8220154 initial metal implementation patch to the jdk sandbox branch In-Reply-To: <5D0BF1C6.6020504@oracle.com> References: <5D098252.3040504@oracle.com> <6E341175-A628-48E1-AE9D-18B3531B59C6@jetbrains.com> <9491F7D4-6960-44D5-A38E-2AD50B59047E@oracle.com> <16b248a8-8e5a-9cb5-adba-b2eeaf3101de@oracle.com> <5D0BF1C6.6020504@oracle.com> Message-ID: <539770D3-8ACF-4EE5-89C2-188457CF87BB@oracle.com> Hello All, Thanks for the review. Changes are merged into the sandbox. Made some more changes in sandbox like JDK-8226560 and took mainline changes into our metal-prototype-branch. We can take latest change from this sandbox branch and work further. Thanks, Jay > On 21-Jun-2019, at 2:21 AM, Philip Race wrote: > > I'm OK with this. We will doubtless incrementally revisit everything before we are done. > > -phil. > > On 6/20/19, 12:52 PM, Kevin Rushforth wrote: >> >> 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/ >>> >>> Regards, >>> Jay >>> >>>> On 20-Jun-2019, at 12:00 AM, Alexey Ushakov > wrote: >>>> >>>> Hello Jay and Phil, >>>> >>>> This changes looks good for me. >>>> >>>>> 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. >>>> >>>> Concerning the logging we can remove it. The junit microbenchmarks are enough for now to measure and compare performance of drawing. >>>> >>>> Best Regards, >>>> Alexey >>>> >>>>> On 19 Jun 2019, at 12:08, Jayathirth Rao > wrote: >>>>> >>>>> Hi Phil, >>>>> >>>>> Thanks for your inputs. >>>>> 1) Removed MetalKit reference in make file >>>>> 2) Removed reference to sun.java2d.metal in jdk8_packages.dat file. >>>>> 3) For pipeline selection logic, I have created new sub-task JDK-8226384 >>>>> 4) Removed MetalKit references in imports which are not needed. >>>>> 5) Time tracing for primitive drawing was present in JetBrain?s code so we took it. It may hamper overall performance while drawing, if it is not needed we can remove it. >>>>> >>>>> Please find updated webrev for review: >>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.01/ >>>>> >>>>> For file comparison of new and old files, I have created comparison table at http://cr.openjdk.java.net/~jdv/8225160/file_compare.rtf . >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>>> On 19-Jun-2019, at 6:01 AM, Philip Race > wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> First >>>>>> These comments are limited to the files that are *modified* and don't >>>>>> address anything where you have deleted sandbox files and replaced them by JB files. >>>>>> And that is very hard to "diff" anyway .. but it is the biggest batch so I am not >>>>>> sure how to address it. >>>>>> Can you give a detailed explanation of what is in the "new" files vs the "old" files >>>>>> and how you chose one over the other ? >>>>>> >>>>>> So this is my quick take on just the modified files : >>>>>> >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/make/lib/Awt2dLibraries.gmk.udiff.html >>>>>> >>>>>> + -framework Metal \ >>>>>> + -framework MetalKit \ >>>>>> I thought there were no dependencies on MetalKit ? >>>>>> >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.base/share/classes/jdk/internal/module/jdk8_packages.dat.udiff.html >>>>>> >>>>>> +sun.java2d.metal >>>>>> >>>>>> I am sure this is wrong. That file is a list of internal packages >>>>>> that were present in JDK 8 >>>>>> >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/classes/sun/java2d/MacosxSurfaceManagerFactory.java.udiff.html >>>>>> JFYI I am not sure I like *either* of the pieces of code here. >>>>>> The deleted one or the new one. >>>>>> By which I mean the logic of >>>>>> if (metal) { >>>>>> return MetalSM() >>>>>> } else { >>>>>> return CGLSM(); >>>>>> } >>>>>> >>>>>> both here, and where similar logic appears in other files. >>>>>> We should be installing something that always returns what we need based >>>>>> on choice of pipeline at start up, not doing error prone repeating of the decision. >>>>>> But that is something to discuss later since it isn't a merge issue. >>>>>> >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.h.udiff.html >>>>>> +#import >>>>>> +#import >>>>>> I am failing to locate what needs these new imports ?? >>>>>> >>>>>> Same here >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m.udiff.html >>>>>> >>>>>> http://cr.openjdk.java.net/~jdv/8225160/webrev.00/src/java.desktop/share/classes/sun/java2d/loops/Blit.java.udiff.html >>>>>> >>>>>> I see this pattern being added to the Trace* classes. >>>>>> At first it wasn't apparent from the diff it is the Trace classes, >>>>>> so this is something we can discuss but it may need to be measured >>>>>> to see if it corrupts the very data you want. >>>>>> { >>>>>> + if ((traceflags & TRACEPTIME) == 0) { >>>>>> tracePrimitive(target); >>>>>> + } >>>>>> + long time = System.nanoTime(); >>>>>> target.Blit(src, dst, comp, clip, >>>>>> srcx, srcy, dstx, dsty, width, height); >>>>>> + tracePrimitiveTime(target, System.nanoTime() - time); >>>>>> >>>>>> >>>>>> -phil >>>>>> >>>>>> >>>>>> On 6/17/19, 2:19 AM, Jayathirth Rao wrote: >>>>>>> >>>>>>> Hello All, >>>>>>> >>>>>>> Please review the below code changes: >>>>>>> >>>>>>> JBS : https://bugs.openjdk.java.net/browse/JDK-8225160 >>>>>>> >>>>>>> We have merged most of the code provided for review by JetBrains for JDK-8220154 to the jdk/sandbox(http://hg.openjdk.java.net/jdk/sandbox ). >>>>>>> Corresponding webrev for the change is http://cr.openjdk.java.net/~jdv/8225160/webrev.00/ . This webrev has JetBrains code from JDK-8220154 and our delta modification[1] over jdk/sandbox metal-prototype-branch >>>>>>> >>>>>>> For additional info : >>>>>>> 1. A webrev relative to the jdk/client codebase - this has JetBrains webrev for JDK-8220154 and our delta modification >>>>>>> http://cr.openjdk.java.net/~aghaisas/8225160/JB_plus_delta/webrev.1/ >>>>>>> >>>>>>> 2. A webrev showing our delta modifications over JetBrains webrev for JDK-8220154 >>>>>>> http://cr.openjdk.java.net/~aghaisas/8225160/webrev.1/ >>>>>>> >>>>>>> >>>>>>> [1] Delta modification: At native rendering side Ajit has added delta modifications to implement FillRect and DrawParallelogram logic using JetBrains initialisation logic. >>>>>>> >>>>>>> Apart from how we initialise GraphicsConfig and native rendering most of the upper level logic is similar so we have taken most of the JetBrains code with MTL*** files. Also native rendering state management code from JetBrains we have merged. >>>>>>> Comparison of code at GraphicsConfig, SurfaceData and Layer is captured under subtask : https://bugs.openjdk.java.net/browse/JDK-8225165 . >>>>>>> >>>>>>> Thanks, >>>>>>> Jay >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Mon Jun 24 12:51:33 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 24 Jun 2019 21:51:33 +0900 Subject: [OpenJDK 2D-Dev] RFR: 8221741 [AIX] Unexpected X11 bitmap fonts are loaded because of fontconfig.properties In-Reply-To: <39a4bf61e419ff9e0a79f51fe6852005@linux.vnet.ibm.com> References: <5CA4DAB9.2060602@oracle.com> <5df6bf0ff90d068fcdf95a19ff8cda55@linux.vnet.ibm.com> <0681c7b7-28c8-67bb-2ba4-0db510449dff@oracle.com> <6c657225-6866-bdc3-66cc-00c5e4141013@oracle.com> <4fa4f749d09354dfe016dfc9e40e3b79@linux.vnet.ibm.com> <39a4bf61e419ff9e0a79f51fe6852005@linux.vnet.ibm.com> Message-ID: Hello Could you review the fix ? Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.03/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 I applied following changes: -- make/data/fontconfig/aix.fontconfig.properties * XLFD font name should be in fonts.dir * Use East Asian TrueType fonts for non UTF-8 CJK locales * Change encoding name for zh_CN (x-IBM1383) and zh_TW (x-IBM950) locale * Add taiwanese entries to support East Asian TrueType fonts * Add Unicode font into Thai UTF-8 locale * Unicode font's encoding name is changed to iso10646-1, because previous encoding name has underscore character -- src/java.desktop/share/classes/sun/font/SunFontManager.java If font file (which is defined into fontconfig.properties file) is missing, default physical font is used. But Java refers "dialog" font, then ClassCastException is happened. To avoid ClassCastException, set Dialog font's slot 0 font to default physical font Thanks, Ichiroh Takiguchi On 2019-06-04 01:33, Ichiroh Takiguchi wrote: > Hello. > > Could you review the fix and give me your suggestion, please ? > I'd like to put some solution into JDK13 for this issue. > > Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 > > And I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > > On 2019-05-24 21:55, Ichiroh Takiguchi wrote: >> Hello. >> >> Could you review the fix and give me your suggestion, please ? >> I really appreciate your feedback. >> >> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >> >> And I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-05-14 21:13, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> I appreciate your comment. >>> >>> I tried to debug this issue from another side. >>> I checked fontconfig.properties file by CompileFontConfig (.bfc build >>> tool) with -verbose option [1] >>> Following messages were displayed: >>> Note: 'filename' entry is undefined for >>> "-monotype-sanswt-medium-r-normal--*-%d-75-75-*-*-ucs2.cjk_japan-0" >>> ... >>> I could find out encoding name has "_" character. >>> And '_' -> ' ' conversion was in FontConfiguration. >>> >>> I applied following fixes: >>> src/java.desktop/share/classes/sun/awt/FontConfiguration.java >>> * '_' -> ' ' conversion only applies before PIXEL_SIZE field on XLFD >>> * fontconfig.bfc is built by boot compiler, so above fix does not >>> affect. >>> After reading fontconfig.bfc, data need to be modified >>> src/java.desktop/unix/classes/sun/awt/X11FontManager.java >>> * Fix typo for logging output >>> >>> Could you review the fix again ? >>> >>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.02/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>> >>> I'd like to obtain a sponsor for this issue. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> >>> On 2019-04-26 05:41, Phil Race wrote: >>>> I am not sure about this. It would seem better to fix the config >>>> file. >>>> Other config files have been carefully written to use the real XLFD >>>> and if it changes in a different release, then you provide a new >>>> one with the specific release file. >>>> >>>> Also I have no way to test this works for AIX, all I can say for >>>> sure >>>> is that it will add extra overhead on other platforms. >>>> >>>> Also I am puzzled when I see this : >>>> ?449???????????????? && >>>> "FILE_NAMES_ALIASES".equals(st.sval)) { >>>> >>>> and then go read about this unfamiliar syntax : >>>> https://www.x.org/archive/X11R7.5/doc/man/man1/mkfontdir.1.html >>>> >>>> I just can't imagine what the AIX fonts.alias file must look like >>>> as your code is parsing XLFDs but that syntax is used to >>>> say that the file might not have anything like that, instead if >>>> a font is in a file called "DejaVuSans.ttf" that "DejaVuSans" is >>>> automatically an X11 alias for that font, without any XLFDs involved >>>> .. >>>> At least that's how I read it. >>>> Your code seems to expect that line at the beginning >>>> and then says "and the rest of the file is aliases I want to read". >>>> SFAICT it is perfectly legitimate to NOT have that line or have it >>>> in? a random place, and your code is broken. >>>> >>>> -phil. >>>> >>>> >>>> On 4/25/19 5:27 AM, Ichiroh Takiguchi wrote: >>>>> (Sorry, please ignore previous mail, it has wrong link for >>>>> "Change") >>>>> >>>>> Hello Phil. >>>>> >>>>> I appreciate your suggestion. >>>>> >>>>> I could find out the root cause. >>>>> XLFD format font name (which was on AIX's fontconfig.properties >>>>> file) is not included >>>>> into fonts.dir (fonts.scale) file. >>>>> It was in fonts.alias file. >>>>> It seems that Java could not find font file on fonts.dir, >>>>> then it tried to use XLFD format font name to load X11's font for >>>>> logical font. >>>>> >>>>> On AIX platform, TrueType font files had been changed several >>>>> times. >>>>> XLFD format font names were registered into fonts.alias file for >>>>> compatibility. >>>>> >>>>> On this condition, I think adding fonts.alias support feature is >>>>> better than >>>>> fixing AIX's fontconfig.properties file. >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.01/ >>>>> >>>>> I'd like to obtain a sponsor for this issue. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> >>>>> On 2019-04-20 03:55, Phil Race wrote: >>>>>> Something must have gone wrong upstream to have this font >>>>>> registered >>>>>> as a native font. >>>>>> You should trace back to find out. I suggest to start with this >>>>>> code >>>>>> in SunFontManager.java, >>>>>> where I am guessing you don't have the file name for some reason. >>>>>> >>>>>> ??? protected void registerFontFile(String fontFileName, >>>>>> String[] >>>>>> nativeNames, >>>>>> >>>>>> int fontRank, boolean defer) { >>>>>> //????? REMIND: case compare depends on platform >>>>>> ??????? if (registeredFontFiles.contains(fontFileName)) { >>>>>> ??????????? return; >>>>>> ??????? } >>>>>> ??????? int fontFormat; >>>>>> ??????? if (ttFilter.accept(null, fontFileName)) { >>>>>> ??????????? fontFormat = FONTFORMAT_TRUETYPE; >>>>>> ??????? } else if (t1Filter.accept(null, fontFileName)) { >>>>>> ??????????? fontFormat = FONTFORMAT_TYPE1; >>>>>> ??????? } else { >>>>>> ??????????? fontFormat = FONTFORMAT_NATIVE;? /// <<<<< >>>>>> I >>>>>> think you are getting here, but why ? >>>>>> ??????? } >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 4/19/19 5:18 AM, Ichiroh Takiguchi wrote: >>>>>>> Hello Phil. >>>>>>> >>>>>>> I'm using standard OpenJDK JDK13 b13 for AIX, like: >>>>>>> openjdk version "13-internal" 2019-09-17 >>>>>>> OpenJDK Runtime Environment (build 13-internal+0-jdk13-13) >>>>>>> OpenJDK 64-Bit Server VM (build 13-internal+0-jdk13-13, mixed >>>>>>> mode) >>>>>>> (Compiled it by myself) >>>>>>> >>>>>>> To see stack trace, I tried following instruction: >>>>>>> ?1. Login to AIX box from another machine >>>>>>> ?2. Login to AIX box from AIX CDE on local AIX box Japanese >>>>>>> locale (Ja_JP) or C locale >>>>>>> ?3. Open terminal, like dtterm on local AIX box >>>>>>> ?4. Start SwingSet2 demo program >>>>>>> ?5. Check java's process id >>>>>>> ?6. Move mouse cursor to 2nd icon (ToolTipDemo) from right side >>>>>>> ?7. Move mouse cursor on cow image to display ToolTip >>>>>>> ?8. Keep moving the mouse cursor slowly, mouse cursor may be >>>>>>> stopped >>>>>>> ??? (I said this situation was "frozen".) >>>>>>> ?9. After Xserver was frozen, execute "kill -3" with java >>>>>>> process id >>>>>>> 10. Then stack trace is displayed >>>>>>> >>>>>>> "AWT-EventQueue-0" #14 prio=6 os_prio=57 cpu=1362.57ms >>>>>>> elapsed=31.90s tid=0x0000000113f44800 nid=0x1516 runnable >>>>>>> [0x0000000114159000] >>>>>>> ?? java.lang.Thread.State: RUNNABLE >>>>>>> ??? at >>>>>>> sun.font.NativeFont.countGlyphs(java.desktop at 13-internal/Native >>>>>>> Method) >>>>>>> ??? at >>>>>>> sun.font.NativeFont.getNumGlyphs(java.desktop at 13-internal/NativeFont.java:312) >>>>>>> ??? at >>>>>>> sun.font.NativeFont.(java.desktop at 13-internal/NativeFont.java:90) >>>>>>> ??? at >>>>>>> sun.font.SunFontManager.registerFontFile(java.desktop at 13-internal/SunFontManager.java:1023) >>>>>>> ??? at >>>>>>> sun.font.SunFontManager.initialiseDeferredFont(java.desktop at 13-internal/SunFontManager.java:946) >>>>>>> ... >>>>>>> >>>>>>> I could recreate same issue on AdoptOpenJDK JDK12 with Hotspot >>>>>>> JVM. >>>>>>> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> >>>>>>> On 2019-04-19 05:20, Phil Race wrote: >>>>>>>> On startup ? >>>>>>>> What is the Java stack trace that gets you into that call ? >>>>>>>> Is it this with any modified IBM code, or pure OpenJDK ? >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 4/17/19 11:55 PM, Ichiroh Takiguchi wrote: >>>>>>>>> Hello Phil. >>>>>>>>> >>>>>>>>> I appreciate your reply. >>>>>>>>> I put problem analysis information in JDK-8221741 [1]. >>>>>>>>> >>>>>>>>> The issue is AIX's Xserver was frozen about 25 secs on my local >>>>>>>>> AIX box. >>>>>>>>> According to my problem analysis, >>>>>>>>> In this case, Java tried to load large 11 X11 bitmap fonts via >>>>>>>>> XLoadQueryFont() on Xlib. >>>>>>>>> The situation can emulate by "xlsfonts -ll" command, like: >>>>>>>>> >>>>>>>>> $ time xlsfonts -ll -fn >>>>>>>>> "-monotype-sansmonowt-medium-r-normal--*-80-72-72-*-*-ucs2.cjk_japan-0" >>>>>>>>> ... >>>>>>>>> real??? 0m2.07s >>>>>>>>> user??? 0m0.00s >>>>>>>>> sys 0m0.00s >>>>>>>>> >>>>>>>>> One of solution is, Unix's fontconfig.properties can support >>>>>>>>> TrueType/Type1 font name format. [2] >>>>>>>>> >>>>>>>>> Anyway, >>>>>>>>> I don't know the reason why X11 bitmap font is required for >>>>>>>>> logical font. >>>>>>>>> (I don't know how to use X11 bitmap font for physical font. >>>>>>>>> I could not see X11 bitmap font name via >>>>>>>>> GraphicsEnvironment.getLocalGraphicsEnvironment().getAvailableFontFamilyNames().) >>>>>>>>> I just want to fix Xserver frozen issue. >>>>>>>>> I appreciate your advice. >>>>>>>>> (Other solutions are welcome) >>>>>>>>> >>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Ichiroh Takiguchi >>>>>>>>> IBM Japan, Ltd. >>>>>>>>> >>>>>>>>> On 2019-04-04 01:09, Philip Race wrote: >>>>>>>>>> On 4/2/19, 9:27 AM, Ichiroh Takiguchi wrote: >>>>>>>>>>> Hello. >>>>>>>>>>> (I am sorry to post it again. Previously, I posted the wrong >>>>>>>>>>> mailing list.) >>>>>>>>>>> >>>>>>>>>>> Could you review the fix ? >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8221741 >>>>>>>>>>> Change: >>>>>>>>>>> https://cr.openjdk.java.net/~itakiguchi/8221741/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> I'd like to obtain a sponsor for this issue. >>>>>>>>>>> >>>>>>>>>>> On AIX platform, fontconfig.properties file is used to pick >>>>>>>>>>> up proper fonts. >>>>>>>>>>> TrueType font settings are written by XLFD format on >>>>>>>>>>> fontconfig.properties file. >>>>>>>>>>> >>>>>>>>>>> On current implementation, Java tries to load X11 bitmap >>>>>>>>>>> fonts even if these are not used. >>>>>>>>>> >>>>>>>>>> I think you need to clarify what you mean here. >>>>>>>>>> >>>>>>>>>> I'd like you to provide a step by step analysis of what >>>>>>>>>> happens and >>>>>>>>>> what the effect of your proposed change is on AIX *AND* what >>>>>>>>>> it might >>>>>>>>>> mean for other X11 platforms, as I don't have time to reverse >>>>>>>>>> engineer the >>>>>>>>>> reasons for the odd-looking change. >>>>>>>>>> It looks like a hack to short-circuit support your syntax. >>>>>>>>>> Right now I am saying no to this. >>>>>>>>>> >>>>>>>>>>> This font load work is almost name as "xlsfonts -ll". >>>>>>>>>>> It spends many CPU time and memories. >>>>>>>>>>> >>>>>>>>>>> Just font name format should be supported. >>>>>>>>>> >>>>>>>>>> Not clear enough for me. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> To SAP representative, >>>>>>>>>>> I have a question about copyright year on >>>>>>>>>>> make/data/fontconfig/aix.fontconfig.properties. >>>>>>>>>>> Please let me know how I should write down copyright year. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Ichiroh Takiguchi >>>>>>>>>>> IBM Japan, Ltd. >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> From alexey.ivanov at oracle.com Mon Jun 24 21:50:43 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 24 Jun 2019 22:50:43 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: Message-ID: Hi Sergey, On 18/06/2019 21:37, Sergey Bylokhov wrote: > Hi, Alexey. > > I guess that the change in doCompare() passed a review because it was > assumed that the code inside will take care of unordered arrays. if we > will drop the doCompare() then probably we need to sort the content of > the arrays before Arrays.equals()? I can't see where doCompare() handled unordered arrays; quite the opposite: doCompare(new String[]{"a", "b"}, new String[]{"a", "b"}) returns true (that is the arrays are *not equal*) whereas the arrays are *equal*. While I run the test, the list of printers always has the same order. We do not sort the array returned by getAllPrinterNames() in PrintServiceLookupProvider.refreshServices(), so I assume Windows returns the installed printers in the same order. Therefore I think sorting the array is not necessary in this case. > On 14/06/2019 11:07, Alexey Ivanov wrote: >> Hi, >> >> Please review the following fix for JDK 13: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8222108 >> webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.00/ >> >> The main goal of this bug was to reduce the minimum refresh time for >> updating remote printer list to facilitate testing. >> >> While working on this bug, I've also done some refactoring. The most >> prominent one is replacing doCompare() with Arrays.equals(). The >> former gives wrong result for equal arrays if the array length is >> greater than 2. Thus this bug can be considered as regression. >> >> Arrays.equals() accepts null parameters and null elements in the >> arrays and always returns the correct result. -- Regards, Alexey From Sergey.Bylokhov at oracle.com Mon Jun 24 23:01:44 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 24 Jun 2019 16:01:44 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: Message-ID: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> On 24/06/2019 14:50, Alexey Ivanov wrote: >> I guess that the change in doCompare() passed a review because it was assumed that the code inside will take care of unordered arrays. if we will drop the doCompare() then probably we need to sort the content of the arrays before Arrays.equals()? > > I can't see where doCompare() handled unordered arrays; quite the opposite: doCompare(new String[]{"a", "b"}, new String[]{"a", "b"}) returns true (that is the arrays are *not equal*) whereas the arrays are *equal*. That was an assumption on how it should work, but it was implemented differently. > While I run the test, the list of printers always has the same order. We do not sort the array returned by getAllPrinterNames() in PrintServiceLookupProvider.refreshServices(), so I assume Windows returns the installed printers in the same order. Therefore I think sorting the array is not necessary in this case. I do not know, if it is always has the same order then the fix look fine, if we unsure then probably we can tweak it and sort. -- Best regards, Sergey. From alexey.ivanov at oracle.com Tue Jun 25 19:17:41 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 25 Jun 2019 20:17:41 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> Message-ID: Please see the updated webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.01/ On 25/06/2019 00:01, Sergey Bylokhov wrote: > On 24/06/2019 14:50, Alexey Ivanov wrote: >>> I guess that the change in doCompare() passed a review because it >>> was assumed that the code inside will take care of unordered arrays. >>> if we will drop the doCompare() then probably we need to sort the >>> content of the arrays before Arrays.equals()? >> >> I can't see where doCompare() handled unordered arrays; quite the >> opposite: doCompare(new String[]{"a", "b"}, new String[]{"a", "b"}) >> returns true (that is the arrays are *not equal*) whereas the arrays >> are *equal*. > > That was an assumption on how it should work, but it was implemented > differently. I see. >> While I run the test, the list of printers always has the same order. >> We do not sort the array returned by getAllPrinterNames() in >> PrintServiceLookupProvider.refreshServices(), so I assume Windows >> returns the installed printers in the same order. Therefore I think >> sorting the array is not necessary in this case. > I do not know, if it is always has the same order then the fix look > fine, if we unsure then probably we can tweak it and sort. The order in which printers are enumerated by EnumPrinters is unspecified. For level 4, the information is queried from the registry. The order for registry enum functions is not guaranteed either. Even though the order of printers has always been the same so far, we cannot rely on this fact. -- Regards, Alexey