Is that on Sierpinski? The main question I still have is whether this
helps other apps. The usage pattern in Sierpinski is fairly specific
and may not translate to all apps (we're still planning on doing this as
it is an easy improvement that doesn't seem to have a down-side, but I
don't
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:
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
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
This is important
Thanks guys
Sent from my iPhone
On Apr 8, 2015, at 9:25 AM, Chris Newland cnewl...@chrisnewland.com 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
Hi Jim,
Definitely discrete GPU on the iMac:
java -cp target/DemoFX.jar -Dprism.verbose=true
com.chrisnewland.demofx.standalone.Sierpinski
Prism pipeline init order: es2 sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing
All my MBP numbers are on integrated Intel graphics as well. I tested on an
old MBP that only has Intel graphics and on my more recent MBP the Nvidia
is deactivated due to a problem with it.
On Wed, Apr 8, 2015 at 1:16 AM, Jim Graham james.gra...@oracle.com wrote:
OK, I took the time to put my
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
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.
If I modify the Sierpinksi program to use moveTo/lineTo/lineTo on a path
and fill the entire path at once the performance improves dramatically
on both Intel and nVidia GPUs. It is faster still if I replace the
triangles with fillRect calls, but not by as large a margin. It would
appear that
Hi,
On Sat, Apr 4, 2015 at 10:31 PM, Chris Newland cnewl...@chrisnewland.com
wrote:
Hi Jim,
-snip
I think my question is:
Does the OpenJFX group think JavaFX is a suitable technology for full
frame rate canvas-style graphics or is the degree of indirection between
application code and
Hi Jim,
The first numbers were for my 27 2011 iMac which runs OSX 10.9 Mavericks.
Here are my numbers for a 2013 MacBook Pro (13 Retina) 2.4 GHz Intel Core
i5 / 8GB / Intel Iris 1536 MB / OSX 10.10.2 Yosemite
I don't get 60fps with either pipeline:
java -Dprism.order=es2 -cp target/classes
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
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
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
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
On 3/30/15 12:04 PM, Jim Graham wrote:
drawPolygon() is a very complex operation that involves things like:
- dealing with only rendering common points of intersection once
An example of the distinction here - try a test case where you execute
the exact same diagonal line primitive 1,000
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
I have filed this now:
https://javafx-jira.kenai.com/browse/RT-40377
On Sat, Mar 28, 2015 at 11:06 AM, Robert Krüger krue...@lesspain.de 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:
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:
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
On Sat, Mar 28, 2015 at 11:22 AM, Chris Newland cnewl...@chrisnewland.com
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
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
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
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.
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
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)
27 matches
Mail list logo
