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 want
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/JavaVirtualMachin
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://
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 y
This is important
Thanks guys
Sent from my iPhone
> On Apr 8, 2015, at 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
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 pow
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_HO
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 wrote:
> OK, I took the time to put my rMBP on a diet yesterda
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 we
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
Hi,
On Sat, Apr 4, 2015 at 10:31 PM, Chris Newland
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 the graphics har
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
co
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
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
Why don't you use Nodes rather than Canvas ?
Sent from my iPhone
> On Mar 31, 2015, at 22:31, Chris Newland 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 t
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 wi
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 ti
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 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://jav
On Sat, Mar 28, 2015 at 11: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.
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
comman
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%22In%20Progress%22%2C%20Reopened)%20AND%20labels%20in%20(macosx)%20%20AND%20label
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) comma
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 :
>
> 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
>
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 wrote:
> Hi Robert,
>
> Please file a Jira issue with a simple t
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 p
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 lo
27 matches
Mail list logo
