Canvas performance on Mac OS

Thu Apr 2 23:13:51 UTC 2015

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(Open%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
>>>
>>>
>>
>
>