[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: Performance-limiting characteristics of Nodes
From:       Gerrit Grunwald <han.solo () muenster ! de>
Date:       2013-12-30 19:16:41
Message-ID: A8B45DEE-107F-46F0-8B4A-41034AD2EA8E () muenster ! de
[Download RAW message or body]

yep that's exactly what I figured out too...Pi needs some special treatment and \
optimized for Pi doesn't mean optimized for embedded in general cause Beagleboard \
really showed different behavior.

Cheers,

Gerrit

> Am 30.12.2013 um 19:48 schrieb Jasper Potts <jasper.potts@oracle.com>:
> 
> Removing/Adding nodes has a high cost. So doing that in a animation or any \
> performance important area is not a good idea. I have gone to lengths to hide the \
> node creation with apps I have built.  
> Using small number of nodes with most drawing done with css can be good practice. \
> But CSS can be expensive so if it changes often then might be better using code and \
> Region API.  
> Path performance is bad on Pi for two reasons. 1) CPU is week so takes a while to \
> compute mask pixels 2) the bus is slow between GPU and CPU. So changing paths is \
> bad but drawing a static path many times should be fine.  
> The Pi has special performance characteristics that are unique because of very slow \
> CPU and data bus but really fast GPU. By the numbers it's GPU is as fast as Intel \
> HD found in most corporate laptops. But the CPU is slower than a Pentium II.  
> That means performance tuning for Pi  may not give same results on other devices. \
> For example Beagle Board is  quite different as CPU is almost 2x Pi but GPU power \
> is more in live with CPU and much slower than Pi.  
> Jasper
> 
> 
> 
> > On Dec 30, 2013, at 3:39 AM, Tom Eugelink <tbee@tbee.org> wrote:
> > 
> > 
> > "removing and re-adding nodes to the scenegraph", yeah, sounds like a good \
> > suspect. 
> > I just got offered a commercial JavaFX project (which I ended up not doing \
> > because of all my other work) where the client said that they tried doing it \
> > themselves, but had all kinds of architectural issues they needed me to solve. \
> > Personally I experienced something similar Gerrit explains here when trying to \
> > write my Agenda control, it appears the first time you do JavaFX you'll be doing \
> > it wrong. Even though the learning curve is much less than Swing's, there still \
> > is one. It may be a good idea to get some "best practices" going. 
> > Tom
> > 
> > 
> > > On 2013-12-30 12:09, Gerrit Grunwald wrote:
> > > I'm pretty sure that one performance drawback in these gauges is related to \
> > > constantly removing and re-adding nodes to the scenegraph in the layoutChildren \
> > > method. This might be the reason why even static drawing code will be handled \
> > > even if it was not necessary. One reason why in the Enzo controls I add nodes \
> > > only once to the scenegraph and from that point on only modify the nodes. On \
> > > the Pi I think one reason for performance problems might be (not sure) that \
> > > paths are rastered by the cpu and because I use a lot of paths and the cpu is \
> > > not that powerful it leads to performance decrease when using lots of nodes \
> > > containing paths but that's more a guess... 
> > > Cheers,
> > > 
> > > Gerrit
> > > 
> > > mail    han.solo@muenster.de
> > > web    harmonic-code.org
> > > twitter hansolo_
> > > 
> > > > Am 30.12.2013 um 11:01 schrieb Felix Bembrick <felix.bembrick@gmail.com>:
> > > > 
> > > > Yes Tom, I also came to the conclusion that most of the nodes in those
> > > > (awesome) gauges are largely static and would rarely, if ever, become
> > > > "dirty" so the inference that it's excessive work on the scenegraph would
> > > > seem unlikely as the cause of the performance degradation.
> > > > 
> > > > It does look to me that there is some inherent impact on performance
> > > > associated simply with having more nodes.  I hope Richard or someone with
> > > > intimate knowledge of the innards of JavaFX rendering could chime in here...
> > > > 
> > > > 
> > > > > On 30 December 2013 20:50, Tom Eugelink <tbee@tbee.org> wrote:
> > > > > 
> > > > > 
> > > > > I also watched Gerrits presentation, and he put a lot of emphasis on the
> > > > > difference between drawing using nodes and drawing using CSS. One of the
> > > > > examples was one of his famous gauges, where he used a number of gradients
> > > > > to draw the background. His initial approach was one-node-per-gradient, so
> > > > > a node for the background, one for the upper shadow, one for the lower,
> > > > > etc. This resulted in a lot of nodes and he says the Pi has a maximum of
> > > > > about 120 nodes. Now, these background nodes (and all others that make up
> > > > > the dial) are static nodes, they do not easily go dirty. So I'm not sure
> > > > > that that is the problem Gerrit experienced.
> > > > > 
> > > > > That said, the other approach where he tries to do as much in one node as
> > > > > possible, using CSS, insets and multiple backgrounds/fills seems like a
> > > > > much clear implementation. So there are other advantages as well. But never
> > > > > the less it would be interesting to see what the performance issue really
> > > > > is, given your statement.
> > > > > 
> > > > > Tom
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > On 2013-12-30 1:50, Jasper Potts wrote:
> > > > > > 
> > > > > > My experience was it is not the number of Nodes. It's the number of Nodes
> > > > > > that are changed/dirty in a single frame. So having a scene with 500 \
> > > > > > nodes may take a couple of seconds to render first time but then you can \
> > > > > > animate a couple of those nodes at 60fps if you done make too big a area \
> > > > > > dirty. 
> > > > > > Performance issues are one of two things too much SceneGraph work or too
> > > > > > much Graphics card work. You can use pulse logger to determine which \
> > > > > > issue you are having.
> > > > > > 
> > > > > > Jasper
> > > > > > 
> > > > > > On Dec 29, 2013, at 3:15 PM, Felix Bembrick <felix.bembrick@gmail.com>
> > > > > > > wrote:
> > > > > > > 
> > > > > > > I just watched the excellent presentation by Gerrit Grunwald "Use the
> > > > > > > force
> > > > > > > Luke" on Parleys and in it he mentions that one of the key ways to
> > > > > > > improve
> > > > > > > performance is to limit the number of nodes in the scenegraph.  He also
> > > > > > > mentions that on such devices as the Raspberry Pi the maximum number of
> > > > > > > nodes viable before performance degrades significantly is very, very
> > > > > > > limited.  Further, he then goes on to demonstrate that the equivalent
> > > > > > > visual appearance can be achieved by other means such as CSS, Canvas \
> > > > > > > etc. where the number of nodes is much less.
> > > > > > > 
> > > > > > > The implication here is that there is a performance-limiting effect of
> > > > > > > Nodes.  If the device's GPU is capable of rendering certain graphics
> > > > > > > primitives, effects, transitions etc. and JavaFX is capable of "making
> > > > > > > them
> > > > > > > happen" by one way or another, I am curious as to why the simple \
> > > > > > > presence of Nodes limits performance so significantly.
> > > > > > > 
> > > > > > > The obvious conclusion is that Nodes use memory and perhaps the
> > > > > > > associated
> > > > > > > overhead is the cause but given that we are largely talking about GPU
> > > > > > > based
> > > > > > > processing I find it hard to believe that it's as simple as this.
> > > > > > > 
> > > > > > > So what is it about the nature of Nodes that causes them to have such a
> > > > > > > limiting effect on performance?
> > > > > > > 
> > > > > > > Cheers,
> > > > > > > 
> > > > > > > Felix
> > 
> > 


[prev in list] [next in list] [prev in thread] [next in thread]