Re: [clutter] Threaded widget generation
- From: Emmanuele Bassi <ebassi gmail com>
- To: Patrick Shirkey <pshirkey boosthardware com>
- Cc: clutter-list gnome org
- Subject: Re: [clutter] Threaded widget generation
- Date: Fri, 23 Nov 2012 20:33:39 +0000
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.
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.
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.
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().
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.
ciao,
Emmanuele.
--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]