Canvas performance on Mac OS

Thu Apr 16 20:36:32 UTC 2015

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
>>>>>>>> <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
>>>>>>>> /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
>>>>>>>>>>> <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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
>
>
>