subject:"JavaFX graphics performance"

Re: JavaFX graphics performance

2017-04-18 Thread Chien Yang


Hi Michael,

Yes, this is a server bug and a backport to 8u and 9 is also being 
consider at this moment. Thanks for bringing it to our attention.


Thanks,
- Chien

On 4/18/17, 2:22 AM, Michael Paus wrote:

Hi

In
https://bugs.openjdk.java.net/browse/JDK-8178804
"Excessive memory consumption in TriangleMesh/MeshView"
you wrote:
There is a missing divide (by VERTEX_SIZE_VB) when computing the 
growth of vertexBuffer array as needed. Hence it has the potential of 
creating a vertexBuffer and some cached data to 9 times as big as 
designed. However this bug only affect Mesh with 
VertexFormat.POINT_NORMAL_TEXCOORD.


This somehow contradicts your last comment in
https://bugs.openjdk.java.net/browse/JDK-8089605
"[3D] TriangleMesh/MeshView high memory/CPU usage"
Application should use the new user-defined normals format for dynamic 
mesh to avoid high memory and CPU usage.


I hope the bug fix will also be backported to Java 8.
Michael

Am 12.04.17 um 22:19 schrieb Chien Yang:
BTW, it is a bug that we are unaware of if you are seeing a 60X 
nominal memory consumption in your program.  Please file a JIRA with 
a test program and we will investigate it.


Thanks,

- Chien


On 4/10/2017 1:08 PM, Kevin Rushforth wrote:
We are planning some performance improvements in JDK 10, mostly in 
the areas of CSS and layout. If you have specific concerns in other 
areas we could look into them. Having a specific test case that 
shows a performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of 
the arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly 
and JavaFX currently
has not much to offer here. Actually the general drawing 
performance is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are 
already any plans for Java 10

to improve this situation?

Michael

Re: JavaFX graphics performance

2017-04-18 Thread Nikos Nikolos

Thanks Mattias for your time on the subject.

I share some of your views on Qt and the complexity of data structures to
ensure best performance. But the Swing team did open the API to allow JOGL
first, now called JOGAMP to propose a nice binding to OpenGL. This way one
can use Java Swing and all its good parts to do the non performance
critical stuff and go with the low level binding of OpenGL to draw
performance intensive stuff.

Off course that meant direct buffers, native libraries and the risk to
crash the VM, but still staying in the "java realm".



I want to be able to reuse long crafted JOGL code in JavaFX but I can't
since it doesn't provide OpenGL context directly and using a JOGAMP
GLCanvas into a SwingNode is bit blit performance nightmare!

Considering a science application displaying 2D or 3D dynamic images with a
small amount of

I'll rather port my OpenGL code to fully OpenGL ES 3.0 and use web
technologies than  try to mess with JavaFX.

I'm quite disappointed by the fact that JavaFX doesn’t even consider this
need as relevant, that’s why I try to argue and understand. I can image
that these needs are too specific for the JavaFX team but I see it as a
leave for Oracle/Java to stay in the desktop GUI technology.



I am a user of Java Swing since 1999, used QT too, and was happy to go on
with Java so, once again, it make me sad…



Regards.
-- Message transféré --
From: Mattias Eliasson <mattias.elias...@medsa.se>
To: openjfx-dev@openjdk.java.net
Cc:
Bcc:
Date: Fri, 14 Apr 2017 15:04:20 +0200
Subject: Re: JavaFX graphics performance
If what you want is the best performance than neither JavaFX nor web
technologies will do. Qt as you mentioned will be much faster and it has
native support for embedding OpenGL. In addition you can combine Qt with
native optimizations for specific platforms. You can even add inline
assembly in order to do very specific optimizations. Hand optimized
assembly by a skilled developer will never be outperformed by anything
else. The problem with these things of course is that they add a lot of
work. Writing Qt code requires you to handle memory and threads and I can
constantly see Qt developers failing at this. The VLC UI is written in Qt
and it spits out a decent amount of Qt errors on the conseole, and that is
probably one of the most well written Qt applications. We have the entire
KDE ecosystem based on Qt which is infamous for it's many bugs. And
assembly programming of course is a lot more problematic. In order to
outperform pre-existing system libraries you sometimes need to know
undocumented instructions used by system libraries. This is less of a
problem today than it was 20 years ago but it still takes a lot to be good
at assembly programming.

However this is the JavaFX mailing list so in order to stay on topic I
think the discussion should be about how to improve JavaFX performance.
Some problems of course are related to the JavaFX code itself, others are
rooted in the Java architecture and in JVM memory management. The fact that
doing something similar to C/C++ structs and "pragma align" requires ninja
level trickery is a problem. I don't know if this is a problem for OpenGL
but sometimes when integrating with external systems the lack of "unsigned"
is also a real problem, it's probably not a performance problem but writing
correct code that deals with data containing unisgned integers can be quite
a mess. I don't know OpenGL data structures well enough but in many
Internet protocols there are lots of unsigened data to be processed. Also
many file formats has that problem.

When we are trying to interface Java with low level data such as OpenGL
data structures we must recognise that we may need to take these things
into consideration for upcoming versions of the JVM. One problem of course
are how to deal with these kind of data structures while preserving data
integrity and the Java way of doing bounds checking. This is also a big
issue I have with the current hacks one have to perform in order to deal
with data structures, dealing with large arrays moves the responsibility of
data integrity to the application which of course is a breeding ground for
bugs.

Re: JavaFX graphics performance

2017-04-18 Thread Michael Paus


Hi

In
https://bugs.openjdk.java.net/browse/JDK-8178804
"Excessive memory consumption in TriangleMesh/MeshView"
you wrote:
There is a missing divide (by VERTEX_SIZE_VB) when computing the growth 
of vertexBuffer array as needed. Hence it has the potential of creating 
a vertexBuffer and some cached data to 9 times as big as designed. 
However this bug only affect Mesh with VertexFormat.POINT_NORMAL_TEXCOORD.


This somehow contradicts your last comment in
https://bugs.openjdk.java.net/browse/JDK-8089605
"[3D] TriangleMesh/MeshView high memory/CPU usage"
Application should use the new user-defined normals format for dynamic 
mesh to avoid high memory and CPU usage.


I hope the bug fix will also be backported to Java 8.
Michael

Am 12.04.17 um 22:19 schrieb Chien Yang:
BTW, it is a bug that we are unaware of if you are seeing a 60X 
nominal memory consumption in your program.  Please file a JIRA with a 
test program and we will investigate it.


Thanks,

- Chien


On 4/10/2017 1:08 PM, Kevin Rushforth wrote:
We are planning some performance improvements in JDK 10, mostly in 
the areas of CSS and layout. If you have specific concerns in other 
areas we could look into them. Having a specific test case that shows 
a performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of the 
arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly 
and JavaFX currently
has not much to offer here. Actually the general drawing performance 
is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are 
already any plans for Java 10

to improve this situation?

Michael

Re: JavaFX graphics performance

2017-04-14 Thread Mattias Eliasson

with Swing is a potential solution but it won’t resist a
> comparison with QT long.
> 
> 
> 
> Thanks for any of your ideas on that.
> 
> Regards
> 
> 
> 
> -- Message transféré --
> From: Mattias Eliasson <mattias.elias...@medsa.se>
> To: openjfx-dev@openjdk.java.net
> Cc:
> Bcc:
> Date: Tue, 11 Apr 2017 14:49:10 +0200
> Subject: Re: JavaFX graphics performance
> Excessive memory usage is more of a well documented JDK problem that
> impacts the performance of many applications. Especially when having a
> large collection of instances of the same class. In C++ an array of objects
> are in memory similar to an array of structs. In Java they are arrays of
> pointers to objects on the heap.
> 
> This could of course be worked around by storing data in arrays and using
> classes to wrap those arrays. In one project I stored X and Y coordinates
> in an array. I had a class with getter and setters but also with a
> reference to the array and index. On top of that I had what worked
> similarly to a standard object pool but in fact only had a few instances of
> the object, changing index of a free object rather than allocating a new.
> For simplicity I used an array for X and another for Y.
> 
> This pattern can be refined to align data in various ways for better cache
> performance. And in our case there may be alignments that gives better GPU
> performance. After all it's usually the GPU that process our data.
> 
> Of course it would be best if the JVM had better memory management
> including something similar to a struct array without pointers to objects.
> But there would still be need to have refinements. For example is it better
> to have XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache
> infrastructure, the order data is accessed and other factors.
> 
> In order notes the main competition to JavaFX is other Java APIs such as
> Swing and it's Java2D. When it comes to performance we obviously have a
> clear winner. But JavaFX isn't shipped within major Linux distributions so
> it is yet considered experimental by many that use Swing. There are also
> competition from SWT used by Eclipse and Azureus/Vuze. Packaging is one
> problem but there are also UI components missing. The SWT on JavaFX
> implementation has a list of SWT components and their JavaFX counterpart.
> That list illustrates that there are a lot of work to do.
> 
> Of course once SWT on JavaFX is complete SWT will be eliminated as
> competition. Especially if Eclipse use JavaFX as its SWT backend. It would
> also mean that JavaFX is better equipped to compete with Swing as SWT
> already is a strong competitor to Swing.
> 
> However SWT has been held back due to stability problems which probably
> will not be in the way when it's based on JavaFX which is good enterprise
> code.
> 
> As for competing with web technologies it would have helped if we had a
> modern browser plugin. JavaFX as an UI may not be faster than browser
> technologies. But Java bytecode is a lot faster than JavaScript. Take RPC
> for example. If you use browser technology you would probably be using Json
> at best. With Java you have binary protocols like Jboss Remoting which ia
> easy to code and much faster than using Json in JavaScript.
> 
> Web technologies can only compete where there is an API implemented in
> something other than JavaScript. Once processing is done in JavaScript the
> it becomes a lot slower than Java.
> 
> I would suggest creating a new fully sandboxed applet technology based on
> JavaFX instead of AWT/Swing. That of course would be incompatible with
> classic Applets but those are dead anyway. Make it at least as good as
> Flash perhaps with an IDE like the commercial flash IDE. I mean
> activescript vs Hotspot will not be a very fair match.
> 
> Another competitor is Unity and similar game engines. As unity is based on
> mono and MonoDevelop we could do something similar using Java and eclipse.
> 
> When it comes to web/client server Vaadin has been gaining a lot of ground.
> It's model of having a combined client and server code base using byte
> buddy or ASM to separate client and server into separate executables is
> impressive. I would like more control such as specifying @client or @server
> in order to control where execution take place. But more to the point I
> would like a JavaFX UI.
> 
> While web technologies are moving in on Java they do have a far way to go
> before they have what java has. We have Hotspot for starters and that's way
> ahead of JavaScript and Flash. What we don't have is browser integration.
> 
> Let's take the lessons learned from both Flash and Java Applets and make
> something awesome. That doesn't carry &q

