Excerpts from Hieu Trung Le's message of Mon Jan 17 03:35:13 +0000 2011: > Robert, > > I would like to know more on the allocate/paint process of the > clutter-actor, could you please provide more detail on that? So if I > apply the scenegraph optimization, I will hook into those function, is > that correct?
There's a lot that could be said about how an actor is allocated/painted so that's a hard question to answer so sorry if I don't cover the details you are after... At a high level Clutter has a "Master Clock" that is responsible for driving the progression of animations and re-painting the stage. It will ensure that actors are allocated before painting. See clutter-master-clock.c:clutter_clock_dispatch() and clutter-stage.c:_clutter_stage_do_update() for more details about the master-clock and how we prepare for a new frame. For actual painting of actors we basically traverse the all actors in the scenegraph starting from the stage. The process starts in the individual backends, so for example in the GLX backend clutter-stage-glx.c:_clutter_stage_glx_redraw() calls clutter-stage.c:_clutter_stage_do_paint() and that calls clutter-actor.c:clutter_actor_paint() for the stage which will then be called for all the other actors too and does the following: - skip painting if transparent - skip painting if not mapped - apply actor transformations - apply actor clipping - try to cull the actor - run ClutterEffect pre-paint callbacks - emit "paint" signal - this is where individual actors draw using Cogl - run ClutterEffect post-paint callbacks The allocation mechanism is something that's useful for ui's that make heavy use of 2D layouting policies - e.g. grid or table layouting or simple vertical list layouting. The basic idea is that actors can report preferences about their size to their parent (The "layout manager") and their is a formal allocation process to negotiate these sizes that happens before we paint a new frame (To see where it starts see clutter-stage.c:_clutter_stage_maybe_relayout()). This is a separate scenegraph traversal to the paint traversal and instead of calling clutter_actor_paint() for each actor we instead call clutter_actor_allocate() which does: - applies constraints to update allocation (constraints set using clutter_actor_add_contstraint()) - skip anything else if the actor isn't marked with "needs_allocation" - calls actor's allocate vfunc - queues a redraw for the actor. There's a lot more that could be said, and I'm not sure what kind of optimizations you are thinking of to know what you need to hook in to, but maybe the above outline will be of some help or else you may be able say more specifically which other details you are interested in. kind regards, - Robert > > Thanks, > -Hieu > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of > Robert Bragg > Sent: Thursday, January 13, 2011 8:34 PM > To: James Moschou > Cc: clutter-app-devel-list > Subject: Re: Optimise painting of stage > > Hi James, > > It could be worth you trying Clutter master if you aren't already, to > see if your application can take advantage of the automatic > clipped-redraws and culling optimizations that landed during this > development cycle. > > The clipped-redraws optimization aims to automatically determine the > bounding box of the actors that have changed while preparing to draw the > next frame so that, for example, if you have only moused over a button > which has changed its highlight then the bounding box just covers that > button and when we come to redraw we actually scissor all rendering to > that button so we wont touch any pixels outside that box. Previous > versions of clutter would instead have to redraw the entire stage. > > The second optimization is applied when we are traversing the > scenegraph. It takes the clip-box determined by the above > optimization and then for each actor it starts by checking if the actor > intersects the current clip-box if it doesn't then further processing of > that actor is immediately skipped. > > So with just the clipped-redraws optimization we know we won't draw any > pixels outside the clip-box of around the button, but we are still > relying on the GPU to do quite a lot of work potentially to cull all the > geometry outside that region. With the culling optimization we avoid > even sending geometry to the GPU and can also avoid lots of application > logic associated with painting actors outside the current clip-box. > > To take advantage of these optimizations your actors need to implement > the get_paint_volume vfunc. The actors from Clutter already implement > this but most of the default implementations will be disabled if the > actor is sub-classed, because we can't make any assumptions about what > was changed in the sub-class. > > There is a visual debugging aid available if you export > CLUTTER_PAINT=redraws or CLUTTER_PAINT=paint-volumes before running you > application which can show what parts of the stage are being redrawn. > > There probably needs to more documentation about this stuff, so if you > have any issues with getting clipped-redraws/culling to work with your > application please ask for more details, and we'll try our best to help. > > kind regards, > - Robert > > Excerpts from James Moschou's message of Mon Jan 10 15:03:05 +0000 2011: > > Hi, > > > > Is there anyway to capture the paint 'output' of an actor plus child > > actors, and store it in a texture? The purpose being to simply repaint > > that texture as an optimisation, instead of painting each individual > > child actor. > > > > My situation is that I have two 'scrollviews' as it were, the classic > > set up of a sidepane on the left with expandable items, and a main > > content view in the right pane. Each sidepane item actor has child > > actors for the label, icon and expander, so even just considering the > > ones actually visible there are still a lot of actors. The lag happens > > when you scroll the content view, since it has to repaint the entire > > stage for every motion event, including the sidepane items > > unnecessarily. Really I should be able to cache this portion of the > > stage, since it doesn't change when the content view is being > > scrolled. > > > > Also capturing the output of an actor would further improve the > > scrollview's in that I could shift the texture across, and only paint > > the newly revealed portion. > > > > Thanks, > > James > -- > Robert Bragg, Intel Open Source Technology Center > _______________________________________________ > clutter-app-devel-list mailing list > [email protected] > http://lists.clutter-project.org/listinfo/clutter-app-devel-list -- Robert Bragg, Intel Open Source Technology Center _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
