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. Regards, James _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