Re: JavaFX graphics performance

2017-04-13 Thread Kevin Rushforth

Thank you. We'll take a look at them. The "Excessive memory consumption" 
should be transfered to the JDK project in a day or two.


-- Kevin


Michael Paus wrote:

Hi,
I have done that already here

"Severe performance drop for scene graph path rendering."
https://bugs.openjdk.java.net/browse/JDK-8178521

and another one for which I do not have the link yet.

"Excessive memory consumption in TriangleMesh/MeshView"
Internal review ID : 9048570

Michael


Am 10.04.17 um 22:08 schrieb Kevin Rushforth:
We are planning some performance improvements in JDK 10, mostly in 
the areas of CSS and layout. If you have specific concerns in other 
areas we could look into them. Having a specific test case that shows 
a performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of the 
arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly 
and JavaFX currently
has not much to offer here. Actually the general drawing performance 
is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are 
already any plans for Java 10

to improve this situation?

Michael

Re: JavaFX graphics performance

2017-04-12 Thread Chien Yang

BTW, it is a bug that we are unaware of if you are seeing a 60X nominal 
memory consumption in your program.  Please file a JIRA with a test 
program and we will investigate it.


Thanks,

- Chien


On 4/10/2017 1:08 PM, Kevin Rushforth wrote:
We are planning some performance improvements in JDK 10, mostly in the 
areas of CSS and layout. If you have specific concerns in other areas 
we could look into them. Having a specific test case that shows a 
performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of the 
arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly 
and JavaFX currently
has not much to offer here. Actually the general drawing performance 
is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are already 
any plans for Java 10

to improve this situation?

Michael

Re: JavaFX graphics performance

2017-04-11 Thread Nikos Nikolos

Here is a copy of a previous post I sent, needs are still the same on my
side and I don't see anything coming from the JavaFX side...


OpenGL rendering was a nice solution for performance intensive application
on the desktop. Since JavaFX doesn't offer a native OpenGL handle you can
use such a solution.


CSS and layout improvement are quite out of scope for the inital needs I
think.


Electron is becoming trendy maybe with some WebGL inside it you will be
able to outperform JavaFX rendering speed!


I really enjoyed desktop GUI development in Java but them came JavaFX...




Following the thread http://mail.openjdk.java.net/
pipermail/openjfx-dev/2016-December/020025.html I would like to ask for
more information on JavaFX plan to allow a simple way to use existing
OpenGL code.



I know this is not a new question and please forgive me if I’ve overlooked
some answers already posted.



I work in the niche area where desktop applications are still needed and
use Swing since 2001, integrated Jogl and then Jogamp since 2006 and that
try to figure out how we can use JavaFX without a huge performance drop. I
think this bug https://bugs.openjdk.java.net/browse/JDK-8091324 is the best
summary of potential needs. And the answer gave by Kevin Rushforth was
quite disappointing.



I remember Swing teams members (Kenneth Bradley Russell) working hard to
have a nice way to use OpenGL in a platform independent manner which is one
of the strength of Java. JOGAMP team also made a good work more recently.



Some tricks have been used to try to provide a solution:

· https://github.com/SkyLandTW/JOGL-FX#jogl-on-javafx-es2

· https://github.com/pepe1914/jfx-zoglpipeline

· https://www.youtube.com/watch?v=aYRF34UYu-E

But they are very fragile (use of internal classes, rebundling JavaFx
jars…).



Is this need too specific for a change to have it implemented in JavaFX?

Going on with Swing is a potential solution but it won’t resist a
comparison with QT long.



Thanks for any of your ideas on that.

Regards



-- Message transféré --
From: Mattias Eliasson <mattias.elias...@medsa.se>
To: openjfx-dev@openjdk.java.net
Cc:
Bcc:
Date: Tue, 11 Apr 2017 14:49:10 +0200
Subject: Re: JavaFX graphics performance
Excessive memory usage is more of a well documented JDK problem that
impacts the performance of many applications. Especially when having a
large collection of instances of the same class. In C++ an array of objects
are in memory similar to an array of structs. In Java they are arrays of
pointers to objects on the heap.

This could of course be worked around by storing data in arrays and using
classes to wrap those arrays. In one project I stored X and Y coordinates
in an array. I had a class with getter and setters but also with a
reference to the array and index. On top of that I had what worked
similarly to a standard object pool but in fact only had a few instances of
the object, changing index of a free object rather than allocating a new.
For simplicity I used an array for X and another for Y.

This pattern can be refined to align data in various ways for better cache
performance. And in our case there may be alignments that gives better GPU
performance. After all it's usually the GPU that process our data.

Of course it would be best if the JVM had better memory management
including something similar to a struct array without pointers to objects.
But there would still be need to have refinements. For example is it better
to have XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache
infrastructure, the order data is accessed and other factors.

In order notes the main competition to JavaFX is other Java APIs such as
Swing and it's Java2D. When it comes to performance we obviously have a
clear winner. But JavaFX isn't shipped within major Linux distributions so
it is yet considered experimental by many that use Swing. There are also
competition from SWT used by Eclipse and Azureus/Vuze. Packaging is one
problem but there are also UI components missing. The SWT on JavaFX
implementation has a list of SWT components and their JavaFX counterpart.
That list illustrates that there are a lot of work to do.

Of course once SWT on JavaFX is complete SWT will be eliminated as
competition. Especially if Eclipse use JavaFX as its SWT backend. It would
also mean that JavaFX is better equipped to compete with Swing as SWT
already is a strong competitor to Swing.

However SWT has been held back due to stability problems which probably
will not be in the way when it's based on JavaFX which is good enterprise
code.

As for competing with web technologies it would have helped if we had a
modern browser plugin. JavaFX as an UI may not be faster than browser
technologies. But Java bytecode is a lot faster than JavaScript. Take RPC
for example. If you use browser technology you would probably be using Json
at best. With Java you have binary protocols like Jboss Remoting which i

Re: JavaFX graphics performance

2017-04-11 Thread Mattias Eliasson

Excessive memory usage is more of a well documented JDK problem that impacts 
the performance of many applications. Especially when having a large collection 
of instances of the same class. In C++ an array of objects are in memory 
similar to an array of structs. In Java they are arrays of pointers to objects 
on the heap.

This could of course be worked around by storing data in arrays and using 
classes to wrap those arrays. In one project I stored X and Y coordinates in an 
array. I had a class with getter and setters but also with a reference to the 
array and index. On top of that I had what worked similarly to a standard 
object pool but in fact only had a few instances of the object, changing index 
of a free object rather than allocating a new. For simplicity I used an array 
for X and another for Y.

This pattern can be refined to align data in various ways for better cache 
performance. And in our case there may be alignments that gives better GPU 
performance. After all it's usually the GPU that process our data. 

Of course it would be best if the JVM had better memory management including 
something similar to a struct array without pointers to objects. But there 
would still be need to have refinements. For example is it better to have 
XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache 
infrastructure, the order data is accessed and other factors. 

In order notes the main competition to JavaFX is other Java APIs such as Swing 
and it's Java2D. When it comes to performance we obviously have a clear winner. 
But JavaFX isn't shipped within major Linux distributions so it is yet 
considered experimental by many that use Swing. There are also competition from 
SWT used by Eclipse and Azureus/Vuze. Packaging is one problem but there are 
also UI components missing. The SWT on JavaFX implementation has a list of SWT 
components and their JavaFX counterpart. That list illustrates that there are a 
lot of work to do.

Of course once SWT on JavaFX is complete SWT will be eliminated as competition. 
Especially if Eclipse use JavaFX as its SWT backend. It would also mean that 
JavaFX is better equipped to compete with Swing as SWT already is a strong 
competitor to Swing.

However SWT has been held back due to stability problems which probably will 
not be in the way when it's based on JavaFX which is good enterprise code. 

As for competing with web technologies it would have helped if we had a modern 
browser plugin. JavaFX as an UI may not be faster than browser technologies. 
But Java bytecode is a lot faster than JavaScript. Take RPC for example. If you 
use browser technology you would probably be using Json at best. With Java you 
have binary protocols like Jboss Remoting which ia easy to code and much faster 
than using Json in JavaScript. 

Web technologies can only compete where there is an API implemented in 
something other than JavaScript. Once processing is done in JavaScript the it 
becomes a lot slower than Java. 

I would suggest creating a new fully sandboxed applet technology based on 
JavaFX instead of AWT/Swing. That of course would be incompatible with classic 
Applets but those are dead anyway. Make it at least as good as Flash perhaps 
with an IDE like the commercial flash IDE. I mean activescript vs Hotspot will 
not be a very fair match. 

Another competitor is Unity and similar game engines. As unity is based on mono 
and MonoDevelop we could do something similar using Java and eclipse. 

When it comes to web/client server Vaadin has been gaining a lot of ground. 
It's model of having a combined client and server code base using byte buddy or 
ASM to separate client and server into separate executables is impressive. I 
would like more control such as specifying @client or @server in order to 
control where execution take place. But more to the point I would like a JavaFX 
UI.

While web technologies are moving in on Java they do have a far way to go 
before they have what java has. We have Hotspot for starters and that's way 
ahead of JavaScript and Flash. What we don't have is browser integration.

