Re: [clutter] Threaded widget generation

[Emmanuele Bassi <ebassi gmail com>]

hi;

On 24 November 2012 12:38, Patrick Shirkey <pshirkey boosthardware com> 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/