JavaFX graphics performance and suitability for advanced animations

[steve.x.northover at oracle.com]

Like I say, ignore this.

Steve

On 31/05/2013 10:20 AM, steve.x.northover at oracle.com wrote:
> Hi John,
>
> Let's get very specific.  Can you post a small example where the 
> animation performs poorly?  Then we can all get to the bottom of it.
>
> Thanks,
> Steve
>
> On 31/05/2013 8:30 AM, John C. Turnbull wrote:
>> 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.bair at oracle.com]
>> Sent: Friday, 31 May 2013 01:12
>> To: John C. Turnbull
>> Cc: openjfx-dev at 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=
>>
>