[OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework

Ajit Ghaisas ajit.ghaisas at oracle.com
Tue Jun 11 09:01:34 UTC 2019 

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> 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/20190611/e1bfbc82/attachment-0001.html>

More information about the 2d-dev mailing list