[OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework
Jayathirth Rao
jayathirth.d.v at oracle.com
Wed Jun 12 15:37:13 UTC 2019
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 <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 <ajit.ghaisas at oracle.com> 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 <jayathirth.d.v at oracle.com <mailto:jayathirth.d.v at 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.ushakov at jetbrains.com <mailto:alexey.ushakov at 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.d.v at oracle.com <mailto:jayathirth.d.v at 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.ghaisas at oracle.com <mailto:ajit.ghaisas at 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.ushakov at jetbrains.com <mailto:alexey.ushakov at 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.Ushakov at jetbrains.com <mailto:Alexey.Ushakov at 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.ghaisas at oracle.com <mailto:ajit.ghaisas at 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.ushakov at jetbrains.com <mailto:alexey.ushakov at 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/2d-dev/attachments/20190612/316ffe99/attachment-0001.html>
More information about the 2d-dev
mailing list