Hi;
On 16 December 2016 at 00:52, Hieu Le Trung <
hieuletrung gmail com> wrote:
I'm using clutter 0.8. I wonder if there's any issue if I call clutter_timeline_stop during the new-frame callback?
Welcome, time traveller from the year 2008! :-)
Yes, you can call clutter_timeline_stop() within a ::new-frame
callback; the timeline will simply remove itself from the pool.
Yes, I know it's quite old but it's the last one with fixed point implementation.
I encounter crash in g_slice_free around this line
clutter_timeout_unref (l->data);
pool->dispatched_timeouts = g_list_delete_link (pool->dispatched_timeouts, l);
And it happens during a new-frame callback and we call clutter_timeline_stop at the end of a timeline. The timeline is looping. Maybe we change the timeouts/dispatch_timeouts during the clutter_timeout_pool_dispatch.
Checking the note, I wonder if it's relating to this one or not.
* Every timeline shares the same #ClutterTimeoutPool to decrease the
* possibility of starving the main loop when using many timelines
* at the same time; this might cause problems if you are also using
* a library making heavy use of threads with no GLib main loop integration.
*
* In that case you might disable the common timeline pool by setting
* the %CLUTTER_TIMELINE=no-pool environment variable prior to launching
* your application.
Currently I try to disable the pool for now.
