Short answer? Maybe. But exactly one more word than any from Oracle ;-)
> On 26 Nov. 2016, at 00:07, Tobias Bley <b...@jpro.io> wrote: > > A very short answer ;) …. > > Do you have any URL? > > > > > >> Am 25.11.2016 um 12:19 schrieb Felix Bembrick <felix.bembr...@gmail.com>: >> >> Yes. >> >>> On 25 Nov. 2016, at 21:45, Tobias Bley <b...@jpro.io> wrote: >>> >>> Hi, >>> >>> @Felix: Is there any Github project, demo video or trial to test HPR with >>> JavaFX? >>> >>> Best regards, >>> Tobi >>> >>> >>> >>> >>>> Am 11.11.2016 um 12:08 schrieb Felix Bembrick <felix.bembr...@gmail.com>: >>>> >>>> Thanks Laurent, >>>> >>>> That's another thing we discovered: using Java itself in the most >>>> performant way can help a lot. >>>> >>>> It can be tricky, but profiling can often highlight various patterns of >>>> object instantiation that show-up red flags and can lead you directly to >>>> regions of the code that can be refactored to be significantly more >>>> efficient. >>>> >>>> Also, the often overlooked GC log analysis can lead to similar discoveries >>>> and remedies. >>>> >>>> Blessings, >>>> >>>> Felix >>>> >>>>> On 11 Nov. 2016, at 21:55, Laurent Bourgès <bourges.laur...@gmail.com> >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> To optimize Pisces that became the Marlin rasterizer, I carefully avoided >>>>> any both array allocation (byte/int/float pools) and also reduced array >>>>> copies or clean up ie only clear dirty parts. >>>>> >>>>> This approach is generic and could be applied in other critical places of >>>>> the rendering pipelines. >>>>> >>>>> FYI here are my fosdem 2016 slides on the Marlin renderer: >>>>> https://bourgesl.github.io/fosdem-2016/slides/fosdem-2016-Marlin.pdf >>>>> >>>>> Of course I would be happy to share my experience and work with a tiger >>>>> team on optimizing JavaFX graphics. >>>>> >>>>> However I would like getting sort of sponsoring for my potential >>>>> contributions... >>>>> >>>>> Cheers, >>>>> Laurent >>>>> >>>>> Le 11 nov. 2016 11:29, "Tobi" <t...@ultramixer.com> a écrit : >>>>>> >>>>>> Hi, >>>>>> >>>>>> thanks Felix, Laurent and Chris for sharing your stuff with the >>>>>> community! >>>>>> >>>>>> I am happy to see starting a discussion about boosting up the JavaFX >>>>>> rendering performance. I can confirm that the performance of JavaFX >>>>>> scene graph is not there where it should be. So multithreading would be >>>>>> an excellent, but difficult approach. >>>>>> >>>>>> Felix, concerning your research of other toolkits: Do they all use >>>>>> multithreading or are there any toolkits which use single threading but >>>>>> are faster than JavaFX? >>>>>> >>>>>> So maybe there are other points than multithreading where we can boost >>>>>> the performance? >>>>>> >>>>>> 2) your HPR sounds great. Did you already try DemoFX (part 3) benchmark >>>>>> with your HPR? >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Tobi >>>>>> >>>>>> >>>>>>> Am 10.11.2016 um 19:11 schrieb Felix Bembrick >>>>>>> <felix.bembr...@gmail.com>: >>>>>>> >>>>>>> (Thanks to Kevin for lifting my "awaiting moderation" impasse). >>>>>>> >>>>>>> So, with all the recent discussions regarding the great contribution by >>>>>>> Laurent Bourgès of MarlinFX, it was suggested that a separate thread be >>>>>>> started to discuss parallelisation of the JavaFX rendering pipeline in >>>>>>> general. >>>>>>> >>>>>>> As has been correctly pointed-out, converting or modifying the existing >>>>>>> rendering pipeline into a fully multi-threaded and performant beast is >>>>>>> indeed quite a complex task. >>>>>>> >>>>>>> But, that's exactly what myself and my colleagues have been working on >>>>>>> for >>>>>>> about 2 years. >>>>>>> >>>>>>> The result is what we call the Hyper Rendering Pipeline (HPR). >>>>>>> >>>>>>> Work on HPR started when we developed FXMark and were (bitterly) >>>>>>> disappointed with the performance of the JavaFX scene graph. Many >>>>>>> JavaFX >>>>>>> developers have blogged about the need to dramatically minimise the >>>>>>> number >>>>>>> of nodes (especially on embedded devices) in order to achieve even >>>>>>> "acceptable" performance. Often it is the case that most (if not all >>>>>>> rendering) is eventually done in a single Canvas node. >>>>>>> >>>>>>> Now, as well already know, the JavaFX Canvas does perform very well and >>>>>>> the >>>>>>> recent awesome work (DemoFX) by Chris Newland, just for example, shows >>>>>>> what >>>>>>> can be done with this one node. >>>>>>> >>>>>>> But, the majority of the animation plumbing in JavaFX is related to the >>>>>>> scene graph itself and is designed to make use of multiple nodes and >>>>>>> node >>>>>>> types. At the moment, the performance of this scene graph is the >>>>>>> Achilles >>>>>>> Heel of JavaFX (or at least one of them). >>>>>>> >>>>>>> Enter HPR. >>>>>>> >>>>>>> I personally have worked with a number of hardware-accelerated toolkits >>>>>>> over the years and am astounded by just how sluggish the rendering >>>>>>> pipeline >>>>>>> for JavaFX is. When I am animating just a couple of hundred nodes using >>>>>>> JavaFX and transitions, I am lucky to get more than about 30 FPS, but on >>>>>>> the same (very powerful) machine, I can use other toolkits to render >>>>>>> thousands of "objects" and achieve frame rates well over 1000 FPS. >>>>>>> >>>>>>> So, we refactored the entire scene graph rendering pipeline with the >>>>>>> following goals and principles: >>>>>>> >>>>>>> 1. It is written using JavaFX 9 and Java 9 (but could theoretically be >>>>>>> back-ported to JavaFX 8 though I see no reason to). >>>>>>> >>>>>>> 2. We analysed how other toolkits had optimised their own rendering >>>>>>> pipelines (especially Qt which has made some significant advances in >>>>>>> this >>>>>>> area in recent years). We also analysed recent examples of >>>>>>> multi-threaded >>>>>>> rendering using the new Vulkan API. >>>>>>> >>>>>>> 3. We carefully analysed and determined which parts of the pipeline >>>>>>> should >>>>>>> best utilise the CPU and which parts should best utilise the GPU. >>>>>>> >>>>>>> 4. For those parts most suited to the CPU, we use the advanced >>>>>>> concurrency >>>>>>> features of Java 8/9 to maximise parallelisation and throughput by >>>>>>> utilising multiple cores & threads in as an efficient manner as >>>>>>> possible. >>>>>>> >>>>>>> 5. We devoted a large amount of time to optimising the "communication" >>>>>>> between the CPU and GPU to be far less "chatty" and this alone led to >>>>>>> some >>>>>>> huge performance gains. >>>>>>> >>>>>>> 6. We also looked at the structure of the scene graph itself and after >>>>>>> studying products such as OpenSceneGraph, we refactored the JavaFX scene >>>>>>> graph in such a way that it lends itself to optimised rendering much >>>>>>> more >>>>>>> easily. >>>>>>> >>>>>>> 7. This is clearly not a "small" patch. In fact to refer to it as a >>>>>>> "patch" is probably rather inappropriate. >>>>>>> >>>>>>> The end result is that we now have a fully-functional prototype of HPR >>>>>>> and, >>>>>>> already, we are seeing very significant performance improvements. >>>>>>> >>>>>>> At the minimum, scene graph rendering performance has improved by 500% >>>>>>> and, >>>>>>> with judicious and sometimes "tricky" use of caching, we have seen >>>>>>> improvements in performance of 10x or more. >>>>>>> >>>>>>> And... we are only just *starting* with the performance optimisation >>>>>>> phase. >>>>>>> >>>>>>> The potential for HPR is massive as it opens-up the possibility for the >>>>>>> JavaFX scene graph and the animation/transition infrastructure to be >>>>>>> used >>>>>>> for a whole new class of applications including games, advanced >>>>>>> visualisations etc., without having to rely on imperative programming >>>>>>> of a >>>>>>> single Canvas node. >>>>>>> >>>>>>> I believe that HPR, along with tremendous recent developments like JPro >>>>>>> and >>>>>>> the outstanding work by Gluon on mobiles and embedded devices, could >>>>>>> position JavaFX to be the best graphics toolkit of any kind in any >>>>>>> language >>>>>>> and, be the ONLY *truly* cross-platform graphics technology available. >>>>>>> >>>>>>> WORA for graphics and UIs is finally within reach! >>>>>>> >>>>>>> Blessings, >>>>>>> >>>>>>> Felix >>>>>> >>> >