Let's take the lessons learned from both Flash and Java Applets and make 
something awesome. That doesn't carry "java" in the name. Like OpenFX? Or 
"Arrow" (yeah I'm a nerd). This including the creative tools that Flash has but 
perhaps also with features that Unity has.

Kevin Rushforth  skrev: (10 april 2017 22:08:04 
CEST)
>We are planning some performance improvements in JDK 10, mostly in the 
>areas of CSS and layout. If you have specific concerns in other areas
>we 
>could look into them. Having a specific test case that shows a 
>performance problem would be a good start.
>
>-- Kevin
>
>
>Michael Paus wrote:
>> Hi,
>>
>> more and more people ask me why I am still doing GUI development in 
>> JavaFX instead
>> of following the  mainstream and use some web technology. One of the 
>> arguments
>> I could use in the past was

Re: JavaFX graphics performance

2017-04-10 Thread Kevin Rushforth

We are planning some performance improvements in JDK 10, mostly in the 
areas of CSS and layout. If you have specific concerns in other areas we 
could look into them. Having a specific test case that shows a 
performance problem would be a good start.


-- Kevin


Michael Paus wrote:

Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of the 
arguments
I could use in the past was performance but nowadays this does not 
seem to be such
a valid argument anymore. Web technologies are catching up quickly and 
JavaFX currently
has not much to offer here. Actually the general drawing performance 
is very bad compared
to what is in principle possible with a modern GPU. I even tried to 
use a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are already 
any plans for Java 10

to improve this situation?

Michael

JavaFX graphics performance

2017-04-10 Thread Michael Paus


Hi,

more and more people ask me why I am still doing GUI development in 
JavaFX instead
of following the  mainstream and use some web technology. One of the 
arguments
I could use in the past was performance but nowadays this does not seem 
to be such
a valid argument anymore. Web technologies are catching up quickly and 
JavaFX currently
has not much to offer here. Actually the general drawing performance is 
very bad compared
to what is in principle possible with a modern GPU. I even tried to use 
a TriangleMesh
to better exploit the graphics hardware but this approach is also 
limited by the fact that
a TrinangleMesh has an excessive memory usage (about 60 times its 
nominal memory
consumption). I would therefore like to ask whether there are already 
any plans for Java 10

to improve this situation?

Michael

Re: JavaFX graphics performance and suitability for advanced animations

2013-06-03 Thread John Hendrikx


On 1/06/2013 02:24, Daniel Zwolenski wrote:

Can anyone recommend any good screen capture software for windows? Not sure
it would capture this problem but it would be useful for some of the other
problems I'm seeing in the TD game that I can't seem to reproduce in small
snippets of code.
I used http://camstudio.org/ before to record a JavaFX program (see here 
for the results: http://www.youtube.com/watch?v=8Mb15bOwIyE)


--John

Re: JavaFX graphics performance and suitability for advanced animations

2013-06-01 Thread Daniel Zwolenski

I tried your pixel snapping one and it is on par with the JScript version,
so it could be that either my system or my eye prefers that option. Good to
know we can switch between them at least to cater for different devices.
That project I captured in the last email had a fixed brand/model of tablet
that it was on so in that case it's good to be able to maximise performance
for that particular device.

I tried to taking screen captures of the different scenarios but it's too
fine detail and the animation just looks crap on all of them in the
captures.

I'm hearing you that this is a messy problem with no ideal, and some
options might be better in case A but worse in case B. Happy to say that
one is done and dusted and not worth going into deeper. I think the trick
will be to use coloured backgrounds - windows metro style.




On Sat, Jun 1, 2013 at 1:59 PM, Richard Bair richard.b...@oracle.comwrote:

  This looks bad for me though in FX, I'm wondering what it looks like for
 you.

 I ran with the pulse logger and definitely there is no frame taking more
 than a couple milliseconds. Things look awful because this example is
 truncating (by casting to int) instead of rounding, and so on each frame
 the rectangle is pixel snapped to a position that may be closer, or farther
 away from the expected location and our brain sees it. To test this theory,
 one thing I did was modify the sample so that instead of taking 3 seconds
 to travel 400 pixels, I use 4 seconds and I removed the EASE_BOTH
 interpolators. In this case the expected location on each frame is exactly
 a pixel boundary, and of course it looks smooth. Note though that the
 border still looks fuzzy (to me) but this is because the refresh rate on
 the monitor or possibly the eye is exhibiting a motion blur.

 public void start(Stage stage) throws Exception {
 final StackPane rootPane = new StackPane();
 VBox box = new VBox();
 box.setMaxSize(200, 200);
 box.setStyle(-fx-border-color: black; -fx-background-color:
 white; -fx-effect: dropshadow(two-pass-box , darkgray, 10, 0.0 , 4, 5););
 rootPane.getChildren().add(box);
 createTranslation(box, 4, -200, -200, 200, 200).play();

 Scene scene = new Scene(rootPane, 1200, 800);
 stage.setScene(scene);
 stage.show();
 }

 protected Animation createTranslation(Node node, int seconds, int
 fromX, int fromY, int toX, int toY) {
 IntegerProperty xProperty = new SimpleIntegerProperty(fromX);
 IntegerProperty yProperty = new SimpleIntegerProperty(fromY);
 node.translateXProperty().bind(xProperty);
 node.translateYProperty().bind(yProperty);

 Timeline t = new Timeline(
 new KeyFrame(Duration.seconds(seconds),
 new KeyValue(xProperty, toX),
 new KeyValue(yProperty, toY)));
 t.setCycleCount(Timeline.INDEFINITE);
 t.setAutoReverse(true);
 return t;
 }




 And here is another version which instead keeps the interpolator and the 3
 second movement (so we're back to unexpected irregular positions) and we
 pixel snap by rounding instead of by truncating.

 public void start(Stage stage) throws Exception {
 final StackPane rootPane = new StackPane();
 VBox box = new VBox();
 box.setMaxSize(200, 200);
 box.setStyle(-fx-border-color: black; -fx-background-color:
 white; -fx-effect: dropshadow(two-pass-box , darkgray, 10, 0.0 , 4, 5););
 rootPane.getChildren().add(box);
 createTranslation(box, 3, -200, -200, 200, 200).play();

 Scene scene = new Scene(rootPane, 1200, 800);
 stage.setScene(scene);
 stage.show();
 }

 class RoundingValue extends SimpleDoubleProperty {
 public RoundingValue(int initialValue) {
 super(initialValue);
 }

 @Override public void set(double newValue) {
 super.set(Math.round(newValue));
 }
 }

 protected Animation createTranslation(Node node, int seconds, int
 fromX, int fromY, int toX, int toY) {
 RoundingValue xProperty = new RoundingValue(fromX);
 RoundingValue yProperty = new RoundingValue(fromY);
 node.translateXProperty().bind(xProperty);
 node.translateYProperty().bind(yProperty);

 Timeline t = new Timeline(
 new KeyFrame(Duration.seconds(seconds),
 new KeyValue(xProperty, toX,
 Interpolator.EASE_BOTH),
 new KeyValue(yProperty, toY,
 Interpolator.EASE_BOTH)));
 t.setCycleCount(Timeline.INDEFINITE);
 t.setAutoReverse(true);
 return t;
 }


 This looks pretty good perhaps this is what you are seeing in the browser?

 Richard

RE: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread John C. Turnbull

 the development team even more than they
are already are.

So, in summary, I am here to help.  Whilst you may not agree with my
methods, please know that I have the best interests of JavaFX and the
community in mind.  I am prepared to do whatever it takes to ensure the
success of JavaFX on a vast variety of platforms and for as long as
possible.  I am going to devote some time into building OpenJFX and trying
to get to the bottom of the performance issues I have informally reported.

If other products can achieve high-quality and high-performance animations
on my computers then why can't JavaFX?  The answers must be out there...

-jct

-Original Message-
From: Richard Bair [mailto:richard.b...@oracle.com] 
Sent: Friday, 31 May 2013 01:12
To: John C. Turnbull
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX graphics performance and suitability for advanced
animations

Hi John,

 Graphics?  Yes, to a point.  But my post was really about graphics and 
 the issues related to performance.  Again, unless those issues are 
 resolved then it's not appropriate to state that JavaFX is suitable for
graphics.

You asked what the full range of applications for which JavaFX is or will
be suitable for.

 Then you mention Halo 5.  I have to say the subtext here troubles me 
 greatly.  If I read you correctly then you are saying that JavaFX is 
 not really suitable for games (at least anything beyond the demands of 
 something like Solitaire).  As someone else pointed out, what is point 
 of developing 3D support in JavaFX if it is not really suitable for 
 games?  To say it is not suitable for games implies that it is not 
 really suitable for *any* application that requires performant 
 animations and visualisations.  What use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D,
and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that are
broader than real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of
them) as well as very specialized tricks for getting the most out of their
graphics cards. When we expose API that allows people to hammer the card
directly, then it would be possible for somebody to build some of the UI in
FX and let their game engine be hand written (in Unity or JOGL or whatever).

 4.   Is JavaFX more targeted at form-based UIs rather than high
 performance graphics?
 
 No.
 
 Again, good to know but where are all the high-performance JavaFX 
 apps?  So far I have seen nothing but form-based apps.  Wouldn't it be 
 prudent for Oracle to include a showcase app or game that shows us 
 the full capabilities of JavaFX with high-performance graphics?
 
 I am sure I am not alone in feeling that the animation examples in 
 Ensemble do very little to promote the graphics capabilities of JavaFX.

Are you offering to contribute? :-)

 Are your slow examples reproducible? If so we need the test case. Is 
 there
 an issue filed? We can't fix things we can't reproduce.
 We spend a *considerable* amount of time and energy on performance 
 and for
 the things we're measuring we're doing well.
 As the saying goes what's measured, improves. After the switch to 
 gradle
 and the new project layout, one thing I'm going to
 look at is using JMH[2] in OpenJFX so we can write micro benchmarks 
 and
 have them easy for everybody to run and
 contribute to. Our current set of micro benchmarks are based on the
 predecessor of JMH which was the
 JRockit benchmark suite and was proprietary (hence we cannot just 
 open
 source our existing benchmarks without doing some rewrite).
 
 All good points.
 
 However, I am not sure that having me preparing reproducible test 
 cases will actually help.  In my experience, the Ensemble app already 
 serves this purpose.  The choppiness I describe is *always* prevalent 
 when I run the animations and transitions in Ensemble (including 
 Ensemble 8).  The only variation is in the degree of that choppiness.

Then start with that, something absolutely dead simple like a path animation
or rotate transition and lets figure out how to measure the jitter and get
it into our benchmark suite.

