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
>>>>       

Reply via email to