What is a "ball park" figure (i.e. around the 6-9 month granularity if possible) for the the release date for JDK 10?
> On 22 Jul 2016, at 04:42, Kevin Rushforth <kevin.rushfo...@oracle.com> wrote: > > Oh, I was agreeing with the analysis of what *would* need to be done. I am > not saying that I think it *should* be done, given resources other > priorities, etc. Having said that, as I mentioned in an earlier post a month > or so ago, we will be collecting ideas for possible JDK 10 features once JDK > 9 is finished. Perhaps this could go into the bucket of things to consider, > but it isn't something I would think would be high on the list...compared to, > say, WebGL, some sort of interop with native rendering, updated graphics > pipelines (we're current stuck on DX 9 and GL 2), public API for UI Controls > Behaviors, etc. > > -- Kevin > > > Felix Bembrick wrote: >> Well, I'm putting my hand up for this. >> >> Kevin, would you like to discuss this with me on or offline? >> >> Felix >> >> P.S. Thanks Markus for your insight! >> >> >>> On 22 Jul 2016, at 04:22, Kevin Rushforth <kevin.rushfo...@oracle.com> >>> wrote: >>> >>> Yep. >>> >>> -- Kevin >>> >>> >>> Richard Bair wrote: >>> >>>> I think you just nailed it on the head Markus :-). >>>> >>>> >>>>> On Jul 21, 2016, at 10:56 AM, Markus KARG <mar...@headcrashing.eu> wrote: >>>>> >>>>> The limiting factor is the single-thread architecture of rather all parts >>>>> of JavaFX. The only real difference you see between machines is not >>>>> correlating with neither number of CPU cores nor GPU cores, but only with >>>>> CPU frequency, roughly spoken. Short term fixes will only provide little >>>>> improvement, by optimizing the critical execution path (i. e. produce hot >>>>> spot histogram using a profiler), for example improvement clipping, >>>>> caching, etc. Huge performance optimizations need an architectural change >>>>> within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline >>>>> to use parallel execution in lots of places. Typical design patterns >>>>> would be parallel iterations, work-stealing executors, fibers (a.k.a >>>>> cooperative multi-threading, a.k.a CompletableFuture), and last but not >>>>> least partitioned rendering (a.k.a tiled rendering). >>>>> >>>>> I am pretty sure you can add a lot more ideas to the list and produce >>>>> great performance, scaling linearly with number of CPU cores / GPU cores, >>>>> but this somes at a cost: Risk to introduce hard to track bugs, and >>>>> needed manpower. >>>>> >>>>> If somebody has at least a lot of free spare time, I am pretty sure Kevin >>>>> could easily provide a huge set of work items in this area. :-) >>>>> >>>>> -Markus >>>>> >>>>> -----Original Message----- >>>>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf >>>>> Of Dr. Michael Paus >>>>> Sent: Donnerstag, 21. Juli 2016 12:07 >>>>> To: openjfx-dev@openjdk.java.net >>>>> Subject: Re: Scene graph performance >>>>> >>>>> Hi Felix, >>>>> I have written various tests like the ones you use in FXMark and I have >>>>> obtained similar results. I have even tried to substitute 2D shapes by >>>>> using 3D MeshViews in the hope that this would give better performance >>>>> but the results were not that good. Of course all this depends on the >>>>> specific test case but in general I see that a JavaFX application which >>>>> makes heavy use of graphics animations is completely CPU-bounded. >>>>> The maximum performance is reached when one CPU/Core is at 100%. >>>>> The performance of your graphics hardware seems to be almost irrelevant. >>>>> I could for example run four instances of the same test with almost the >>>>> same performance at the same time. In this case all 4 cores of my machine >>>>> were at 100%. This proves that the graphics hardware is not the limiting >>>>> factor. My machine is a MacBook Pro with Retina graphics and a dedicated >>>>> NVidia graphics card which is already a couple of years old and certainly >>>>> not playing in the same league as your high-power card. >>>>> I myself have not yet found a way to really speed up the graphics >>>>> performance and I am a little bit frustrated because of that. But it is >>>>> not only the general graphic performance which is a problem. There are >>>>> also a lot of other pitfalls into which you can stumble and which can >>>>> bring your animations to a halt or even crash your system. Zooming for >>>>> example is one of these issues. >>>>> >>>>> I would like to have some exchange on these issues and how to best >>>>> address them but my impression so far is that there are only very view >>>>> people interested in that. (I hope someone can prove me wrong on this :-) >>>>> >>>>> Michael >>>>> >>>>> >>>>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick: >>>>>> Having written and tested FXMark on various platforms and devices, one >>>>>> thing has really struck me as quite "odd". >>>>>> >>>>>> I started work on FXMark as a kind of side project a while ago and, at >>>>>> the time, my machine was powerful but not "super powerful". >>>>>> >>>>>> So when I purchased a new machine with just about the highest specs >>>>>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan >>>>>> X GPUs in SLI mode, I was naturally expecting to see significant >>>>>> performance improvements when I ran FXMark on this machine. >>>>>> >>>>>> But to my surprise, and disappointment, the scene graph animations ran >>>>>> almost NO faster whatsoever! >>>>>> >>>>>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with >>>>>> a rudimentary (single) GPU and, guess what - almost the same level of >>>>>> performance (i.e. FPS and smoothness etc.) was achieved on this >>>>>> considerably less powerful machine (in terms of both CPU and GPU). >>>>>> >>>>>> So, it seems there is some kind of "performance wall" that limits the >>>>>> rendering speed of the scene graph (and this is with full speed >>>>>> animations enabled). >>>>>> >>>>>> What is the nature of this "wall"? Is it simply that the rendering >>>>>> pipeline is not making efficient use of the GPU? Is too much being done >>>>>> on the CPU? >>>>>> >>>>>> Whatever the cause, I really think it needs to be addressed. >>>>>> >>>>>> If I can't get better performance out of a machine that scores in the >>>>>> top 0.01% of all machine in the world in the 3DMark Index than an entry >>>>>> level PC, isn't this a MAJOR issue for JavaFX? >>>>>> >>>>>> Blessings, >>>>>> >>>>>> Felix >>>>