Richard=

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread steve . x . northover

 to the policies of Oracle
management are not particularly helpful in this forum as clearly nothing I
say here is going to change anything in that respect.  Such comments
probably only serve to frustrate the development team even more than they
are already are.

So, in summary, I am here to help.  Whilst you may not agree with my
methods, please know that I have the best interests of JavaFX and the
community in mind.  I am prepared to do whatever it takes to ensure the
success of JavaFX on a vast variety of platforms and for as long as
possible.  I am going to devote some time into building OpenJFX and trying
to get to the bottom of the performance issues I have informally reported.

If other products can achieve high-quality and high-performance animations
on my computers then why can't JavaFX?  The answers must be out there...

-jct

-Original Message-
From: Richard Bair [mailto:richard.b...@oracle.com]
Sent: Friday, 31 May 2013 01:12
To: John C. Turnbull
Cc: openjfx-dev@openjdk.java.net
Subject: Re: JavaFX graphics performance and suitability for advanced
animations

Hi John,


Graphics?  Yes, to a point.  But my post was really about graphics and
the issues related to performance.  Again, unless those issues are
resolved then it's not appropriate to state that JavaFX is suitable for

graphics.

You asked what the full range of applications for which JavaFX is or will
be suitable for.


Then you mention Halo 5.  I have to say the subtext here troubles me
greatly.  If I read you correctly then you are saying that JavaFX is
not really suitable for games (at least anything beyond the demands of
something like Solitaire).  As someone else pointed out, what is point
of developing 3D support in JavaFX if it is not really suitable for
games?  To say it is not suitable for games implies that it is not
really suitable for *any* application that requires performant
animations and visualisations.  What use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D,
and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that are
broader than real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of
them) as well as very specialized tricks for getting the most out of their
graphics cards. When we expose API that allows people to hammer the card
directly, then it would be possible for somebody to build some of the UI in
FX and let their game engine be hand written (in Unity or JOGL or whatever).


4.   Is JavaFX more targeted at form-based UIs rather than high
performance graphics?

No.

Again, good to know but where are all the high-performance JavaFX
apps?  So far I have seen nothing but form-based apps.  Wouldn't it be
prudent for Oracle to include a showcase app or game that shows us
the full capabilities of JavaFX with high-performance graphics?

I am sure I am not alone in feeling that the animation examples in
Ensemble do very little to promote the graphics capabilities of JavaFX.

Are you offering to contribute? :-)


Are your slow examples reproducible? If so we need the test case. Is
there

an issue filed? We can't fix things we can't reproduce.

We spend a *considerable* amount of time and energy on performance
and for

the things we're measuring we're doing well.

As the saying goes what's measured, improves. After the switch to
gradle

and the new project layout, one thing I'm going to

look at is using JMH[2] in OpenJFX so we can write micro benchmarks
and

have them easy for everybody to run and

contribute to. Our current set of micro benchmarks are based on the

predecessor of JMH which was the

JRockit benchmark suite and was proprietary (hence we cannot just
open

source our existing benchmarks without doing some rewrite).

All good points.

However, I am not sure that having me preparing reproducible test
cases will actually help.  In my experience, the Ensemble app already
serves this purpose.  The choppiness I describe is *always* prevalent
when I run the animations and transitions in Ensemble (including
Ensemble 8).  The only variation is in the degree of that choppiness.

Then start with that, something absolutely dead simple like a path animation
or rotate transition and lets figure out how to measure the jitter and get
it into our benchmark suite.

Richard=

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Scott Palmer

Taking a quick look at the code it seems that the animation time for ball
updates is fixed at 40ms using a Timeline with a single KeyFrame.  So
25fps, half the refresh speed of any known desktop computer display.

brickbreaker/Config.java:40
public static final Duration ANIMATION_TIME = Duration.millis(40);

 Since this is well below the monitor refresh rate, and I suspect it isn't
synced to the display refresh, you get ugly animation.

I flipped it to 20ms for a quick test and the animation is much smoother,
though there is still the occasional jitter due to not syncing with the
display.

I think a better implementation would use an AnimationTimer.  I believe
JavaFX tries to call them at the display refresh rate?


Scott



On Fri, May 31, 2013 at 10:13 AM, Richard Bair richard.b...@oracle.comwrote:

 Have you tried to determine what the FPS is? My guess is that FPS is not
 anywhere near the limit and it is the occasional stutter that is the
 problem, but I'm not certain. Knowing that helps to point in which
 direction to go. The fact that it runs pretty well on a PI is indication
 that it isn't the framerate.

 Richard

 On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com wrote:

 Speaking of poor animation in Ensemble...

 Is anyone able to run Brick Breaker without choppy animation or poor
 framerate performance on the ball?

 Now, I suspect the issue there is in the balls animation implementation in
 the application rather than the JavaFX framework, as the bat moves smoothly
 when I move the mouse, but the overall perception of JavaFX performance for
 this demo app is not good. I would go so far as to say that Brick Breaker
 has had the opposite effect it was intended too - simply because the
 animation of the ball is not smooth.  That's something that would run
 smoothly on a Commodore 64,yet the last time I tried it (5 minutes ago)
 with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a decent NVIDIA
 card, it didn't run as smoothly as I would expect.  Just a single ball with
 a shadow bouncing around the screen seemed to have a low framerate and the
 occasional skipped frame.  It just didn't look that great.

 The fact that Brick Breaker ships as a sample app from Oracle and it's
 animation looks bad is harming JavaFX's reputation in my opinion.  I think
 it could run much better on the existing JavaFX runtime.  The simple
 animations in the Ensemble app run much smoother for example.



 Scott


 On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.comwrote:


  Then you mention Halo 5.  I have to say the subtext here troubles me
  greatly.  If I read you correctly then you are saying that JavaFX is not
  really suitable for games (at least anything beyond the demands of
 something
  like Solitaire).  As someone else pointed out, what is point of
 developing
  3D support in JavaFX if it is not really suitable for games?  To say it
 is
  not suitable for games implies that it is not really suitable for *any*
  application that requires performant animations and visualisations.
  What
  use then is the 3D API?

 That's not fair at all. There are a *lot* of enterprise use cases for 3D,
 and we get these requests all the time. Whether we're taking about 3D
 visualizations for medical or engineering applications or consumer
 applications (product display, etc), there is a requirement for 3D that are
 broader than real time first person shooters.

 Game engines often have very specialized scene graphs (sometimes several
 of them) as well as very specialized tricks for getting the most out of
 their graphics cards. When we expose API that allows people to hammer the
 card directly, then it would be possible for somebody to build some of the
 UI in FX and let their game engine be hand written (in Unity or JOGL or
 whatever).




  However, I am not sure that having me preparing reproducible test
 cases
  will actually help.  In my experience, the Ensemble app already serves
 this
  purpose.  The choppiness I describe is *always* prevalent when I run the
  animations and transitions in Ensemble (including Ensemble 8).  The only
  variation is in the degree of that choppiness.

 Then start with that, something absolutely dead simple like a path
 animation or rotate transition and lets figure out how to measure the
 jitter and get it into our benchmark suite.

 Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Kevin Rushforth

Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801

Richard Bair wrote:

Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the problem,
but I'm not certain. Knowing that helps to point in which direction to go. The
fact that it runs pretty well on a PI is indication that it isn't the framerate.

Richard

On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com wrote:

Speaking of poor animation in Ensemble...

Is anyone able to run Brick Breaker without choppy animation or poor framerate performance on the ball?

Now, I suspect the issue there is in the balls animation implementation in the
application rather than the JavaFX framework, as the bat moves smoothly when I
move the mouse, but the overall perception of JavaFX performance for this demo
app is not good. I would go so far as to say that Brick Breaker has had the
opposite effect it was intended too - simply because the animation of the ball
is not smooth. That's something that would run smoothly on a Commodore 64,yet
the last time I tried it (5 minutes ago) with JavaFX 8.0-b91 on a quad-core
3GHz Windows 7 box with a decent NVIDIA card, it didn't run as smoothly as I
would expect. Just a single ball with a shadow bouncing around the screen
seemed to have a low framerate and the occasional skipped frame. It just
didn't look that great.

The fact that Brick Breaker ships as a sample app from Oracle and it's
animation looks bad is harming JavaFX's reputation in my opinion. I think it
could run much better on the existing JavaFX runtime. The simple animations in
the Ensemble app run much smoother for example.

Scott

On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.com wrote:

Then you mention Halo 5. I have to say the subtext here troubles me
greatly. If I read you correctly then you are saying that JavaFX is not
really suitable for games (at least anything beyond the demands of something
like Solitaire). As someone else pointed out, what is point of developing
3D support in JavaFX if it is not really suitable for games? To say it is
not suitable for games implies that it is not really suitable for *any*
application that requires performant animations and visualisations. What
use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D, and
we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer applications
(product display, etc), there is a requirement for 3D that are broader than
real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of
them) as well as very specialized tricks for getting the most out of their
graphics cards. When we expose API that allows people to hammer the card
directly, then it would be possible for somebody to build some of the UI in FX
and let their game engine be hand written (in Unity or JOGL or whatever).

However, I am not sure that having me preparing reproducible test cases
will actually help. In my experience, the Ensemble app already serves this
purpose. The choppiness I describe is *always* prevalent when I run the
animations and transitions in Ensemble (including Ensemble 8). The only
variation is in the degree of that choppiness.

Then start with that, something absolutely dead simple like a path animation or
rotate transition and lets figure out how to measure the jitter and get it into
our benchmark suite.

Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Daniel Zwolenski

Just on the topic of what should we expect performance/animation/graphic wise,
are there technical limitations why jfx can't achieve this exact level of
quality in animations:
http://m.youtube.com/#/watch?v=-fNg-qZcIdYfeature=youtube_gdata_playerdesktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player

This is more or less the style of animation that I'd want to use jfx for.

So if I wrote the code for this and then ran it side by side with the video how
far off should the two be?

I get that this is a pre-rendered video so it has some advantages but the video
does not use rapid redraws or complicated particle effects, shadows,
reflections, etc, like in a FPS game. How close should we expect jfx to get to
this and which bits are not achievable and why?

On 01/06/2013, at 1:32 AM, Scott Palmer swpal...@gmail.com wrote:

