Re: [clutter] Animations
On Thu, 2009-05-28 at 09:39 +0200, Jonas Bonn wrote: I found two small details to fix up in your version... I'll just submit them to the list as a single patch (trivial stuff). you should use bugzilla - I tend to loose track of stuff sent to the mailing list (it took me ages and a poke on IRC to get to look at your email :-)). ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer| emmanuele.ba...@intel.com Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
Re: [clutter] Animations
On Wed, 2009-05-27 at 21:11 +0300, Henrik Hedberg wrote: Is there really a good reason to assign only one animation object to an actor and readjust that when the clutter_actor_animate* is called again, instead of creating separate animation objects for each call of the clutter_actor_animate*? I don't have anything against composition of multiple animations. the first implementation of the animate() function allowed composition; after some discussions in the office, I decided to remove that because we didn't have the API to stop an animation and avoid conflicting settings. after some months, the composition behaviour was brought up again, this time with more API and some use cases. as a matter of taste, for compositing animations I'd rather have an AnimationGroup and then a clutter_actor_animate_with_group() - more flexible, but obviously it would need to wait the 1.1/1.2 cycle. ciao, Emmanuele. -- Emmanuele Bassi, Senior Engineer| emmanuele.ba...@intel.com Intel Open Source Technology Center | http://oss.intel.com -- To unsubscribe send a mail to clutter+unsubscr...@o-hand.com
[clutter] Re: Finding the source of a memory leak
On Thu, 2009-05-28 at 00:33 -0400, Pierre-Luc Beaudoin wrote: I've spent a lot of time (on many occasions) trying to pinpoint the source of a *huge* memory leak in libchamplain (both when using Clutter 0.8.8 or 0.9). Hum, never mind me posting very late at night... The valgrind results were wrong because I wasn't using G_SLICE=always-malloc G_DEBUG=gc-friendly. I am using Gnome's system monitor to observe libchamplain's demo apps, and browsing around the world can quickly take up to 200 Mb of ram (and it keeps growing). That seems huge considering that at any point in time there is a maximum on 32 256x256 images. I guess I'll continue to investigate. Tell me if such a behavior is to be expected ;) Pierre-Luc PS: here are the more sensible results I got: ==11883== 3,856,203 bytes in 433 blocks are still reachable in loss record 308 of 308 ==11883==at 0x4C21540: memalign (vg_replace_malloc.c:460) ==11883==by 0x4C215FA: posix_memalign (vg_replace_malloc.c:569) ==11883==by 0xECB2763: _mesa_align_malloc (in /usr/lib/dri/i965_dri.so) ==11883==by 0xECF30A2: _math_matrix_ctr (in /usr/lib/dri/i965_dri.so) ==11883==by 0xECB66DF: (within /usr/lib/dri/i965_dri.so) ==11883==by 0xECB6731: _mesa_init_matrix (in /usr/lib/dri/i965_dri.so) ==11883==by 0xEC81107: _mesa_initialize_context (in /usr/lib/dri/i965_dri.so) ==11883==by 0xEC49974: intelInitContext (in /usr/lib/dri/i965_dri.so) ==11883==by 0xEC5A6C1: brwCreateContext (in /usr/lib/dri/i965_dri.so) ==11883==by 0xEC3F560: (within /usr/lib/dri/i965_dri.so) ==11883==by 0x928804A: (within /usr/lib/libGL.so.1.2) ==11883==by 0x9288532: glXCreateContext (in /usr/lib/libGL.so.1.2) signature.asc Description: This is a digitally signed message part
