Canvas performance on Mac OS

Thu Apr 16 20:41:10 UTC 2015

Yes, that is indeed what I'm doing.

- Johan

2015-04-16 22:05 GMT+02:00 Tobias Bley <tobi at ultramixer.com>:

> Hi Johan,
>
> I would like to test it on iPad 1 and iPhone 4, would it be possible now
> via JavaFXPorts-Gradle-Plugin?
>
> Best,
> Tobi
>
>
> > Am 16.04.2015 um 21:58 schrieb Johan Vos <johan at lodgon.com>:
> >
> > Hi Jim,
> >
> > On iOS, the performance jumped from 2 fps to 15 fps on my old iPad.
> > Excellent work!
> >
> > - Johan
> >
> > 2015-04-14 21:16 GMT+02:00 Jim Graham <james.graham at oracle.com>:
> >
> >> 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
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
>
>