The competition
Richard Bair
richard.bair at oracle.com
Fri Nov 30 15:05:38 PST 2012
> Perhaps jfx has a higher frame rate, I don't know. That's quite a narrow benchmark though and from my experience using jfx, and also building very similar applications in jscript (ie dynamically updating trees, tables, forms with page animations) the jfx app was noticeably laggy and/or jittery on reasonably high end win7 desktops and laptops. Those same computers running the latest version of Google Chrome achieve better visual outcomes for similarly complex/rich jscript screens. Whether this is what you mean by "simple" screens I couldn't say but I would say they are the standard, modern, popular, rich web application screens and my review was preceded with the statement that web was the context I was reviewing it in.
This feedback is unfortunately not actionable, so I don't know how to help. WIthout a test case or benchmark to look at, all I can say is that we are not seeing anything like this on windows. There is an issue we're fixing right now regarding event starvation on windows, but that is unlikely to be what you noticed. We've had many customer conversations in the enterprise space where guys had tried web first, found it didn't even get close to the performance they needed, switched to JavaFX and were very pleased with the results.
I just wanted to make sure that the claim that the browser was as fast as JavaFX didn't go without comment, because I've seen no data to support that. All the other points regarding deployment are of course irrefutable, which is why I didn't comment on any of that.
> As a side note, I also can't see any technical reason why Chrome for example would have any limitations on it that java doesn't have.
Two huge technical reasons: JavaScript and DOM. Both have "features" of their design that preclude the kinds of performance optimizations that we can do on Java / JavaFX.
> The raspberry pi would feature very low in terms of market share in the space I am talking about.
I mentioned PI, though even on desktop we're 5-10x faster on GUIMark text benchmark from any of the browsers. (10x Firefox). We haven't published these numbers because our benchmarks are not open source -- see below.
> Also it was all just my personal analysis of the space, provided as a side note to your main work since oracle has stated its not a space it is focusing on. Performance was just one small part of my breakdown of the space.
I know, but I wasn't going to let a statement that we're slower than browsers to go uncontested :-). From all the data I have (and I'm happy for any bug reports with benchmarks indicating areas we need to improve!) we're much faster than the browsers in all phases (images, text, and vectors). On Mac we have serious smoothness issues (we know what those are and are working on them), but we've not seen these issues on Windows. There are outstanding bug reports on things like the rendering performance of Paths and Lines, but even our results on GUIMark2 indicates we're much faster than the browser.
> I'm always open to rebuttal and generally pretty good at taking on board corrections and better ideas if they are tangible. The performance one is hard to quantify currently because while there are many jscript apps out there to look at, there are very few (any?) publicly available, commercial quality jfx apps out there to compare to. If you can provide some example of real world apps where the jfx experience is better than can be achieved with jscript in the latest chrome or Firefox then I will very happily change my opinion.
I'm working on getting our benchmarks open sourced with everything else. But if you've got a sample handy where the browser is faster, I'd love to see it and fix it. I'm manic about performance (ask the team). We have been very, very focused on performance from the get-go, complete with regular performance regression analysis, repeatable benchmarks, engineers who's full-time responsibility is performance analysis and tooling, benchmark tools, etc.
Richard
More information about the openjfx-dev
mailing list