Richard, I suspect you made a typo. I think you mean *40*ms is a really
odd number... (it was 25 FPS, not 25ms)

I quickly hacked it to use AnimationTimer and the animation is very smooth
now. Though I didn't make the required changes to adjust the speeds based
on the refresh rate. The quick conversion to AnimationTimer is trivial..
but going through and adjusting all the translations and increments to be
relative to the time between consecutive frames is something I don't have
time for.

Cheers,

Scott

On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth
kevin.rushfo...@oracle.com wrote:

**
Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801

Richard Bair wrote:

Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the
problem, but I'm not certain. Knowing that helps to point in which direction
to go. The fact that it runs pretty well on a PI is indication that it isn't
the framerate.

Richard

On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com
swpal...@gmail.com wrote:

Speaking of poor animation in Ensemble...

Is anyone able to run Brick Breaker without choppy animation or poor
framerate performance on the ball?

Now, I suspect the issue there is in the balls animation implementation in
the application rather than the JavaFX framework, as the bat moves smoothly
when I move the mouse, but the overall perception of JavaFX performance for
this demo app is not good. I would go so far as to say that Brick Breaker
has had the opposite effect it was intended too - simply because the
animation of the ball is not smooth. That's something that would run
smoothly on a Commodore 64,yet the last time I tried it (5 minutes ago) with
JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a decent NVIDIA card,
it didn't run as smoothly as I would expect. Just a single ball with a
shadow bouncing around the screen seemed to have a low framerate and the
occasional skipped frame. It just didn't look that great.

The fact that Brick Breaker ships as a sample app from Oracle and it's
animation looks bad is harming JavaFX's reputation in my opinion. I think
it could run much better on the existing JavaFX runtime. The simple
animations in the Ensemble app run much smoother for example.

Scott

On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.com
richard.b...@oracle.com wrote:

That's not fair at all. There are a *lot* of enterprise use cases for 3D,
and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that are
broader than real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of
them) as well as very specialized tricks for getting the most out of their
graphics cards. When we expose API that allows people to hammer the card
directly, then it would be possible for somebody to build some of the UI in
FX and let their game engine be hand written (in Unity or JOGL or whatever).

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Richard Bair

The link didn't work for me, is there another link? (It came up with a page of
videos, the top one being video.3gp)

Richard

On May 31, 2013, at 8:46 AM, Daniel Zwolenski zon...@gmail.com wrote:

Just on the topic of what should we expect performance/animation/graphic
wise, are there technical limitations why jfx can't achieve this exact level
of quality in animations:
http://m.youtube.com/#/watch?v=-fNg-qZcIdYfeature=youtube_gdata_playerdesktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player

This is more or less the style of animation that I'd want to use jfx for.

So if I wrote the code for this and then ran it side by side with the video
how far off should the two be?

I get that this is a pre-rendered video so it has some advantages but the
video does not use rapid redraws or complicated particle effects, shadows,
reflections, etc, like in a FPS game. How close should we expect jfx to get
to this and which bits are not achievable and why?

On 01/06/2013, at 1:32 AM, Scott Palmer swpal...@gmail.com wrote:

Richard, I suspect you made a typo. I think you mean *40*ms is a really
odd number... (it was 25 FPS, not 25ms)

Cheers,

Scott

On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth
kevin.rushfo...@oracle.com wrote:

**
Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801

Richard Bair wrote:

Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the
problem, but I'm not certain. Knowing that helps to point in which
direction to go. The fact that it runs pretty well on a PI is indication
that it isn't the framerate.

Richard

On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com
swpal...@gmail.com wrote:

Speaking of poor animation in Ensemble...

Is anyone able to run Brick Breaker without choppy animation or poor
framerate performance on the ball?

Now, I suspect the issue there is in the balls animation implementation in
the application rather than the JavaFX framework, as the bat moves smoothly
when I move the mouse, but the overall perception of JavaFX performance for
this demo app is not good. I would go so far as to say that Brick Breaker
has had the opposite effect it was intended too - simply because the
animation of the ball is not smooth. That's something that would run
smoothly on a Commodore 64,yet the last time I tried it (5 minutes ago)
with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a decent NVIDIA
card, it didn't run as smoothly as I would expect. Just a single ball with
a shadow bouncing around the screen seemed to have a low framerate and the
occasional skipped frame. It just didn't look that great.

The fact that Brick Breaker ships as a sample app from Oracle and it's
animation looks bad is harming JavaFX's reputation in my opinion. I think
it could run much better on the existing JavaFX runtime. The simple
animations in the Ensemble app run much smoother for example.

Scott

On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.com
richard.b...@oracle.com wrote:

That's not fair at all. There are a *lot* of enterprise use cases for 3D,
and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that are
broader than real time first person shooters.

Game engines often have very specialized scene graphs (sometimes several of
them) as well as very specialized tricks for getting the most out of their
graphics cards. When we expose API that allows people to hammer the card
directly, then it would be possible for somebody to build some of the UI in
FX and let their game engine be hand written (in Unity or JOGL or whatever).

However, I am not sure that having me

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Scott Palmer

Flip the link from Mobile to Desktop at the top.

I think JavaFX could easily handle this.

Scott

On Fri, May 31, 2013 at 12:08 PM, Richard Bair richard.b...@oracle.comwrote:

The link didn't work for me, is there another link? (It came up with a
page of videos, the top one being video.3gp)

Richard

On May 31, 2013, at 8:46 AM, Daniel Zwolenski zon...@gmail.com wrote:

Just on the topic of what should we expect performance/animation/graphic
wise, are there technical limitations why jfx can't achieve this exact
level of quality in animations:

http://m.youtube.com/#/watch?v=-fNg-qZcIdYfeature=youtube_gdata_playerdesktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player

This is more or less the style of animation that I'd want to use jfx for.

So if I wrote the code for this and then ran it side by side with the
video how far off should the two be?

I get that this is a pre-rendered video so it has some advantages but
the video does not use rapid redraws or complicated particle effects,
shadows, reflections, etc, like in a FPS game. How close should we expect
jfx to get to this and which bits are not achievable and why?

On 01/06/2013, at 1:32 AM, Scott Palmer swpal...@gmail.com wrote:

Richard, I suspect you made a typo. I think you mean *40*ms is a
really
odd number... (it was 25 FPS, not 25ms)

I quickly hacked it to use AnimationTimer and the animation is very
smooth
now. Though I didn't make the required changes to adjust the speeds
based
on the refresh rate. The quick conversion to AnimationTimer is
trivial..
but going through and adjusting all the translations and increments to
be
relative to the time between consecutive frames is something I don't
have
time for.

Cheers,

Scott

On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth
kevin.rushfo...@oracle.com wrote:

**
Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801

Richard Bair wrote:

Have you tried to determine what the FPS is? My guess is that FPS is
not anywhere near the limit and it is the occasional stutter that is the
problem, but I'm not certain. Knowing that helps to point in which
direction to go. The fact that it runs pretty well on a PI is indication
that it isn't the framerate.

Richard

On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com
swpal...@gmail.com wrote:

Speaking of poor animation in Ensemble...

Is anyone able to run Brick Breaker without choppy animation or poor
framerate performance on the ball?

Now, I suspect the issue there is in the balls animation
implementation in the application rather than the JavaFX framework, as the
bat moves smoothly when I move the mouse, but the overall perception of
JavaFX performance for this demo app is not good. I would go so far as to
say that Brick Breaker has had the opposite effect it was intended too -
simply because the animation of the ball is not smooth. That's something
that would run smoothly on a Commodore 64,yet the last time I tried it (5
minutes ago) with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a
decent NVIDIA card, it didn't run as smoothly as I would expect. Just a
single ball with a shadow bouncing around the screen seemed to have a low
framerate and the occasional skipped frame. It just didn't look that great.

The fact that Brick Breaker ships as a sample app from Oracle and it's
animation looks bad is harming JavaFX's reputation in my opinion. I think
it could run much better on the existing JavaFX runtime. The simple
animations in the Ensemble app run much smoother for example.

Scott

On Thu, May 30, 2013 at 11:11 AM, Richard Bair
richard.b...@oracle.com richard.b...@oracle.com wrote:

Then you mention Halo 5. I have to say the subtext here troubles me
greatly. If I read you correctly then you are saying that JavaFX is
not
really suitable for games (at least anything beyond the demands of
something
like Solitaire). As someone else pointed out, what is point of
developing
3D support in JavaFX if it is not really suitable for games? To say
it is
not suitable for games implies that it is not really suitable for *any*
application that requires performant animations and visualisations.
What
use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for
3D, and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that are
broader than real time first person shooters.

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Richard Bair

Patch attached to https://javafx-jira.kenai.com/browse/RT-29801. I'm not seeing 
any stutter on my Mac, interested to hear the experience on Windows.

Richard

