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 g_idle_add() to signal the GUI thread that the associated GdkDrawingArea has to be redraw, the idle function simply queue the draw of the widget and the expose event locks the gdkimage and do the real drawing.
This works quite smoothly (25fps) with twelve 352x288 video inputs on any dual core PC . I pulled out all the threaded logic and made an example as simple as possible to trigger the problem, actually I could also remove the drawing itself, but it was useful to see that the program was not hung :) -- Bye, Gabry _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
