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 <jayathirth....@oracle.com> 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 > <Build_failure.txt> > > >> On 16-May-2019, at 10:39 PM, Alexey Ushakov <alexey.usha...@jetbrains.com >> <mailto:alexey.usha...@jetbrains.com>> 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 >> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01>) and verified it >> with the openjdk workspace hg.openjdk.java.net/jdk/client >> <http://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 <jayathirth....@oracle.com >>> <mailto:jayathirth....@oracle.com>> wrote: >>> >>> Hi Alexey, >>> >>> We are trying to test basic calls of Graphics2D as mentioned in >>> https://docs.oracle.com/javase/tutorial/2d/TOC.html >>> <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 <ajit.ghai...@oracle.com >>>> <mailto:ajit.ghai...@oracle.com>> 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 <alexey.usha...@jetbrains.com >>>>> <mailto:alexey.usha...@jetbrains.com>> wrote: >>>>> >>>>> FYI, I’ve rebased our work on top of the latest state of >>>>> http://hg.openjdk.java.net/jdk/jdk <http://hg.openjdk.java.net/jdk/jdk> >>>>> (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>>>> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01>) >>>>> >>>>> Best Regards, >>>>> Alexey >>>>> >>>>>> On 8 May 2019, at 16:19, Alexey Ushakov <alexey.usha...@jetbrains.com >>>>>> <mailto:alexey.usha...@jetbrains.com>> 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 <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 <ajit.ghai...@oracle.com >>>>>>> <mailto:ajit.ghai...@oracle.com>> wrote: >>>>>>> >>>>>>> Hi Alexey, >>>>>>> >>>>>>> I tried building this patch with latest >>>>>>> http://hg.openjdk.java.net/jdk/jdk/ >>>>>>> <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 >>>>>>>> <alexey.usha...@jetbrains.com <mailto:alexey.usha...@jetbrains.com>> >>>>>>>> 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 >>>>>>>> <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/ >>>>>>>>> <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 >>>>>>>>> <http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00> >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Alexey >>>>>>> >>>>>> >>>>> >>>> >>> >> >