On 25 January 2011 21:37, Robert Bragg <[email protected]> wrote: > 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 >
Cheers, I've set this problem aside for now though. The thing about my particular case is that I'm using an internal UI framework, based on clutter, but where I have a sole Clutter.Actor class which delegates to different view objects, as opposed to having the view objects inherit from Clutter.Actor directly. So I literally have only two types of actors, a view-actor class which inherits from Clutter.Actor and a container-actor class which inherits from Clutter.Group, together both classes are less than 300 lines of code. So I doubt the issue is one single actor behaving weirdly, as they're all the same. I suspect the problem is more fundamental, it might even by the vala bindings since they don't exist yet for clutter unstable. I had to do all sorts of hacks to get the code to compile. Regards James _______________________________________________ clutter-app-devel-list mailing list [email protected] http://lists.clutter-project.org/listinfo/clutter-app-devel-list
