Hi Igor,
On Tuesday, 3 July 2012, Igor Chetverovod wrote
Hi David,
probably you should use macros:
gdk_threads_enter ()
gdk_threads_leave ().
Those macros were used to lock the main gdk thread in earlier versions of
gtk if you wanted to call gtk_ functions from many threads. They are now
code (that I think is correct) do not leak in linux (ubuntu 12.04, gtk
2.24.10) nor on win32 (GTK 2.16) while it leaks about 12kbyte/sec with
GTK
2.24.10 on win32.
G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
--num-callers=32 src/your-binary
I had already tested
On 2 July 2012 15:44, Gabriele Greco gabriele.gr...@darts.it wrote:
I'm posting the code here before creating a bugzilla entry for it since I'm
not sure I can use g_idle_add to notify a new frame is available without
freeing the source, that works in linux and in older WIN32 versions and it
... on win32 with gtk 2.24.10 (20120208 bundle from gtk.org) the program
leaks about 10kb per sec, and as I said there is no leak also on win32 with
2.16.6 (20100207 bundle from gtk.org)
Filed bug 679312 https://bugzilla.gnome.org/show_bug.cgi?id=679312
--
Bye,
Gabry
Your code looks a bit strange, but I agree it should work with no
leaks. Probably a bug.
In the real code there are 1 to X (up to 12) GdkImage(s) that are semaphore
protected and filled by h264 decoders in different threads. Once the thread
fills his GdkImage with the frame data it uses
