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