Confirmed, full 60fps performance on 2011 iMac with this fix: /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/bin/java -cp target/DemoFX.jar com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 23 fps: 19 fps: 26 fps: 21 fps: 21 fps: 26 fps: 17
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk_PATCHED/Contents/Home/bin/java -cp target/DemoFX.jar com.chrisnewland.demofx.standalone.Sierpinski fps: 1 fps: 53 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 fps: 60 I've uploaded OSX SDK overlay builds containing this webrev to http://108.61.191.178/ if anyone wants to test the fix on their OSX system. Thanks a lot Jim and team for looking into this! Cheers, Chris On Thu, April 16, 2015 09:39, Chris Newland wrote: > Hi Jim, > > > Thanks for looking into this. > > > The patch definitely improves es2 performance on Debian Linux amd64 from > around 33fps to around 53fps for me (nVidia FX580). > > I've made patched overlay builds of OpenJFX (Linux) 8 and 9 available on > my OpenJFX CI server for anyone who wants to try it: http://108.61.191.178/ > > > Will test on OSX tonight. > > > Cheers, > > > Chris > > > > On Tue, April 14, 2015 20:16, Jim Graham wrote: > >> 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 >>>>>>>> <cnewl...@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 >>>>>>>> /j >>>>>>>> ava/ 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 >>>>>>>>>>> %2 >>>>>>>>>>> 0(Op >>>>>>>>>>> en%2C% 20%2 2In% >>>>>>>>>>> 20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(m >>>>>>>>>>> aco sx)% 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 >>>>>>>>>>> <cnewl...@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 >>>>>>>>>>>>>> <krue...@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.gra...@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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>> >>> >> > > >
