On Sat, Jan 22, 2011 at 3:01 AM, James Moschou <[email protected]> wrote: > On 22 January 2011 13:02, James Moschou <[email protected]> wrote: >> On 21 January 2011 22:49, Robert Bragg <[email protected]> wrote: >>> Excerpts from James Moschou's message of Thu Jan 20 13:47:17 +0000 2011: >>>> On 20 January 2011 03:38, Robert Bragg <[email protected]> wrote: >>>> > Excerpts from James Moschou's message of Wed Jan 19 04:56:48 +0000 2011: >>>> >> > 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. >>>> >> >>>> >> I'm having trouble with this. How exactly do they show what parts of >>>> >> the stage are being drawn? Do they flash a rectangle over the stage, >>>> >> or is it more like console output? I don't know what I'm supposed to >>>> >> be looking for. >>>> > For CLUTTER_PAINT=redraws you should see a clear red outline >>>> > highlighting the sub-region that was last redrawn. For >>>> > CLUTTER_PAINT=paint-volumes you should see a 3D wire, bounding box around >>>> > all actors. If the actor isn't actually able to report a paint-volume >>>> > then the box will be blue and will correspond to the actor's allocation >>>> > box. If it does report a paint-volume then the wireframe will be green. >>>> > All the boxes will also be labeled with the actor's type - though >>>> > sometimes this can look very cluttered. >>>> > >>>> > Probably if you aren't seeing anything then you will need to re-build >>>> > your clutter with --enable-debug=yes and --enable-cogl-debug=yes >>>> > >>>> > A common gotcha with the optimization to automatically queue >>>> > clipped-redraws is that application code that g_signal_connects to the >>>> > "paint" signal of an actor will effectively disable that actor from >>>> > being able to report a paint-volume so it can't queue clipped redraws. >>>> > The reason is that clutter has no idea what the application might be >>>> > doing in that paint_handler so it has to assume that it is painting >>>> > outside the reported paint-volume and so by disabling the paint-volume >>>> > the actor's volume effectively becomes the size of the stage. >>>> > >>>> > At the moment there isn't a convenient way to determine if your >>>> > application is doing that besides from manually checking your code or if >>>> > you build clutter from source then look at the implementation of >>>> > _clutter_actor_get_paint_volume_mutable and you will see that we >>>> > test for this using g_signal_has_handler_pending and you can set a break >>>> > point on the failure case and hopefully the backtrace will help you find >>>> > the offending paint handler. >>>> > >>>> > Just to clarify a bit; the odd paint handler used for a few actors in >>>> > your scene shouldn't completely disable the benefits of clipped-redraws >>>> > it's just the actors queuing redraws for a sub-region of the stage that >>>> > shouldn't have paint handlers. I.e. having some kind of icon actor in >>>> > the corner if your window with a "paint" handler shouldn't stop >>>> > automatic clipped redraws working for mousing over buttons in the middle >>>> > if the screen. >>>> > >>>> > It might be worth verifying that you can get the debug options working >>>> > with some of clutter's tests/interactive tests (e.g. I tested a lot with >>>> > test-state for the when adding the automatic clipped-redraws support) >>>> > >>>> >> >>>> >> I haven't really noticed a difference in performance. All I have done >>>> >> is duplicate the implementation of get_paint_volume I found in >>>> >> Clutter.Rectangle. Is this the idea, or does it need to be smarter in >>>> >> some way? Do I need to mark actors as needing to be updated, or does >>>> >> that happen automatically? >>>> > In a lot of cases a get_paint_volume implementation like this should do: >>>> > static gboolean >>>> > my_actor_get_paint_volume (ClutterActor *self, >>>> > ClutterPaintVolume *volume) >>>> > { >>>> > return clutter_paint_volume_set_from_allocation (volume, self); >>>> > } >>>> > >>>> > What we do, in addition, for most actors provided by Clutter though is >>>> > also explicitly check the GType of the actor so we don't make >>>> > assumptions about the paint-volume of sub-classes. You might want to >>>> > also do that if you are providing a toolkit and you don't know how some >>>> > of your actors may have been sub-classed. For new actors though it may >>>> > be best to avoid this though and simply require that sub-classes that >>>> > escape the default paint-volume should also provide a new >>>> > get_paint_volume implementation. >>>> > >>>> > The GType can be checked in your get_paint_volume implementation for >>>> > example like: >>>> > if (G_OBJECT_TYPE (self) != CLUTTER_TYPE_TEXTURE) >>>> > return FALSE; >>>> > >>>> > I hope that helps, >>>> > regards, >>>> > - Robert >>>> >> >>>> >> Regards, >>>> >> James >>>> > -- >>>> > Robert Bragg, Intel Open Source Technology Center >>>> > >>>> >>>> Thanks Robert, >>>> >>>> I hadn't compiled clutter with the debug options. The other half to my >>>> problem was that I wasn't setting LD_LIBRARY_PATH. >>>> >>>> CLUTTER_PAINT=paint-volumes is working as expected: A whole mess of >>>> green rectangles, although the stage one is blue. >>>> >>>> CLUTTER_PAINT=redraws is not working, I still see nothing. I am >>>> definitely not connecting to any paint signals. I checked with gdb and >>>> some printfs, and every actor is reporting its paint volume correctly. >>>> Do you have any tips on how to find the cause of the problem? The >>>> stage is inside a GtkClutter.Embed and libclutter-gtk is still version >>>> 0.10.4 if that is significant. >>> >>> I assume you are using glx not egl? For glx; clipped redraws depend on >>> you either having the GLX_MESA_copy_sub_buffer extension or >>> GL_EXT_framebuffer_blit extension which you can check for via glxinfo. >>> >>> Also note that there is a short warm up period of ~5 frames when your >>> app starts where clipped redraws aren't used. >>> >>> I guess your problem might be something more involved, but perhaps good >>> to check these first. >>> >>> regards, >>> - Robert >>> >>>> >>>> Regards, >>>> James >>> -- >>> Robert Bragg, Intel Open Source Technology Center >>> >> >> I think I've identified the problem as >> Clutter.PaintVolume.set_from_allocation is failing for all actors >> whose "visible" property is set to false. But I'm not sure where to go >> from here. >> >> Cheers, >> James >> > > Actually I don't think that's it, since CLUTTER_PAINT=redraws still > isn't working when I force everything to be visible. I should mention > that CLUTTER_PAINT=redraws is working for the tests though, so I don't > think it's a problem with clutter. I'm just don't know how to go about > debugging my own application.
I wonder if you can try stripping your scenes down until they become simple enough that hopefully the clipping starts to work, and then as you add things back you might see what's upsetting clutter. For debugging purposes this comment copied from clutter-actor.c:clutter_actor_queue_redraw() might give a rough overview of the control flow involved in queuing clipped redraws so you might be able gdb or printf debug clutter to see at which stage things are going wrong: /* Here's an outline of the actor queue redraw mechanism: * * The process starts either here or in * _clutter_actor_queue_redraw_with_clip. * * These functions queue an entry in a list associated with the * stage which is a list of actors that queued a redraw while * updating the timelines, performing layouting and processing other * mainloop sources before the next paint starts. * * We aim to minimize the processing done at this point because * there is a good chance other events will happen while updating * the scenegraph that would invalidate any expensive work we might * otherwise try to do here. For example we don't try and resolve * the screen space bounding box of an actor at this stage so as to * minimize how much of the screen redraw because it's possible * something else will happen which will force a full redraw anyway. * * When all updates are complete and we come to paint the stage then * we iterate this list and actually emit the "queue-redraw" signals * for each of the listed actors which will bubble up to the stage * for each actor and at that point we will transform the actors * paint volume into screen coordinates to determine the clip region * for what needs to be redrawn in the next paint. * * Besides minimizing redundant work another reason for this * deferred design is that it's more likely we will be able to * determine the paint volume of an actor once we've finished * updating the scenegraph because its allocation should be up to * date. NB: If we can't determine an actors paint volume then we * can't automatically queue a clipped redraw which can make a big * difference to performance. * * So the control flow goes like this: * clutter_actor_queue_redraw and * _clutter_actor_queue_redraw_with_clip * * then control moves to: * _clutter_stage_queue_actor_redraw * * later during _clutter_stage_do_update, once relayouting is done * and the scenegraph has been updated we will call: * _clutter_stage_finish_queue_redraws * * _clutter_stage_finish_queue_redraws will call * _clutter_actor_finish_queue_redraw for each listed actor. * Note: actors *are* allowed to queue further redraws during this * process (considering clone actors or texture_new_from_actor which * respond to their source queueing a redraw by queuing a redraw * themselves). We repeat the process until the list is empty. * * This will result in the "queue-redraw" signal being fired for * each actor which will pass control to the default signal handler: * clutter_actor_real_queue_redraw * * This will bubble up to the stages handler: * clutter_stage_real_queue_redraw * * clutter_stage_real_queue_redraw will transform the actors paint * volume into screen space and add it as a clip region for the next * paint. */ Sorry that we don't currently have a good debugging methodology for this. I suppose as more people the try to add paint-volumes we'll learn what the common problems are and this will become easier. kind regards, - Robert _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
