Well, given that you and Benjamin seem to be the only people interested in it, perhaps we should discuss it offline (so as not to bother Oracle or spam list this)...
> On 28 Nov. 2016, at 06:57, Tobias Bley <b...@jpro.io> wrote: > > Where can we read more about your HPR renderer? > > > > >> Am 25.11.2016 um 16:45 schrieb Felix Bembrick <felix.bembr...@gmail.com>: >> >> 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 >>>>>>>> >>>>> >>> >
