[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    The competition
From:       richard.bair () oracle ! com (Richard Bair)
Date:       2012-11-30 23:05:38
Message-ID: 85A3B2A2-12A6-48AD-BF2B-BE3F02395D6F () oracle ! com
[Download RAW message or body]

> 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


[prev in list] [next in list] [prev in thread] [next in thread]