hi; On 24 November 2012 12:38, Patrick Shirkey <[email protected]> wrote: > At the moment I am just using scrollActor.add_actor().
Clutter.Actor.add_child() (which is what the deprecated Clutter.Container.add_actor() internally calls) tries to maintain the list of children sorted using the :depth/:z-position property as the sorting key; sadly, we need to maintain that invariant for backwards compatibility, though it's a stupid thing to do (and won't be done any more in 2.0). since insert_child_above/below_sibling() were introduced afterwards, and since they are based on explicit ordering, I could implement them as constant time operations. if you are building a row of actors then you probably want to use them, since you already have an implicit order you want to use. >> pack sibling nodes inside a container, and then add the container to >> the parent, so that you can avoid recursive invalidations inside the >> scene graph. >> > > To paraphrase, it's more efficient to destroy the container, create a new > container, add the children to the container and then add the container > to the parent after all the child actors have been built? yes; the invalidations necessary when adding children will traverse the scene graph (something we're trying to optimize), so if the scene graph is shallow, they will stop sooner. >> use constant time operations wherever possible. >> >> do not block the main loop with your own loops: use lazy loading >> through callbacks inside the main loop, like the ones provided by >> g_idle_add() or g_timeout_add(). >> > > This is what I was trying to get at with threading. Is there an example > somewhere of handling g_idle_add/g_timeout_add with a large array of > actors? I wrote this article years ago, to deal with GtkTreeModel implementations inside gtk: http://blogs.gnome.org/ebassi/documentation/lazy-loading/ the concept still applies: you create a simple state machine, pass the list of actors to add (possibly already ordered) to the callback function you use with idle_add(), and iterate over the list inserting a single child (or a small batch, depending on your time constraints) for each iteration. once the list has been consumed, you remove the idle handler. > Ex. Is there an example of a clutter "spinner" type widget somewhere for > loading large external datasets (web/db)? no, not really; though creating a texture with an image, and then animating its rotation angle using a PropertyTransition() with repeat_count=-1 would do. >>> The target system is a quad core with 8GB RAM so things might be faster >>> with a single "page" of 12 rows but I would like to support smooth >>> scrolling with upto 1024 rows or 85 "pages". >> >> my design suggestion is to have a screen with predefined rows, and >> instead change the contents of the actors, instead of a huge grid that >> you have to translate in order to scroll. >> > > You may be surprised to know that the actual scrolling of the grid with a > large number of rows works smoothly on this machine in all directions with > "EASE_OUT" for the easing mode. I'm not overly surprised: ScrollActor uses transformations to achieve the scrolling effect, which means that the scene graph is not invalidated at all. :-) > It's just the time it takes to build and > display the widget that I am interested in maximising efficiency at this > point. lazily loading actors and data is usually a good technique, especially when dealing with libraries like Clutter which are based on a main loop. also, as I said, trying to use as many constant time operations - or even linear time operations with a small input - usually allows you to preserve as much of your time budget (which is 16 milliseconds, for 60fps) as possible. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ _______________________________________________ clutter-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/clutter-list
