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