On May 31, 2013, at 8:44 AM, Richard Bair richard.b...@oracle.com wrote:

 Ya I did the same, am now adjusting it so the factor by which things move is 
 better.
 
 Richard
 
 On May 31, 2013, at 8:32 AM, Scott Palmer swpal...@gmail.com wrote:
 
 Richard, I suspect you made a typo.  I think you mean *40*ms is a really 
 odd number... (it was 25 FPS, not 25ms)
 
 I quickly hacked it to use AnimationTimer and the animation is very smooth 
 now.  Though I didn't make the required changes to adjust the speeds based 
 on the refresh rate.  The quick conversion to AnimationTimer is trivial.. 
 but going through and adjusting all the translations and increments to be 
 relative to the time between consecutive frames is something I don't have 
 time for.
 
 Cheers,
 
 Scott
 
 
 Scott
 
 
 On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth 
 kevin.rushfo...@oracle.com wrote:
 Btw, there is a JIRA issue filed against BrickBreaker specifically: 
 https://javafx-jira.kenai.com/browse/RT-29801
 
 
 Richard Bair wrote:
 
 Have you tried to determine what the FPS is? My guess is that FPS is not 
 anywhere near the limit and it is the occasional stutter that is the 
 problem, but I'm not certain. Knowing that helps to point in which 
 direction to go. The fact that it runs pretty well on a PI is indication 
 that it isn't the framerate.
 
 Richard
 
 On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com wrote:
 
 
 Speaking of poor animation in Ensemble...
 
 Is anyone able to run Brick Breaker without choppy animation or poor 
 framerate performance on the ball?  
 
 Now, I suspect the issue there is in the balls animation implementation in 
 the application rather than the JavaFX framework, as the bat moves 
 smoothly when I move the mouse, but the overall perception of JavaFX 
 performance for this demo app is not good. I would go so far as to say 
 that Brick Breaker has had the opposite effect it was intended too - 
 simply because the animation of the ball is not smooth.  That's something 
 that would run smoothly on a Commodore 64,yet the last time I tried it (5 
 minutes ago) with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a 
 decent NVIDIA card, it didn't run as smoothly as I would expect.  Just a 
 single ball with a shadow bouncing around the screen seemed to have a low 
 framerate and the occasional skipped frame.  It just didn't look that 
 great.
 
 The fact that Brick Breaker ships as a sample app from Oracle and it's 
 animation looks bad is harming JavaFX's reputation in my opinion.  I think 
  it could run much better on the existing JavaFX runtime.  The simple 
 animations in the Ensemble app run much smoother for example.
 
 
 
 Scott
 
 
 On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.com 
 wrote:
 
 
 Then you mention Halo 5.  I have to say the subtext here troubles me
 greatly.  If I read you correctly then you are saying that JavaFX is not
 really suitable for games (at least anything beyond the demands of 
 something
 like Solitaire).  As someone else pointed out, what is point of developing
 3D support in JavaFX if it is not really suitable for games?  To say it is
 not suitable for games implies that it is not really suitable for *any*
 application that requires performant animations and visualisations.  What
 use then is the 3D API?
 
 That's not fair at all. There are a *lot* of enterprise use cases for 3D, 
 and we get these requests all the time. Whether we're taking about 3D 
 visualizations for medical or engineering applications or consumer 
 applications (product display, etc), there is a requirement for 3D that 
 are broader than real time first person shooters.
 
 Game engines often have very specialized scene graphs (sometimes several 
 of them) as well as very specialized tricks for getting the most out of 
 their graphics cards. When we expose API that allows people to hammer the 
 card directly, then it would be possible for somebody to build some of the 
 UI in FX and let their game engine be hand written (in Unity or JOGL or 
 whatever).
 
 
 
 However, I am not sure that having me preparing reproducible test cases
 will actually help.  In my experience, the Ensemble app already serves 
 this
 purpose.  The choppiness I describe is *always* prevalent when I run the
 animations and transitions in Ensemble (including Ensemble 8).  The only
 variation is in the degree of that choppiness.
 
 Then start with that, something absolutely dead simple like a path 
 animation or rotate transition and lets figure out how to measure the 
 jitter and get it into our benchmark suite.
 
 Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Richard Bair

The magnifying glass is harder (but with render to image you could do it I
think). Otherwise I agree this should be quite doable.

Richard

On May 31, 2013, at 9:17 AM, Scott Palmer swpal...@gmail.com wrote:

Flip the link from Mobile to Desktop at the top.

I think JavaFX could easily handle this.

Scott

On Fri, May 31, 2013 at 12:08 PM, Richard Bair richard.b...@oracle.com
wrote:
The link didn't work for me, is there another link? (It came up with a page
of videos, the top one being video.3gp)

Richard

On May 31, 2013, at 8:46 AM, Daniel Zwolenski zon...@gmail.com wrote:

Just on the topic of what should we expect performance/animation/graphic
wise, are there technical limitations why jfx can't achieve this exact
level of quality in animations:
http://m.youtube.com/#/watch?v=-fNg-qZcIdYfeature=youtube_gdata_playerdesktop_uri=%2Fwatch%3Fv%3D-fNg-qZcIdY%26feature%3Dyoutube_gdata_player

This is more or less the style of animation that I'd want to use jfx for.

So if I wrote the code for this and then ran it side by side with the video
how far off should the two be?

I get that this is a pre-rendered video so it has some advantages but the
video does not use rapid redraws or complicated particle effects, shadows,
reflections, etc, like in a FPS game. How close should we expect jfx to get
to this and which bits are not achievable and why?

On 01/06/2013, at 1:32 AM, Scott Palmer swpal...@gmail.com wrote:

Richard, I suspect you made a typo. I think you mean *40*ms is a really
odd number... (it was 25 FPS, not 25ms)

Cheers,

Scott

On Fri, May 31, 2013 at 11:21 AM, Kevin Rushforth
kevin.rushfo...@oracle.com wrote:

**
Btw, there is a JIRA issue filed against BrickBreaker specifically:
https://javafx-jira.kenai.com/browse/RT-29801

Richard Bair wrote:

Have you tried to determine what the FPS is? My guess is that FPS is not
anywhere near the limit and it is the occasional stutter that is the
problem, but I'm not certain. Knowing that helps to point in which
direction to go. The fact that it runs pretty well on a PI is indication
that it isn't the framerate.

Richard

On May 31, 2013, at 4:26 AM, Scott Palmer swpal...@gmail.com
swpal...@gmail.com wrote:

Speaking of poor animation in Ensemble...

Is anyone able to run Brick Breaker without choppy animation or poor
framerate performance on the ball?

Now, I suspect the issue there is in the balls animation implementation
in the application rather than the JavaFX framework, as the bat moves
smoothly when I move the mouse, but the overall perception of JavaFX
performance for this demo app is not good. I would go so far as to say
that Brick Breaker has had the opposite effect it was intended too -
simply because the animation of the ball is not smooth. That's something
that would run smoothly on a Commodore 64,yet the last time I tried it (5
minutes ago) with JavaFX 8.0-b91 on a quad-core 3GHz Windows 7 box with a
decent NVIDIA card, it didn't run as smoothly as I would expect. Just a
single ball with a shadow bouncing around the screen seemed to have a low
framerate and the occasional skipped frame. It just didn't look that
great.

The fact that Brick Breaker ships as a sample app from Oracle and it's
animation looks bad is harming JavaFX's reputation in my opinion. I
think it could run much better on the existing JavaFX runtime. The
simple animations in the Ensemble app run much smoother for example.

Scott

On Thu, May 30, 2013 at 11:11 AM, Richard Bair richard.b...@oracle.com
richard.b...@oracle.com wrote:

Then you mention Halo 5. I have to say the subtext here troubles me
greatly. If I read you correctly then you are saying that JavaFX is not
really suitable for games (at least anything beyond the demands of
something
like Solitaire). As someone else pointed out, what is point of developing
3D support in JavaFX if it is not really suitable for games? To say it is
not suitable for games implies that it is not really suitable for *any*
application that requires performant animations and visualisations. What
use then is the 3D API?

That's not fair at all. There are a *lot* of enterprise use cases for 3D,
and we get these requests all the time. Whether we're taking about 3D
visualizations for medical or engineering applications or consumer
applications (product display, etc), there is a requirement for 3D that
are

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Hervé Girod

I don't know if there is the same behavior in JavaFX as in Swing, but using 
Swing for complex animated rendering of texts, we discovered that if we used 
the standard way of daring the strings in a Graphics2D, there was a kind of 
Jitter on each String when moving or rotating the texts, the letters seemed to 
move relatively to each other.

To avoid this effect, we used a TextLayout and cached the Strings Layouts when 
they changed and draw their outline Shapes. With this method, there was no 
Jitter at all. Perhaps this is the same case with the two methods you mention 
with these Microsoft links.

Herve

Sent from my iPad

