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