[9] Review request: JDK-8168089, Secondary Launchers (*.exe files) are not generated
Chris, Please review the changes about secondary launchers: JIRA: https://bugs.openjdk.java.net/browse/JDK-8168089 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8168089/webrev.00/ --Victor
Re: Optimised, high-performance, multi-threaded rendering pipeline
Short answer? Maybe. But exactly one more word than any from Oracle ;-) > On 26 Nov. 2016, at 00:07, Tobias Bley wrote: > > A very short answer ;) …. > > Do you have any URL? > > > > > >> Am 25.11.2016 um 12:19 schrieb Felix Bembrick : >> >> Yes. >> >>> On 25 Nov. 2016, at 21:45, Tobias Bley 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 : 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 > 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" 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 >>> : >>> >>> (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 >>> Jav
Re: Optimised, high-performance, multi-threaded rendering pipeline
Thanks Benjamin, We studied those products you mentioned when designing HPR and, yes, there is extensive use of shaders and much more utilisation of the GPU in general. We also have the beginnings of a Vulkan-only version written in (coincidentally) Rust which is showing amazing promise. Vulkan is something we are investing a lot of research and effort into. Felix > On 25 Nov. 2016, at 22:25, Benjamin Gudehus wrote: > > Wow, thanks for all the great work (Felix and Laurent)! Marlin and HPR seem > to really fit into what needs to be done to improve the performance. > > Speaking of the Vulkan API: Does HPR use shaders to optimize the rendering or > does this only apply to rasterization (i.e. Marlin)? > > Webrender and Servo (by Mozilla written in Rust) use GPU shaders a lot, along > with parallelized DOM (scene graph) access, aggressive culling and caching > and batching. > > --Benjamin > >> On Fri, Nov 25, 2016 at 11:45 AM, Tobias Bley 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 : >> > >> > 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 >> >> 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" 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 >> : >> >> (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. >> >
In(Sanity) Testing Mondays
Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PST until 1pm PST. Happy testing! Thanks, Vadim
[9] Review request for 8164792: Memory leak in JavaFX WebView
Hi Kevin, Arun, Guru, Please review the below leak fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8164792 Webrev: http://cr.openjdk.java.net/~mbilla/8164792/webrev.00/ Thanks, Murali
Re: Optimised, high-performance, multi-threaded rendering pipeline
A very short answer ;) …. Do you have any URL? > Am 25.11.2016 um 12:19 schrieb Felix Bembrick : > > Yes. > >> On 25 Nov. 2016, at 21:45, Tobias Bley 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 : >>> >>> 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 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" 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 : >> >> (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 >
Re: Optimised, high-performance, multi-threaded rendering pipeline
Wow, thanks for all the great work (Felix and Laurent)! Marlin and HPR seem to really fit into what needs to be done to improve the performance. Speaking of the Vulkan API: Does HPR use shaders to optimize the rendering or does this only apply to rasterization (i.e. Marlin)? Webrender and Servo (by Mozilla written in Rust) use GPU shaders a lot, along with parallelized DOM (scene graph) access, aggressive culling and caching and batching. --Benjamin On Fri, Nov 25, 2016 at 11:45 AM, Tobias Bley 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 >: > > > > 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 > 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" 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 > t
Re: Optimised, high-performance, multi-threaded rendering pipeline
Yes. > On 25 Nov. 2016, at 21:45, Tobias Bley 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 : >> >> 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 >>> 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" 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 : > > (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 > p
Re: Optimised, high-performance, multi-threaded rendering pipeline
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 : > > 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 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" 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 : (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 analyse