Re: [clutter] Threaded widget generation

["Patrick Shirkey" <pshirkey boosthardware com>]

On Sat, November 24, 2012 7:33 am, Emmanuele Bassi wrote:
> hi;
>
> On 23 November 2012 19:48, Patrick Shirkey <pshirkey boosthardware com>
> wrote:
>
> > In an attempt to decrease the build time for my grid with thousands of
> > actors I am looking at threading options. It currently takes about 5
> > seconds to build 25 rows with 130 actors in each row. That's adding
> > approx
> > 5500 clutter.Rectangle()'s to a Clutter.ScrollActor() on my dual core
> > 1.8Ghz with 2048 MB RAM.

Thanks for your detailed reply.

> though I think this is not a great design decision on your part,
> allocating 5000 actors is not going to be a problem. even adding them
> to a container won't take much; though using add_child() will try to
> keep the list sorted, which will result in a O(n log n) behaviour,
> most likely, so you'll probably want to use insert_child_above() or
> insert_child_below(), which are constant time operations. you're also
> probably invalidating the scene graph multiple times - and if you are
> just adding rectangles in a loop, you're most likely blocking the main
> loop, and thus blocking the interactive execution of your application.

At the moment I am just using scrollActor.add_actor().

Is insert_child_[below/after]() faster than add_actor()?


> > I am interested in threading options for clutter.
>
> the current, and only, option right now is: do not.
>
> you cannot call Clutter API from different threads.
>
> > Either way is there a recommendation for number of threads to use or a
> > more efficient method when generating a large grid of actors?
>
> 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?

> 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?

Ex. Is there an example of a clutter "spinner" type widget somewhere for
loading large external datasets (web/db)?


> > 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. It's just the time it takes to build and
display the widget that I am interested in maximising efficiency at this
point.



--
Patrick Shirkey
Boost Hardware Ltd