On 31 mai 2013, at 22:57, Richard Bair richard.b...@oracle.com wrote:

 Felipe found these links:
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ee663563(v=vs.85).aspx
 http://msdn.microsoft.com/en-us/library/windows/desktop/dd756767%28v=vs.85%29.aspx
 
 I followed the 2nd link to run in Parallels. I'm not sure to what extent it 
 is the same as what you'd see on dedicated hardware, but I thought it would 
 be good for you to see what kind of options DirectWrite provides (and to know 
 that Felipe is working on the DirectWrite backend for text rendering on 
 Windows).
 
 Running the Default rendering method gives predictably crappy looking 
 animated text. Predictable in that MS is doing the same thing we are by 
 default -- focusing on producing crisp text. Their crappy might be better or 
 worse than our crappy, but in both cases it is crappy when animated :-). The 
 Outlines method is very nice (and much slower). I couldn't run the A8 
 method on Parallels (it just didn't draw anything).
 
 Give a play and see what the native system is doing. We need some kind of API 
 (as linked in your JIRA issue) to allow you to easily pick which method you 
 want.
 
 Perhaps it is a windows issue. Does seem like a few of the people reporting 
 problems in this thread are on windows, and without those lovely high-res 
 Mac displays that make everything look so pretty. On my machine there is no 
 way you could say the jfx one is on par with the jscript one. I'd have a 
 hard time convincing anyone to use jfx over even lowly jscript using that 
 incredibly basic showdown I put together.   
 
 We have a mix of systems but I personally have only a Mac + parallels (and 
 when it comes to performance you really can't draw any accurate conclusions 
 when running in a VM).
 
 How often do you personally run something like ensemble on windows? It could 
 be that we're seeing big issues and you're seeing minor ones, hence out 
 angst at how casually these issues are treated (two bugs I spent hours 
 narrowing down and reproducing got closed in around 10 minutes - was the 
 code run on the environment it was reported to be found on in this time?). 
 Might be worth you having an eyeball just to see.
 
 I know Kevin and Jonathan have Windows machines. But this is a good point we 
 need to make sure we run on a similar environment.
 
 Regarding the Text vs Label thing, I'm not sure I get what that's about. My 
 primary use with animations is to do ipad like transitions of rich widgets 
 containing labels, buttons, tables, etc. So a panel of buttons might slide 
 in left, a document might get folded up and put in a rubbish bin, or a 
 dialog might grow out of a button that was clicked. Are you saying smooth 
 animations are not intended to be used on complex node graphs like this?
 
 Usually when animating a page of stuff, the best way to get good performance 
 (on desktop and mobile) is to first set cache=true on the panel being 
 animated, animate the thing, and then turn cache=false on the panel. In that 
 case, you won't see any of these issues. But I think you are right that 
 Labeled things should have a setting to indicate the way they render their 
 text just like the Text node should.
 
 JS is driving tis animation and not CSS?
 
 Is this a question about the HTML I put up? If so then the answer is jquery 
 is used to animate between a start css style and an end css style (just view 
 source on the HTML, it's about 10 lines of code). How it does this you would 
 have to look at jquery's animate method. I know as much about it's internals 
 as I do about JFX's.
 
 Right, my thought was whether the difference between what I see on Mac vs. 
 what you see on Windows is based on the browser engine (but I tried chrome, 
 so maybe not). When JS is driving the animation you often get different 
 performance / behavior than when CSS is driving it.
 
 Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Hervé Girod

We used the second method in a case where we painted animated Swing hierarchies 
in an external OpenGL context, each character associated bitmap was cached when 
it was necessary to draw the Glyph. The result seemed ok to us. Now I'm 
thinking that we could have done the same thing in pure Java rather than using 
our outlines ;)

Sent from my iPad

On 1 juin 2013, at 00:43, Richard Bair richard.b...@oracle.com wrote:

 Yes, and sounds like what we want to do with Text. Basically in your swing 
 example you were treating the text as outlines rather than glyphs. It draws 
 much nicer -- but also much slower.
 
 The other option is to treat them as images and not snap-em. Not as nice but 
 probably quite decent for a lot of stuff and a *lot* faster.
 
 On May 31, 2013, at 3:10 PM, Hervé Girod herve.gi...@gmail.com wrote:
 
 I don't know if there is the same behavior in JavaFX as in Swing, but using 
 Swing for complex animated rendering of texts, we discovered that if we used 
 the standard way of daring the strings in a Graphics2D, there was a kind of 
 Jitter on each String when moving or rotating the texts, the letters seemed 
 to move relatively to each other.
 
 To avoid this effect, we used a TextLayout and cached the Strings Layouts 
 when they changed and draw their outline Shapes. With this method, there was 
 no Jitter at all. Perhaps this is the same case with the two methods you 
 mention with these Microsoft links.
 
 Herve
 
 Sent from my iPad
 
 On 31 mai 2013, at 22:57, Richard Bair richard.b...@oracle.com wrote:
 
 Felipe found these links:
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ee663563(v=vs.85).aspx
 http://msdn.microsoft.com/en-us/library/windows/desktop/dd756767%28v=vs.85%29.aspx
 
 I followed the 2nd link to run in Parallels. I'm not sure to what extent it 
 is the same as what you'd see on dedicated hardware, but I thought it would 
 be good for you to see what kind of options DirectWrite provides (and to 
 know that Felipe is working on the DirectWrite backend for text rendering 
 on Windows).
 
 Running the Default rendering method gives predictably crappy looking 
 animated text. Predictable in that MS is doing the same thing we are by 
 default -- focusing on producing crisp text. Their crappy might be better 
 or worse than our crappy, but in both cases it is crappy when animated :-). 
 The Outlines method is very nice (and much slower). I couldn't run the A8 
 method on Parallels (it just didn't draw anything).
 
 Give a play and see what the native system is doing. We need some kind of 
 API (as linked in your JIRA issue) to allow you to easily pick which method 
 you want.
 
 Perhaps it is a windows issue. Does seem like a few of the people 
 reporting problems in this thread are on windows, and without those lovely 
 high-res Mac displays that make everything look so pretty. On my machine 
 there is no way you could say the jfx one is on par with the jscript one. 
 I'd have a hard time convincing anyone to use jfx over even lowly jscript 
 using that incredibly basic showdown I put together.   
 
 We have a mix of systems but I personally have only a Mac + parallels (and 
 when it comes to performance you really can't draw any accurate conclusions 
 when running in a VM).
 
 How often do you personally run something like ensemble on windows? It 
 could be that we're seeing big issues and you're seeing minor ones, hence 
 out angst at how casually these issues are treated (two bugs I spent hours 
 narrowing down and reproducing got closed in around 10 minutes - was the 
 code run on the environment it was reported to be found on in this time?). 
 Might be worth you having an eyeball just to see.
 
 I know Kevin and Jonathan have Windows machines. But this is a good point 
 we need to make sure we run on a similar environment.
 
 Regarding the Text vs Label thing, I'm not sure I get what that's about. 
 My primary use with animations is to do ipad like transitions of rich 
 widgets containing labels, buttons, tables, etc. So a panel of buttons 
 might slide in left, a document might get folded up and put in a rubbish 
 bin, or a dialog might grow out of a button that was clicked. Are you 
 saying smooth animations are not intended to be used on complex node 
 graphs like this?
 
 Usually when animating a page of stuff, the best way to get good 
 performance (on desktop and mobile) is to first set cache=true on the panel 
 being animated, animate the thing, and then turn cache=false on the panel. 
 In that case, you won't see any of these issues. But I think you are right 
 that Labeled things should have a setting to indicate the way they render 
 their text just like the Text node should.
 
 JS is driving tis animation and not CSS?
 
 Is this a question about the HTML I put up? If so then the answer is 
 jquery is used to animate between a start css style and an end css style 
 (just view source on the HTML, it's about 10 lines of code). How it does 
 this

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Richard Bair

The text in PowerPoint is very likely outlines (treat the text as shapes) since 
there isn't much text per slide and its usually very large (in fact most render 
engines stop rendering text as glyphs at a given size -- for us it is  80pt.). 
H. I wonder if you used an 81pt font and scaled it down what that would 
look like?

I'm curious on the animated box though as to what you are seeing that you like. 
Is it pixel snapping but its moving fast enough that it looks OK? Or is it that 
the AA algorithm is better for this case? If you did a screen capture would 
it be high enough quality to show exactly what it is you see?

Richard

On May 31, 2013, at 4:26 PM, Daniel Zwolenski zon...@gmail.com wrote:

 I just did some animated text scaling in PowerPoint and it was beautiful. If 
 jfx did that you'd have no complaints from me. 
 
 Is it worth me putting up the PPS file for comparison? Can you open PPS on 
 Mac?
 
 I did the box one too and it was roughly on par with jscript one, though the 
 drop shadow seemed slightly less jumpy. 
 
 
 
 
 On 01/06/2013, at 9:08 AM, Hervé Girod herve.gi...@gmail.com wrote:
 
 We used the second method in a case where we painted animated Swing 
 hierarchies in an external OpenGL context, each character associated bitmap 
 was cached when it was necessary to draw the Glyph. The result seemed ok to 
 us. Now I'm thinking that we could have done the same thing in pure Java 
 rather than using our outlines ;)
 
 Sent from my iPad
 
 On 1 juin 2013, at 00:43, Richard Bair richard.b...@oracle.com wrote:
 
 Yes, and sounds like what we want to do with Text. Basically in your swing 
 example you were treating the text as outlines rather than glyphs. It draws 
 much nicer -- but also much slower.
 
 The other option is to treat them as images and not snap-em. Not as nice 
 but probably quite decent for a lot of stuff and a *lot* faster.
 
 On May 31, 2013, at 3:10 PM, Hervé Girod herve.gi...@gmail.com wrote:
 
 I don't know if there is the same behavior in JavaFX as in Swing, but 
 using Swing for complex animated rendering of texts, we discovered that if 
 we used the standard way of daring the strings in a Graphics2D, there was 
 a kind of Jitter on each String when moving or rotating the texts, the 
 letters seemed to move relatively to each other.
 
 To avoid this effect, we used a TextLayout and cached the Strings Layouts 
 when they changed and draw their outline Shapes. With this method, there 
 was no Jitter at all. Perhaps this is the same case with the two methods 
 you mention with these Microsoft links.
 
 Herve
 
 Sent from my iPad
 
 On 31 mai 2013, at 22:57, Richard Bair richard.b...@oracle.com wrote:
 
 Felipe found these links:
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/ee663563(v=vs.85).aspx
 http://msdn.microsoft.com/en-us/library/windows/desktop/dd756767%28v=vs.85%29.aspx
 
 I followed the 2nd link to run in Parallels. I'm not sure to what extent 
 it is the same as what you'd see on dedicated hardware, but I thought it 
 would be good for you to see what kind of options DirectWrite provides 
 (and to know that Felipe is working on the DirectWrite backend for text 
 rendering on Windows).
 
 Running the Default rendering method gives predictably crappy looking 
 animated text. Predictable in that MS is doing the same thing we are by 
 default -- focusing on producing crisp text. Their crappy might be better 
 or worse than our crappy, but in both cases it is crappy when animated 
 :-). The Outlines method is very nice (and much slower). I couldn't run 
 the A8 method on Parallels (it just didn't draw anything).
 
 Give a play and see what the native system is doing. We need some kind of 
 API (as linked in your JIRA issue) to allow you to easily pick which 
 method you want.
 
 Perhaps it is a windows issue. Does seem like a few of the people 
 reporting problems in this thread are on windows, and without those 
 lovely high-res Mac displays that make everything look so pretty. On my 
 machine there is no way you could say the jfx one is on par with the 
 jscript one. I'd have a hard time convincing anyone to use jfx over even 
 lowly jscript using that incredibly basic showdown I put together.   
 
 We have a mix of systems but I personally have only a Mac + parallels 
 (and when it comes to performance you really can't draw any accurate 
 conclusions when running in a VM).
 
 How often do you personally run something like ensemble on windows? It 
 could be that we're seeing big issues and you're seeing minor ones, 
 hence out angst at how casually these issues are treated (two bugs I 
 spent hours narrowing down and reproducing got closed in around 10 
 minutes - was the code run on the environment it was reported to be 
 found on in this time?). Might be worth you having an eyeball just to 
 see.
 
 I know Kevin and Jonathan have Windows machines. But this is a good point 
 we need to make sure we run on a similar environment.
 
 Regarding

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Richard Bair

 The text in PowerPoint is very likely outlines (treat the text as shapes) 
 since there isn't much text per slide and its usually very large (in fact 
 most render engines stop rendering text as glyphs at a given size -- for us 
 it is  80pt.). H. I wonder if you used an 81pt font and scaled it down 
 what that would look like?

Well, I tried it, and it wasn't pretty: 
https://javafx-jira.kenai.com/browse/RT-30862

Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Phil Race


On 5/31/13 4:52 PM, Richard Bair wrote:

