Hi Richard,
Let me start by saying that on re-reading my last post I realised
that it
had a "tone" which was not intended and may have appeared overly
critical or
negative. If you or anyone on the JavaFX development team were
offended in
any way then I am sorry. All I can say in my defence was that it was
posted
after midnight at the end of a very long day...
Anyway, I want you to know that I am not here to engage in gratuitous
JavaFX
bashing or trolling. In fact, I am one of the strongest supporters and
proponents of JavaFX that there is. I am in the process of bringing
JavaFX
into my (large corporate) workplace and am involved in a private project
which I take very seriously that will also be using JavaFX.
Consequently I
have more at stake and more interest in having JavaFX succeed than
most. If
everything goes according to "plan", I will be focussing on Java and
especially JavaFX for the next 10 years or so.
>From my perspective it is important to address the features or
issues with
JavaFX that the competitors perceive as weaknesses and reasons why the
technology is a "dead duck". The JavaFX community is vibrant with many
well-known evangelists who are doing a very good job of promoting
JavaFX and
highlighting its many benefits but it is rare for them to say anything
negative about it.
Is this because there are no "negatives" with JavaFX or is just that
they
steer clear of them? I tend to think that they prefer to concentrate
on the
pros rather than the cons and that's fair enough, they are there to
further
the cause of JavaFX rather than detract from it.
I am someone who has been told tends to "say the things that other
people
think but are afraid to say". I am not out to win any popularity
contests
and will call a spade a spade. As I said, when it comes to JavaFX, I am
doing this because we need a balanced argument that confronts the
opposition
head on. Many of the criticisms levelled at JavaFX by competitors
have a
valid foundation and as community we need to be able to respond to them.
The issues I highlighted in my last post are real and I very much
believe
that if solutions are not found then JavaFX is going to struggle in the
"real world" in the longer term.
The market for graphics toolkits and cross-platform developer tools is
extremely competitive and cut-throat and no one is going to give
JavaFX a
break. I am merely trying to bring these issues up within the JavaFX
community so we can address them as soon as possible. As I said, I
am very
much *for* JavaFX. I both want it to succeed and *need* it to succeed.
As Daniel Zwolenski has posted, animations which I have found to perform
quite poorly in JavaFX work very well inside a web page with JavaScript
(with or without Canvas) on the exact same machine. Clearly then
there must
be something fundamentally different in the way these competing
technologies
are handling animations. To me this says that it must be possible for
JavaFX to achieve similar levels of performance as other technologies
are
able to extract better performance out of the same OS and hardware.
This says to me that developers who are not necessarily tied to the Java
language for any reason would obviously choose a technology that
performs
better. This is the concern. This is the kind of thing we need to
redress.
Whilst my comments may be seen to be unnecessarily critical, I am
being far
kinder than our competitors. New features can be added to JavaFX but
if the
"core" features are not working as well as the other products on the
market
then clearly there is a real problem.
I made a comment along the lines that I feel the animations in the
Ensemble
demos do very little to promote JavaFX and, as harsh as it may sound, I
stand by that. Scott Palmer has echoed those sentiments with his recent
commentary on Brick Breaker. While obviously it's a lot of work, JavaFX
needs at least one truly awesome demo that showcases everything it
has to
offer. If such a demo is not possible with JavaFX as it currently
stands
then that tells us something.
My own personal feelings about JavaFX are that it is an absolutely
awesome
product with amazing potential. It is a vast improvement over Swing
and,
although not many people outside the Java community realise this, it has
features and capabilities that other competing products simply don't
have.
If we can get the basics working better, JavaFX has the potential to
be a
very significant player and not just for developers who have
traditionally
programmed in Java. For me, they are the people we should really be
targeting.
Also, I think the JavaFX development team are doing a first class
job. Even
though I think I made this clear, none of my critical commentary is
directed
at them. I also acknowledge that my references 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=
