Hi, On Mon, Feb 25, 2008 at 11:07 AM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > Clutter diverges quite quickly from a 2D canvas as soon as you start > considering rotations around the X and Y axis, and the depth handling; > how would you handle the issue of actors at different angles and depths? > I mean: would a container be able to reflow around these kind of > transformations?
I think it does not; all of that stuff is done only at paint-time. Scale, rotation, depth, and translate (anchor point) affect the paint box, but not layout. At least that's what my patch does and what I think is simplest and most useful. One implication is that if you animate any of these paint-only transformations, the layout is not recomputed for each frame. > another question pertains the recomputing the layout, especially the > chain up to the stage; how would a complex layout impact the > performances of Clutter? you note, in clutter_actor_get_allocation(): Ah, what I was saying in this comment is that get_allocation() really should only be called inside paint(). In that context, it is just returning actor->allocation. If someone calls it elsewhere, they're doing something that really does not make sense, because the allocation could be outdated. So the comment is just about how to try to make sense of what they might mean. I ended up making get_size() be the "do what I mean" function, so I think get_allocation() should probably just return the most recent allocation even if it isn't really valid. That will always be fast, at least. > I'm actually quite scared of people blocking a relayout operation (and > thus a redraw) during an animation, which would suck to no end. > personally, I'd rather limit the options rather than allow people to do > stupid things. Relayout should be very fast, because if requests have not changed for some reason, they are cached. If an entire group is unchanged, then there won't be a need to traverse it during relayout. Most actors have a trivial implementation of size request that just returns a number. The only actor with an "expensive" (relatively) size request operation is ClutterLabel, but note that as long as the label's text and attributes are unchanged, the request will be cached and there won't be a need to create and measure the PangoLayout. In principle layout could even make things faster, since all the resizing etc. can be queued to an idle and compressed, rather than doing it synchronously each time someone changes a property on an actor. There may be some fine-tuning needed as to exactly when we do layout; as you say, maybe another thread (or just don't force relayout before painting) could make sense - i.e. have the painting always use latest allocations, even if those aren't up-to-date. That could lead to artifacts, but could be faster. I would say don't prematurely optimize, just see how it goes. Havoc -- To unsubscribe send a mail to [EMAIL PROTECTED]
