On Sat, November 24, 2012 7:33 am, Emmanuele Bassi wrote: > hi; > > On 23 November 2012 19:48, Patrick Shirkey <[email protected]> > 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 _______________________________________________ clutter-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/clutter-list
