2015-10-15 23:02 GMT+08:00 Christian Hergert <christ...@hergert.me>: > On 10/15/2015 07:19 AM, cee1 wrote: >>> From GStreamer point of view, the main problem as it was explained to >>> > me, is the global locks, creating contention (GStreamer is highly multi >>> > -threaded). It's also a base type reserved for very specific use cases >>> > (where a lot of that type need to be allocated, GstBuffer, GstEvent, >>> > etc.). I'm not sure it make much sense generically. Specially that you >>> > loose most of the feature of an object, properties, interface, signal, >>> > etc. >> >> Such mini objects may also play a role in GTK+, I guess... > > Almost certainly not. Gtk uses properties and signals heavily, and is > dominated by single threaded operations. Basically the complete opposite > of why GstMiniObject was created.
GstMiniObject is discussed because the COW feature (aka. gst_mini_object_make_writable). So the question is will GTK+ benefit from the COW feature? If yes, we may let GObject inherit from GstMiniObject to obtain the COW feature? -- Regards, - cee1 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
