Canvas performance on Mac OS

Tue Apr 14 19:16:51 UTC 2015

Hi Chris,

We identified a fairly localized optimization that we might be able to 
apply to enhance the performance of your Sierpinski program.  We don't 
have any figures yet on whether this will improve other 
applications/benchmarks that people have been discussing, but the 
improvements with your Sierpinski program are quite dramatic on a number 
of platforms and GPUs.

This issue is now being tracked as: 
https://javafx-jira.kenai.com/browse/RT-40533

If others could apply the indicated patch to an OpenJFX build and 
provide feedback on any improvements (or bugs!) that they see, that 
would help.  In the meantime, we have a lot of testing to do to verify 
the correctness of the changes...

			...jim

On 4/8/15 9:25 AM, Chris Newland wrote:
> Hi Jim,
>
> I'll post the verbose prism output from my iMac when I get home.
>
> Just tried this on my Linux workstation and the performance gap is the
> same between es2 and sw so I don't think it's an OSX issue.
>
> uname -a
> Linux chris 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
>
> "$JAVA_HOME/bin/java" -classpath target/DemoFX.jar
> com.chrisnewland.demofx.standalone.Sierpinski
> fps: 1
> fps: 20
> fps: 31
> fps: 32
> fps: 33
> fps: 35
> fps: 34
> fps: 33
>
> "$JAVA_HOME/bin/java" -Dprism.order=sw -classpath target/DemoFX.jar
> com.chrisnewland.demofx.standalone.Sierpinski
> fps: 1
> fps: 54
> fps: 56
> fps: 60
> fps: 59
> fps: 60
> fps: 61
> fps: 61
> fps: 60
>
> This is a Xeon W3520 quad-core HT box with an Nvidia Quadro FX 580
> graphics card running driver 304.125
>
> Regards,
>
> Chris
>
>
> On Wed, April 8, 2015 00:16, Jim Graham wrote:
>> OK, I took the time to put my rMBP on a diet yesterday and find room to
>> install a 10.10 partition.  I get the same numbers for Sierpinski on 10.10,
>> so my theory that something changed in the OGL implementation for 10.10
>> doesn't hold water.
>>
>> But, I then tried it using the integrated graphics.  I get really poor
>> performance using the integrated Intel 4000 graphics, but I get great
>> numbers on the discrete nVidia 650m.  It makes sense that the Intel
>> graphics wouldn't be as powerful as the discrete graphics, but we
>> shouldn't be taxing it that much to make that big of a difference.
>>
>> Just to be sure - is that iMac a dual graphics system, or is it
>> all-AMD-all-the-time?  You can see which GPU is being used if you run it
>> with -Dprism.verbose=true...
>>
>> ...jim
>>
>>
>> On 4/2/15 4:13 PM, Jim Graham wrote:
>>
>>> On my retina MBP (10.8) I get 60fps for es2 and 44fps for sw.  Are you
>>> running a newer version of MacOS?
>>>
>>> ...jim
>>>
>>>
>>> On 3/31/15 3:40 PM, Chris Newland wrote:
>>>
>>>> Hi Hervé,
>>>>
>>>>
>>>> That's a valid question :)
>>>>
>>>>
>>>> Probably because
>>>>
>>>>
>>>> a) All my non-UI graphics experience is with immediate-mode / raster
>>>> systems
>>>>
>>>> b) I'm interested in using JavaFX for particle effects / demoscene /
>>>> gaming so assumed (perhaps wrongly?) that scenegraph was not the way
>>>> to go for that due to the very large number of nodes.
>>>>
>>>> Numbers for my Sierpinski filled triangle example:
>>>>
>>>>
>>>> System: 2011 iMac Core i7 3.4GHz / 20GB RAM / AMD Radeon HD 6970M
>>>> 1024 MB
>>>>
>>>>
>>>> java -Dprism.order=es2 -cp target/classes/
>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>> fps: 23
>>>> fps: 18
>>>> fps: 25
>>>> fps: 18
>>>> fps: 23
>>>> fps: 23
>>>> fps: 19
>>>> fps: 25
>>>>
>>>>
>>>> java -Dprism.order=sw -cp target/classes/
>>>> com.chrisnewland.demofx.standalone.Sierpinski fps: 1
>>>> fps: 54
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>> fps: 60
>>>>
>>>>
>>>> There are never more than 2500 filled triangles on screen. JDK is
>>>> 1.8.0_40
>>>>
>>>>
>>>> I would say there is a performance problem here? (or at least a need
>>>> for documentation so as to set expectations for gc.fillPolygon).
>>>>
>>>> Best regards,
>>>>
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, March 31, 2015 22:00, HervÃ© Girod wrote:
>>>>
>>>>> Why don't you use Nodes rather than Canvas ?
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>>
>>>>>> On Mar 31, 2015, at 22:31, Chris Newland
>>>>>> <cnewland at chrisnewland.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Jim,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks, that makes things much clearer.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was surprised how much was going on under the hood of
>>>>>> GraphicsContext
>>>>>> and hoped it was just magic glue that gave the best of GPU
>>>>>> acceleration where available and immediate-mode-like simple
>>>>>> rasterizing where not.
>>>>>>
>>>>>> I've managed to find an anomaly with GraphicsContext.fillPolygon
>>>>>> where the software pipeline achieves the full 60fps but ES2 can
>>>>>> only manage 30-35fps. It uses lots of overlapping filled triangles
>>>>>> so I expect suffers from the problem you've described.
>>>>>>
>>>>>> SSCCE:
>>>>>> https://github.com/chriswhocodes/DemoFX/blob/master/src/main/java/
>>>>>> com/ch
>>>>>>
>>>>>> risnewland/demofx/standalone/Sierpinski.java
>>>>>>
>>>>>> Was full frame rate canvas drawing an expected use case for
>>>>>> JavaFX or
>>>>>> would I be better off with Graphics2D?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Mon, March 30, 2015 20:04, Jim Graham wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> drawLine() is a very simple primitive that can be optimized
>>>>>>> with a GPU
>>>>>>> shader.  It either looks like a (potentially rotated) rectangle
>>>>>>> or a rounded rect - and we have optimized shaders for both
>>>>>>> cases.  A large number of drawLine() calls turns into simply
>>>>>>> accumulating a large vertex list and uploading it to the GPU
>>>>>>> with an appropriate shader which is very fast.
>>>>>>>
>>>>>>> drawPolygon() is a very complex operation that involves things
>>>>>>> like:
>>>>>>>
>>>>>>>
>>>>>>> - dealing with line joins between segments that don't exist for
>>>>>>>   drawLine() - dealing with only rendering common points of
>>>>>>> intersection once
>>>>>>>
>>>>>>> To handle all of that complexity we have to involve a
>>>>>>> rasterizer that takes the entire collection of lines, analyzes
>>>>>>> the stroke attributes and interactions and computes a coverage
>>>>>>> mask for each pixel in the region. We do that in software
>>>>>>> currently for all pipelines.
>>>>>>>
>>>>>>> For the ES2 pipeline Line.v.Poly is dominated by pure GPU vs
>>>>>>> CPU path
>>>>>>> rasterization.
>>>>>>>
>>>>>>> For the SW pipeline, drawLine is a simplified case of
>>>>>>> drawPolygon and so the overhead of lots of calls to drawLine()
>>>>>>> dominates its performance.
>>>>>>>
>>>>>>> I would expect ES2 to blow the SW pipeline out of the water
>>>>>>> with drawLine() performance (as long as there are no additional
>>>>>>> rendering primitives interspersed in the set of lines).
>>>>>>>
>>>>>>> But, both should be on the same footing for the drawPolygon
>>>>>>> case. Does
>>>>>>> the ES2 pipeline compare similarly (hopefully better than) the
>>>>>>> SW
>>>>>>> pipeline for the polygon case?
>>>>>>>
>>>>>>> One thing I noticed is that we have no optimized case for
>>>>>>> drawLine() on the SW pipeline.  It generates a path containing a
>>>>>>> single MOVETO and LINETO and feeds it to the generalized path
>>>>>>> rasterizer when it could instead compute the rounded/square
>>>>>>> rectangle and render it more directly.  If we added that support
>>>>>>> then I'd expect the SW pipeline to perform the set of drawLine
>>>>>>> calls faster than drawPolygon as well...
>>>>>>>
>>>>>>> ...jim
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 3/28/15 3:22 AM, Chris Newland wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> I've not filed a Jira yet as I was hoping to find time to
>>>>>>>> investigate thoroughly but when I saw your question I thought
>>>>>>>> I'd
>>>>>>>> better add my findings.
>>>>>>>>
>>>>>>>> I believe the issue is in the ES2Pipeline as if I run with
>>>>>>>> -Dprism.order=sw then strokePolygon outperforms the series of
>>>>>>>> strokeLine commands as expected:
>>>>>>>>
>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m line
>>>>>>>> Result:
>>>>>>>> 44fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> java -cp target/DemoFX.jar -Dprism.order=sw
>>>>>>>> com.chrisnewland.demofx.DemoFXApplication -c 500 -m poly
>>>>>>>> Result:
>>>>>>>> 60fps
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will see if I can find the root cause as I've got plenty more
>>>>>>>>   examples where ES2Pipeline performs horribly on my Mac which
>>>>>>>> should have no problem throwing around a few thousand polys.
>>>>>>>>
>>>>>>>> I realise there's a *lot* of indirection involved in making
>>>>>>>> JavaFX
>>>>>>>> support such a wide range of underlying graphics systems but I
>>>>>>>> do think there's a bug here.
>>>>>>>>
>>>>>>>> Will file a Jira if I can contribute a bit more than "feels
>>>>>>>> slow" ;)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Sat, March 28, 2015 10:06, Robert KrÃ¼ger wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is consistent with what I am observing. Is this
>>>>>>>>> something that Oracle is aware of? Looking at Jira, I don't
>>>>>>>>> see that anyone is working on this:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://javafx-jira.kenai.com/issues/?jql=status%20in%20(Op
>>>>>>>>> en%2C% 20%2
>>>>>>>>> 2In%
>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%
>>>>>>>>> 20%20A
>>>>>>>>> ND%2
>>>>>>>>> 0la
>>>>>>>>> bels%20in%20(performance)
>>>>>>>>>
>>>>>>>>> Given that one of the One of the main reasons to use JFX
>>>>>>>>> for me is to be able to develop with one code base for at
>>>>>>>>> least OSX and Windows and
>>>>>>>>> the official statement what JavaFX is for, i.e.
>>>>>>>>>
>>>>>>>>> "JavaFX is a set of graphics and media packages that
>>>>>>>>> enables developers to design, create, test, debug, and
>>>>>>>>> deploy rich client applications that operate consistently
>>>>>>>>> across diverse platforms"
>>>>>>>>>
>>>>>>>>> and the fact that this is clearly not the case currently
>>>>>>>>> (8u40)
>>>>>>>>> as soon as I do something else than simple forms, I run into
>>>>>>>>>   performance/quality problems on the Mac, I am a bit unsure
>>>>>>>>> what to make of all that. Is Mac OSX a second-class citizen
>>>>>>>>> as far as dev resources are concerned?
>>>>>>>>>
>>>>>>>>> Tobi and Chris, have you filed Jira Issues on Mac graphics
>>>>>>>>> performance that can be tracked?
>>>>>>>>>
>>>>>>>>> I will file an issue with a simple test case and hope for
>>>>>>>>> the best.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Fri, Mar 27, 2015 at 11:08 PM, Chris Newland
>>>>>>>>> <cnewland at chrisnewland.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Possibly related:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I can reproduce a massive (90%) performance drop on OSX
>>>>>>>>>> between drawing a wireframe polygon on a Canvas using a
>>>>>>>>>> series of gc.strokeLine(double x1, double y1, double x2,
>>>>>>>>>> double y2) commands versus using a single
>>>>>>>>>> gc.strokePolygon(double[] xPoints, double[] yPoints, int
>>>>>>>>>> count) command.
>>>>>>>>>>
>>>>>>>>>> Creating the polygons manually with strokeLine() is
>>>>>>>>>> significantly faster using the ES2Pipeline on OSX.
>>>>>>>>>>
>>>>>>>>>> This is reproducible in a little GitHub JavaFX
>>>>>>>>>> benchmarking project I've created:
>>>>>>>>>> https://github.com/chriswhocodes/DemoFX
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Build with ant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Run with:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> # use strokeLine
>>>>>>>>>> ./run.sh -c 5000 -m line
>>>>>>>>>> result: 60 (sixty) fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> # use strokePolygon
>>>>>>>>>> ./run.sh -c 5000 -m poly
>>>>>>>>>> result: 6 (six) fps
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> System is 2011 iMac 27" / Mavericks / 3.4GHz Core i7 /
>>>>>>>>>> 20GB RAM
>>>>>>>>>> /
>>>>>>>>>> Radeon
>>>>>>>>>> 6970M 1024MB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Looking at the code paths in
>>>>>>>>>> javafx.scene.canvas.GraphicsContext:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gc.strokeLine() maps to writeOp4(x1, y1, x2, y2,
>>>>>>>>>> NGCanvas.STROKE_LINE)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gc.strokePolygon() maps to writePoly(xPoints, yPoints,
>>>>>>>>>> nPoints, true, NGCanvas.STROKE_PATH) which involves
>>>>>>>>>> significantly more work with adding to and flushing a
>>>>>>>>>> GrowableDataBuffer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I've not had time to dig any deeper than this but it's
>>>>>>>>>> surely a bug when building a poly manually is 10x faster
>>>>>>>>>> than using the convenience method.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Chris
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, March 27, 2015 21:26, Tobias Bley wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> In my opinion the whole graphics performance on MacOSX
>>>>>>>>>>> isnÃ¢â‚¬â„¢t good at all with JavaFXÃ¢â‚¬Â¦.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Am 27.03.2015 um 22:10 schrieb Robert KrÃƒÂ¼ger
>>>>>>>>>>>> <krueger at lesspain.de>:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The bad full screen performance is without the arcs.
>>>>>>>>>>>> It is
>>>>>>>>>>>> just one call to fillRect, two to strokeOval and one
>>>>>>>>>>>> to fillOval, that's all. I will build a simple test
>>>>>>>>>>>> case and file an issue.
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Mar 27, 2015 at 9:58 PM, Jim Graham
>>>>>>>>>>>> <james.graham at oracle.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Robert,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please file a Jira issue with a simple test case.
>>>>>>>>>>>>> Arcs
>>>>>>>>>>>>> are handled as a generalized shape rather than via a
>>>>>>>>>>>>>   predetermined shader, but it shouldn't be that
>>>>>>>>>>>>> slow. Something else may
>>>>>>>>>>>>> be going on.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Another test might be to replace the arcs with
>>>>>>>>>>>>> rectangles or ellipses and see if the performance
>>>>>>>>>>>>> changes...
>>>>>>>>>>>>>
>>>>>>>>>>>>> ...jim
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 3/27/15 1:52 PM, Robert KrÃƒÂ¼ger wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a super-simple animation implemented using
>>>>>>>>>>>>>>   AnimationTimer
>>>>>>>>>>>>>> and Canvas where the canvas just performs a few
>>>>>>>>>>>>>> draw operations, i.e. fills the screen with a
>>>>>>>>>>>>>> color and then draws and fills 2-3 circles and I
>>>>>>>>>>>>>> have already observed that each drawing operation
>>>>>>>>>>>>>> I add, results in
>>>>>>>>>>>>>> significant CPU load (e.g. when I draw < 10 arcs
>>>>>>>>>>>>>> in addition to the circles, the CPU load goes up
>>>>>>>>>>>>>> to 30-40% on a Mac Book Pro for a Canvas size of
>>>>>>>>>>>>>> 600x600(!).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now I tested the animation in full screen mode
>>>>>>>>>>>>>> (only
>>>>>>>>>>>>>> with a few circles) and playback is unusable for a
>>>>>>>>>>>>>>   serious application (very choppy). Is 2D canvas
>>>>>>>>>>>>>> performance known to be very bad on Mac or am I
>>>>>>>>>>>>>> doing something wrong? Are there workarounds for
>>>>>>>>>>>>>> this?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Robert
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Robert KrÃƒÂ¼ger
>>>>>>>>>>>> Managing Partner
>>>>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> www.lesspain-software.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Robert KrÃ¼ger
>>>>>>>>> Managing Partner
>>>>>>>>> Lesspain GmbH & Co. KG
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> www.lesspain-software.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>
>