The text in PowerPoint is very likely outlines (treat the text as shapes) since 
there isn't much text per slide and its usually very large (in fact most render 
engines stop rendering text as glyphs at a given size -- for us it is  80pt.). 
H. I wonder if you used an 81pt font and scaled it down what that would look 
like?
We are too clever for that ;-) Its not the user point size, its the 
final device scaled

size that affects this decision. ie 80 *pixels*.

-phil.

I'm curious on the animated box though as to what you are seeing that you like. Is it 
pixel snapping but its moving fast enough that it looks OK? Or is it that the AA 
algorithm is better for this case? If you did a screen capture would it be 
high enough quality to show exactly what it is you see?

Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Richard Bair

 The text in PowerPoint is very likely outlines (treat the text as shapes) 
 since there isn't much text per slide and its usually very large (in fact 
 most render engines stop rendering text as glyphs at a given size -- for us 
 it is  80pt.). H. I wonder if you used an 81pt font and scaled it down 
 what that would look like?
 We are too clever for that ;-) Its not the user point size, its the final 
 device scaled
 size that affects this decision. ie 80 *pixels*.

You are right, I had forgotten how clever we were :-). So either by specifying  
a much larger font size and scaling between 1   1, or by having a normal font 
but scaling it up so that the final size is the equivalent of  80pt font, then 
it should end up with outlines and everything is great (but of course FPS will 
degrade).

Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-31 Thread Scott Palmer

No problem.  I wish I took a look sooner!


Scott

On 2013-05-31, at 4:45 PM, Richard Bair richard.b...@oracle.com wrote:

 I pushed the fix to graphics. Thanks Scott for tracking that down! It looks 
 10x better.
 
 Richard
 
 On May 31, 2013, at 9:25 AM, Richard Bair richard.b...@oracle.com wrote:
 
 Patch attached to https://javafx-jira.kenai.com/browse/RT-29801. I'm not 
 seeing any stutter on my Mac, interested to hear the experience on Windows.
 
 Richard
snip

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-30 Thread Daniel Zwolenski

A little bit more esoteric, but some not very nice looking rendering when
animating a very lightly styled Node:
https://javafx-jira.kenai.com/browse/RT-30830


On Fri, May 31, 2013 at 12:07 PM, Daniel Zwolenski zon...@gmail.com wrote:

 Jittery text when scaling in an animation:
 https://javafx-jira.kenai.com/browse/RT-30827


 On Fri, May 31, 2013 at 12:01 PM, Richard Bair richard.b...@oracle.comwrote:

 Wow. Thanks!

 On May 30, 2013, at 6:48 PM, Daniel Zwolenski zon...@gmail.com wrote:

 I have replicated the z-order problem with the Tower Defender game and
 the Canvas: https://javafx-jira.kenai.com/browse/RT-30826


 On Fri, May 31, 2013 at 1:26 AM, Richard Bair richard.b...@oracle.comwrote:

 Note this is only for Mac.

 On May 30, 2013, at 7:54 AM, Richard Bair richard.b...@oracle.com
 wrote:

  Anybody interested in jitter ought to look at
 https://javafx-jira.kenai.com/browse/RT-26702
 
  Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-29 Thread Richard Bair

 Did we try turning cache to true and cache hint to SPEED?
 
 A simple game I wrote used some basic animation of about 50 nodes with 
 effects applied to them (translucent, blur, sectioned viewports into a large 
 Image) and without caching ran painfully slowly.  Setting caching to true and 
 using cache hints (just on the animated nodes) made a massive performance 
 difference (on a macbook air), it was the difference between a game which was 
 playable and a game which was not (i.e. framerate did not drop to single 
 digits and the air's fan didn't spin up).  
 
 Turning on caching for select nodes was the easiest and single biggest 
 performance improvement I got for the game.

Is the source for that available?

 We had an embedded hack-fest a couple weeks ago in which performance on 
 desktop went from 320-800+fps on table view scrolling, which in large 
 measure came down to reducing the number of state switches on the graphics 
 card (and the resulting decrease in the number of OpenGL calls).
 
 I realize the above statement is to do with internal optimizations, but 
 should I, as a user of the JavaFX API ever have to worry that the way in 
 which I write my user code may result in something like an increased number 
 of state switches on the graphics card?  
 
 Or should I just be able to ignore that kind of stuff as an implementation 
 detail, kind of like when I drive my car, I press the accelerator and it goes 
 and I don't really need to worry much about how that happened? 
 
 The difficulty for me here is that I don't know what a state switch on a 
 graphics card is and have no way of knowing whether a particular code path is 
 triggering a lot of switches.
 
 It seems like an aim for JavaFX is to not require the developer be a 
 low-level mechanic to make things work.

From a high level that is the aim -- relieve the developer of the burden of 
being a graphics expert. However some things (like the performance difference 
of a box blur vs. a gaussian blur, and image pixel format differences) are 
inherent to the problem space. If anything those are issues where the lower 
level details are leaking up (knowing what algorithm is being used for a blur 
-- there is a speed / quality tradeoff to be made, but many people wouldn't 
know off the top of their head which is which between a Box and Gaussian).

Some things (state switches) are also inherent in the medium. We can in some 
cases decrease this overhead for you, but in other cases we won't be able to 
and the developer will have to learn this particular set of performance tricks. 
There is still a place for some high quality JavaOne talks I guess :-)


 We should never require you to have to follow a 15 point performance plan 
 just to get acceptable performance, or to avoid choppiness
 
 Nevertheless, an official performance guide would be useful (like Android's: 
 http://developer.android.com/training/best-performance.html).

The docs team has been working on one, but I don't know what the ETA is. In the 
meantime, we ought to populate the wiki. Anybody want to take an ownership role 
on that and we can submit performance ideas?

Thanks!
Richard

Re: JavaFX graphics performance and suitability for advanced animations

2013-05-29 Thread Hervé Girod

Hello,

Concerning my previous question, is it planned to provide some kind of shape  
drawing for JavaFX 8 in the graphic context, or is it safer to assume that the 
scene graph will be the preferred way to handle this (apart from the svgpath 
drawing of course)?

I have the same kind of question about attributed strings which are handled 
using the TextFlow node in JavaFX 8, but for which there is no direct way to 
handle them in the canvas graphic context.

We are currently trying to draw complex and animated map overlays in JavaFX.

We did that drawing directly in the graphic context in swing, and we assumed 
that it was safe to use the JavaFX canvas graphic context to do the same thing, 
but are now not so sure that its the right way to handle it. I'm not talking 
about the current JavaFX 2.2 API, but rather what you are planning for Java FX 
8.

Herve

Sent from my iPhone

On 29 mai 2013, at 02:40, Herve Girod herve.gi...@gmail.com wrote:

 Thanks for your answer!
 
 As for our experience, we are currently migrating a big UI application (Java 
 ARINC 661 Server: http://sourceforge.net/projects/j661/)  from being 
 Swing-based to JavaFX based. We still keep the Swing compatibility, but we 
 found that using the JavaFX scene graph makes things MUCH more simple for us. 
 And in our very preliminary tests it does seem that our performance is good 
 (the application is almost completely ported and working, but several of our 
 custom widgets implementations still have to be implemented in JavaFX, so we 
 don't have direct comparisons yet).
 
 However, as you talk about the scene graph / the canvas API, I have a 
 question. We are mostly rendering controls and Shapes (exactly what JavaFX 
 scene graph is about), but we also have to render Map overlays (with 
 waypoints, flight plans, etc...). We used to do it by overriding the 
 paintComponent method of a custom Component in our Swing implementation, 
 dealing directly with the Graphics2D Layer. The natural path for us with 
 JavaFX would be to use the Canvas widget, and GraphicContext, but reading 
 your answer, I begin to suspect that we could maybe achieve a better 
 performance with a simpler architecture by using directly the scenegraph for 
 that too. What do you think?
 
 Herve
 
 
 2013/5/29 Richard Bair richard.b...@oracle.com
 Hi John,
 
  1.   Can someone from Oracle please outline the full range of
  applications for which JavaFX is or will be suitable for?
 
 That's a pretty broad question. Lots of stuff? At a minimum everything Swing 
 and SWT were used for, as well as mobile and embedded UIs, rich media, 
 graphics, etc. I don't expect somebody to write Halo 5 with it.
 
  2.   Is there something inherent in the JavaFX architecture (such as
  CPU/GPU interaction, the performance of the JVM or the Java language 
  itself)
  that limits its suitability and thus effectiveness in advanced
  animations/visualisations?
 
 Absolutely not, in fact, quite the opposite. The basic architecture 
 (threading model, GPU usage model, etc) is designed for high concurrency and 
 throughput. Some of the features in Controls though (like CSS lookup, color 
 derivation, etc) put a tax on performance. When it wasn't exposed in the 
 API, every design decision is made with performance as a for most thought. 
 When it comes to API usability is considered primarily but performance is 
 also always considered (along with security). And for every feature that 
 adds weight, there is a way to avoid it when absolutely necessary.
 
  3.   Is this choppiness and lack of smoothness I have experienced
  typical of JavaFX performance or is it some issue with my
  environment/drivers etc.?
 
 Hard to say. I saw a couple weeks ago a machine where scrolling the table 
 view was 14fps whereas it was 320fps for me. The difference was the other 
 system was falling back to the software pipeline. To determine what you're 
 seeing, we need to know whether what you're running is producing 
 consistently slow results or erratic results. Also, we need to know whether 
 you are render bound or compute bound. What's taking so long to complete?
 
 We have seen situations where we are preparing a frame but never rendering 
 it, which might also be contributing to the choppiness.
 
  4.   Is JavaFX more targeted at form-based UIs rather than high
  performance graphics?
 
 No.
 
  5.   Do you have any other comments on JavaFX and its suitability for
  advanced animations and visualizations?
 
 The biggest issue at present architecturally is that we don't expose any way 
 for you to *really* draw without the scene graph. The Canvas gets you 
 partway there, but ultimately that guy is still just buffering up drawing 
 commands and issuing them later against a texture, rather than allowing you 
 to go directly down to OpenGL. So that's a feature that is missing that is 
 going to impact some people.
 
 Instead, you have to do everything with the scene graph which in more

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

Re: JavaFX graphics performance

JavaFX graphics performance

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

RE: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

Re: JavaFX graphics performance and suitability for advanced animations

31 matches

Site Navigation

Mail list logo

Footer information