John, Greatly appreciated, thank you.
We should start simple and work our way up. Since we've spent most of our time working on raw frame rates, perhaps it would be best to face down the jitter problem first. Lets start with something simple: a basic translate transition of a rectangle, and see how that goes. I've pushed to the Graphics repo "TranslatedRectangle" which is just a single rectangle, animated horizontally, with a linear interpolator so that any jitter would show up easily and immediately. On a few-day old version of the workspace I saw an occasional stutter on Mac. It might be GC, or it might be something else (not sure). I've just updated to the latest repo and will run it again after I have a build. I'm going to add a wiki page to keep track of FPS & Jitter for the sample so we have some numbers, and we can gather the data from a variety of environments / platforms. We need a reliable way to measure the Jitter -- for that I will try to use the PulseLogger. In the meantime, if you can just run this and let me know the results on your system that would be great. After simple translation we can try path animation, or try different types of nodes. Richard On May 31, 2013, at 5:30 AM, "John C. Turnbull" <ozem...@ozemail.com.au> 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.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= >
