Re: problem about the array module.
On Sat, Jul 5, 2014 at 11:47 AM, lintong724 13759972...@163.com wrote: Hey Guys: can anyone tell me why we should neew GArray ? what if we directly use GRealArray? GRealArray is an implementation detail of glib, it's not exposed in the headers (so you cannot use it unless you redefine it yourself), and it's subject to change at any time, so your application would break badly. Also, there are no interesting fields in GRealArray. Giovanni ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Memory tracking in GJS
2014-02-20 2:50 GMT+01:00 Cosimo Cecchi cosi...@gnome.org: Hi all, The state of garbage collection for typical GTK/JS applications is pretty sad these days. mozjs will execute a garbage collection run when it thinks around 30MB of allocations have been done. It's worth pointing out that mozjs will *force* a garbage collect if you go over the malloc limit (a dynamic value between 30 and 90 MB), but will garbage collect a lot more often if you call MaybeGC. Firefox does that at the end of the every user script (with a comment saying it's for sunspider), maybe we can do the same in gjs? Additionally, gjs does not support the more advanced forms of GC, so they trigger less often and block longer. See #724797 for incremental GC for example. Any other ideas? I feel this is a fundamental enough issue that there must be a good way to design a generic solution. We can probably look into mallinfo() as well, it offers a reasonable estimate of the memory usage for a single threaded application (because most allocations happen from the main arena). Giovanni ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sharing CSS code between Gtk and the Shell
Hello Gtk and hello Shell developers, In https://bugzilla.gnome.org/show_bug.cgi?id=687881 I promised I'd try to address one of the big performance problems in the current gnome-shell, which is the St theming system. Currently St does an awful lot of string matching again and again, as neither the style classes and element names, nor the property names are interned or preprocessed. We rely on libcroco to do basic tokenization, but that's it, everything else happens every time a StThemeNode (~ GtkStyleContext) is computed. We introduced some caching at the beginning of the 3.7 cycle, but to me that's just papering over a bad implementation. So I started to rewrite it. I streamlined selector matching, added quarking to classes, tried to normalize css values at parsing time and finally built a map of known CSS properties to StThemeNode fields. But I don't have a selector tree, I don't have GtkBitmask optimizations, I had to reimplement GtkCssValue, etc. The patch is not complete (it's missing background properties), but I'm thinking: why should I write this again? Someone else did this in Gtk, can't we just use that? And this prompted me to this mail: is there a way for gnome-shell to reuse Gtk CSS implementation? Ideally, we would just use GtkStyleContext outside GtkWidget, and parts of Gtk's docs claim it is supported. But I'm curious on what assumptions are made from GtkWidgetPath, and if those assumptions can be worked around or lifted. Additionally, there are a number of accessors that are not exposed by GtkStyleContext or GtkThemingEngine, but are available only to Gtk internals. Consider that we can't use gtk_render_*, since we use Cogl for painting, not cairo. The next issue with that straightforward approach is that St's theming is slightly more powerul than Gtk's. Looking at the gtk docs, I see Gtk has no support for box-shadow, icon-shadow (st extension), background-position, background-size, outline, text-decoration, text-align, as well as width, min-width and max-width. If we were to use Gtk directly, we would need to move our implementation into Gtk, or work around that limitation. Also, I saw that Gtk has recently deprecated extension CSS properties. We use a number of those in gnome-shell, and it's not always possible to replace them with standard CSS2, although I guess it'd be possible to use gtk_style_context_save() / add_class() / restore() like Gtk themes do. The second option is to share just code, in some form, either as a private shared library that would be provided by Gtk (libgtk-internal?) and developed by both teams, or just as a copy-lib, with a massive s/Gtk/St/. I'm not sure what would be the cost of this last possibility, but I'm still convinced it would be lower than rewriting from scratch, and maintaining two different CSS implementations in GNOME. Looking forward to your comments, Giovanni ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Problems with un-owned objects passed to closures in pygobject (gtk_cell_renderer_text_start_editing)
2013/1/17 Simon Feltman s.felt...@gmail.com: Hi Everyone, I'm trying to figure out a complete solution for proper reference management of gobjects passed into python vfuncs and signal closures as in arguments. Currently pygobject will add a ref to gobject arguments marked as transfer-none during marshaling and additionally sink/ref the gobject when the python object wrapper is created around it. The initial added ref during marshaling is then leaked upon the closure finishing in most cases. The fix could simply be to not add the initial ref during marshaling (or we need to make sure it is released when the closure finishes). The problem is this behavior is relied upon when a floating ref is passed and is the explicit fix described in the following ticket (which un-fortunately causes a leak in the non-floating case): https://bugzilla.gnome.org/show_bug.cgi?id=661359 The specific problem described in bug 661359 occurs when a python closure is connected to a GtkCellRendererTexts editing-started signal. During the start of editing, a GtkEntry is created and passed almost immediately to signal emission before any ownership takes place: http://git.gnome.org/browse/gtk+/tree/gtk/gtkcellrenderer.c#n864 This results in the following ref counting behavior of the GtkEntry as it is used by gtk_cell_area_activate_cell and gtk_cell_renderer_start_editing: 1 (floating) - gtk_cell_renderer_text_start_editing creates the GtkEntry 2 (floating) - g_signal_emit argument marshaling adds an additional ref during signal emission 3 (floating) - python closure marshaling adds an additional ref described above 3 (owned) - A PyGObject wraps the GtkEntry and sinks the floating ref * python callback is called and passed the wrapper 2 (owned) - The PyGObject wrapper is destroyed after the python callback finishes additionally freeing a gobject ref 1 (owned) - g_signal_emit argument marshaling completes and frees the ref it added 2 (owned) - gtk_cell_area_activate_cell sets the CellAreas edit widget which adds a ref 1 (owned) - cell editing finishes and removes the widget from the CellArea I don't know the internals of pygobject, but to me it looks the leak comes from not releasing the reference you add inside the callback marshaller. The way it works in gjs is: 1 (floating) - gtk_cell_renderer_text_start_editing creates the GtkEntry 2 (floating) - g_signal_emit argument marshaling adds an additional ref during signal emission 2 (owned) - gjs closure marshaling creates a JS object wrapper, calling ref_sink on the object 2 (owned, toggle, GC root) gjs adds a toggle reference and then immediately unrefs the object 1 (owned, toggle, not rooted) - g_signal_emit argument marshaling completes and frees the ref it added 2 (owned, toggle, GC root) - gtk_cell_area_activate_cell sets the CellAreas edit widget which adds a ref 1 (owned, toggle, not rooted) - cell editing finishes and removes the widget from the CellArea ... time passes ... 0 - GC triggers and the JS object finalizer removes the last ref I know that Python doesn't have a GC in the traditional sense, but you could still send finalization for GObject wrappers to a idle callback so there is no risk of finalizing objects that C code assumes are still alive. Giovanni ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [GObjectIntrospection] Cleaning up GIRepository
Il giorno lun, 23/08/2010 alle 09.10 -0300, Johan Dahlin ha scritto: [not on gtk-devel, so CC me replies] On Fri, 20 Aug 2010 01:59:09 Giovanni Campagna scampa giovanni gmail com wrote: First of all, sorry if this is not the correct mailing list but I did not find a more suited one (and Glib discussion happens here anyway). I started looking for GObjectIntrospection API recently and I've seen a lot of overlap with the original GObject/GType system. In particular, I would like to ask why the following were reimplemented (using the typelib and not run time type information): There are three primary reasons for not doing things within the GType system. A) GLib was up until last year moving very slowly, it seems that multiple year processes were the norm for even the smallest functional additions. B) the GIRepsitory API reflects the internals of a binary typelib which will be loaded from disk via mmap. It's intended to be used by multiple processes within a gnome desktop and needs to use as little writable memory as possible. I'm not sure how many bytes that needs to be allocated for a GObject, but it's in the multiple 100 byte range, while creating a GIBaseInfo only requires 44 bytes on 32-bit systems. Well, if so much memory is required for a GObject, then making GObject more lightweight (possibly without signals and properties) would make sense. Secondly, little is gained by sharing the typelib, if the information is *also* contained in a different private writable memory area. C) in many cases we want to avoid using the GType because it is not registered at that point. Registering the GType means that we have to recursively register the type and all its parents. Writing a lazy binding for dynamic languages like python and javascript means that the type registration should only be done when needed, eg such as when the class wrapper is accessed - usually when the first instance of specific class is created. And why you would ever need information about a class which is not used and/or available to use? 1) g_object_info_get_abstract, g_object_info_get_fundamental: equivalent informations may be queried from G_TYPE_GET_ABSTRACT, G_TYPE_GET_FUNDAMENTAL See B) 2) g_object_info_get_interfaces: exists as g_type_get_interfaces + gi_repository_get_from_gtype See C) 3) g_object_info_get_properties: transfer could be placed as a GParamFlag and array fixed size / array null terminated could be added as part of a new g_param_spec_array() (I am not sure about the latter, are there properties which are GArray / GPtrArray / C arrays?) then is just a matter of g_object_class_list_properties GObjectInfo needs to know about properties and signals which are also available in the glib type system because annotations might override them. For instance, we want to include array/transfer/direction metadata which is only available in the typelib. Direction doesn't make sense for properties and I proposed how to encode array and transfer in GParamFlag. Currently both gjs/pygobject uses the gtype system for both signals and properties, but they need to be ported over to use gobject-introspection information. 6) g_object_info_get_unref_function co. I see this is to support dynamic GstMiniObject bindings, this is the part I understand the least, as it definitely belongs in the type system implementation, not type reflection / introspection system. I believe bindings, either static or dynamic, should use the facilities from GValue and GValueTypeTables. This means that objects retrieved from the C API are placed inside a GValue with g_value_set_instance. Such objects are copied around as GValue, which take care of reffing and unreffing. The original instance pointer is retrieved for passing to C API functions with g_value_peek_pointer. Registering an unref/ref method requires glib extensions as far as I understand. No, the (un)ref method is exposed in the GTypeValueTable. The value transformation routines were added since the dynamic bindings for objects such as GstMiniObject use gst_mini_object_set/get_value They should be able to use g_value_set_instance / g_value_peek_pointer, keeping gst_mini_object_*_value for C convenience. (By the way, not only GstMiniObject and GObject are GTypeInstance, also GParamSpec is, so this writing binding this way could facilitate memory management) GParamSpec is not instantiable, g-i only support GTypeInstances with the instantiable flag set. In practice, only GstMiniObject is tested/supported. Ok 7) Union, structs, instances all have fields and method. Also, instances and interfaces have vfuncs. Finally, GObject / GInterface (with a GObject prerequisite) have properties and signals. Why each of them has its own method (pun not intended) for introspecting them? (as a side note: Vala has methods for enums) This is because the way
[GObjectIntrospection] Cleaning up GIRepository
First of all, sorry if this is not the correct mailing list but I did not find a more suited one (and Glib discussion happens here anyway). I started looking for GObjectIntrospection API recently and I've seen a lot of overlap with the original GObject/GType system. In particular, I would like to ask why the following were reimplemented (using the typelib and not run time type information): 1) g_object_info_get_abstract, g_object_info_get_fundamental: equivalent informations may be queried from G_TYPE_GET_ABSTRACT, G_TYPE_GET_FUNDAMENTAL 2) g_object_info_get_interfaces: exists as g_type_get_interfaces + gi_repository_get_from_gtype 3) g_object_info_get_properties: transfer could be placed as a GParamFlag and array fixed size / array null terminated could be added as part of a new g_param_spec_array() (I am not sure about the latter, are there properties which are GArray / GPtrArray / C arrays?) then is just a matter of g_object_class_list_properties 6) g_object_info_get_unref_function co. I see this is to support dynamic GstMiniObject bindings, this is the part I understand the least, as it definitely belongs in the type system implementation, not type reflection / introspection system. I believe bindings, either static or dynamic, should use the facilities from GValue and GValueTypeTables. This means that objects retrieved from the C API are placed inside a GValue with g_value_set_instance. Such objects are copied around as GValue, which take care of reffing and unreffing. The original instance pointer is retrieved for passing to C API functions with g_value_peek_pointer. (By the way, not only GstMiniObject and GObject are GTypeInstance, also GParamSpec is, so this writing binding this way could facilitate memory management) 7) Union, structs, instances all have fields and method. Also, instances and interfaces have vfuncs. Finally, GObject / GInterface (with a GObject prerequisite) have properties and signals. Why each of them has its own method (pun not intended) for introspecting them? (as a side note: Vala has methods for enums) 8) On the other hand, all GTypeInstance get a GIObjectInfo, but only GObject has properties and signals. Would it be more appropriate to move GObject specific code down the hierarchy? Last comment: why none of this API uses GObject and is not even a registered boxed? Thanks for your time, Giovanni Campagna ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
