Re: librsvg api
Kalle Vahlman schrieb: > 2009/4/17 Stefan Kost : > >> hi, >> >> I am using librsvg to get pixbufs for my app. I could not find a dedicated >> list, >> for it, hope this one is okay. >> >> First I am using deprecated api: >> rsvg_pixbuf_from_file_at_size >> as when using >> rsvg_handle_get_pixbuf >> I can specify the size it should be rendered (tried rsvg_handle_set_dpi and >> rsvg_handle_set_dpi_x_y). Any idea here? >> >> I would like to use not deprecated rsvg_handle_ API, as I need to resize the >> images and I'd like to keep the svg loaded. Just set new size and rerender. >> > > To do that, you'll need to render to a cairo surface with approperiate > scaling and convert that to pixbuf. You can get the "natural" pixel > size of the SVG with rsvg_handle_get_dimensions() to calculate the > scaling factor. > I was wondering if there is a direct way, as with the deprecated api there was. But thanks for your suggestions. Stefan > The conversion can be done by either rendering to a GdkDrawable (ie. > pixmap) and then using gdk_pixbuf_get_from_drawable() or using an > image surface and then converting the image data to the format used by > GdkPixbuf. GOffice has an example implementation of that conversion: > > http://git.gnome.org/cgit/goffice/tree/goffice/utils/go-cairo.c#n305 > > Personally I'd prefer the latter in the current X.Org driver > landscape; drawing a complex SVG (specially with gradients) can > seriously suck if the server needs to do lots of fallbacks to software > rendering... > > >> Besides some more dom exposure would be sweet. >> > > Indeed! > > >> Not sure if anyone is actually even working on the lib still (which would be >> sad). >> > > It seriously lacks some loving, that's for sure. > > ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: librsvg api
2009/4/17 Stefan Kost : > hi, > > I am using librsvg to get pixbufs for my app. I could not find a dedicated > list, > for it, hope this one is okay. > > First I am using deprecated api: > rsvg_pixbuf_from_file_at_size > as when using > rsvg_handle_get_pixbuf > I can specify the size it should be rendered (tried rsvg_handle_set_dpi and > rsvg_handle_set_dpi_x_y). Any idea here? > > I would like to use not deprecated rsvg_handle_ API, as I need to resize the > images and I'd like to keep the svg loaded. Just set new size and rerender. To do that, you'll need to render to a cairo surface with approperiate scaling and convert that to pixbuf. You can get the "natural" pixel size of the SVG with rsvg_handle_get_dimensions() to calculate the scaling factor. The conversion can be done by either rendering to a GdkDrawable (ie. pixmap) and then using gdk_pixbuf_get_from_drawable() or using an image surface and then converting the image data to the format used by GdkPixbuf. GOffice has an example implementation of that conversion: http://git.gnome.org/cgit/goffice/tree/goffice/utils/go-cairo.c#n305 Personally I'd prefer the latter in the current X.Org driver landscape; drawing a complex SVG (specially with gradients) can seriously suck if the server needs to do lots of fallbacks to software rendering... > Besides some more dom exposure would be sweet. Indeed! > Not sure if anyone is actually even working on the lib still (which would be > sad). It seriously lacks some loving, that's for sure. -- Kalle Vahlman, z...@iki.fi Powered by http://movial.com Interesting stuff at http://sandbox.movial.com See also http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
librsvg api
hi, I am using librsvg to get pixbufs for my app. I could not find a dedicated list, for it, hope this one is okay. First I am using deprecated api: rsvg_pixbuf_from_file_at_size as when using rsvg_handle_get_pixbuf I can specify the size it should be rendered (tried rsvg_handle_set_dpi and rsvg_handle_set_dpi_x_y). Any idea here? I would like to use not deprecated rsvg_handle_ API, as I need to resize the images and I'd like to keep the svg loaded. Just set new size and rerender. Besides some more dom exposure would be sweet. E.g. querying the position and extends of named elements and hiding/showing named elements. This way I could easily do variants in inkscape and render the variants in the app. Now I need dozen files. There is rsvg_handle_get_pixbuf_sub(), but thats not enough. I would rather need rsvg_handle_get_pixbuf_get_subs(handle, id1 , ...) where it makes all given layers visible. Not sure if anyone is actually even working on the lib still (which would be sad). Thanks in advance, Stefan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential need for librsvg API breakage
Ah, so that's why all the plug-ins in encompass are going whacky now. I spent a damn long time trying to debug why the hell it was giving me "already registered" errors. I even wrote a simplified module loading test case, but that of course had no problems. Of course, encompass is still having the problem. My current suspicion is that the use of bonobo in encompass is causing it to break for some reason. It seemed to work OK when I short-circuited all the bonobo server startup bits. And I agree. This API breakage sucks. -- dobey On Wed, 2006-11-01 at 15:02 -0500, Dominic Lachowicz wrote: > Hi, > > So I'm currently faced with a dilemma that's hitting a lot of users, > causing their applications to crash and otherwise behave badly. I'd > appreciate if people might offer any insight they had on the issue. > > In the 2.16.x series, librsvg's fundamental "type", the RsvgHandle, > became a subclass of GObject, and is registered via > g_type_register_static(). AFAIK, this relationship isn't exposed in > any way that the public ABI is concerned (i.e. RsvgHandle is just a > anonymous typedef in the header file). > > The problem is that librsvg is a library that gets used by a lot of > plugins - I can think of at least 3 places: AbiWord's image loader, > GdkPixbuf's "loader" architecture, and GTK+'s theme engine. Some of > these (GTK+'s theme engine bits come to mind) make heavy use of what > GObject calls "dynamic types" that get loaded/unloaded as necessary, > and the GModule that ultimately called > g_type_register_static(RSVG_TYPE_HANDLE, ...) may get unloaded. Since > there is no way to signal that types need to be unregistered, this > causes subsequent registration of the RsvgHandle type to fail, and > lots of code to go belly-up. This is bad. > > Now, I don't intend to pass judgment on the type registration system. > I just want to come up with the best way to fix the problem I'm > encountering. I can think of a few solutions, but I welcome other > ideas and suggestions for implementing my proposals. > > 1) Make helper-processes that do the heavy lifting. Have the plugins > call those processes via a wire protocol (see also: The Gimp). The > helper-process calls type registration. Problem goes away. > Pros: No API breakage > Cons: A decent amount of work. Performance penalties in at least 2 > places (pixbuf loading, theme engine) where performance actually > matters. > > 2) Break API. Involves changing documentation, removing type > registration, etc. Probably need to tweak libtool bits to suggest > interface breakage. > Pros: No performance hit > Cons: The obvious. Plus, Rsvg makes use of other GObject-based > libraries (libgsf, gnome-vfs) that may still in-turn exhibit problems. > > 3) Whatever you all come up with > > Thanks for your help and understanding, > Dom ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential need for librsvg API breakage
Hi Tim, > this is already broken and has to be fixed. > if you want to be able to unload a type implementaiton, you MUST > use g_type_register_dynamic. > using g_type_register_static and unloading its implementaiton is as > good as dlopen(); atexit(dlsym()); dlclose(); > the alternative is of course to make the module effectively unloadable > by means of g_module_make_resident or dlopen(self) once loaded. It's not something that I'm in control of, which is the problem. The problem is that a plugin (be it GdkPixbuf or some 3rd-party plugin that I'm not aware of) will call rsvg_handle_new() directly or indirectly, which looks innocuous enough. But behind that, there is a call to g_type_register_static(), which becomes problematic. Now, this is a caveat to be aware of when using GObject that should be advertised in big bold neon blinking text, and I found this out the hard way. Mea culpa. However, I don't see how I can keep RsvgHandle as a GObject subclass while retaining the ability to use librsvg in various plugins that might get unloaded. Thus my question about breaking API to revert the use of GObject, and asking if there is a better alternative, because I'm not seeing one. > i'm not sure what exactly your problem is here. > if it's just the combo of g_type_register_static + unloading, > simply prevent unloading or use g_type_register_dynamic. > if it's something else, i didn't manage to grasp it from your email ;) I don't control the loading/unloading of these modules, nor do I wish to. I also don't necessarily have a GTypeModule* to pass to a GType registration function, nor do I wish to muddy librsvg's public API to accommodate what is (in my mind) a hackish workaround. Best, Dom -- "I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex." -Jack Handy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential need for librsvg API breakage
On Wed, 1 Nov 2006, Dominic Lachowicz wrote: > Hi, > > So I'm currently faced with a dilemma that's hitting a lot of users, > causing their applications to crash and otherwise behave badly. I'd > appreciate if people might offer any insight they had on the issue. > > In the 2.16.x series, librsvg's fundamental "type", the RsvgHandle, > became a subclass of GObject, and is registered via > g_type_register_static(). AFAIK, this relationship isn't exposed in > any way that the public ABI is concerned (i.e. RsvgHandle is just a > anonymous typedef in the header file). > > The problem is that librsvg is a library that gets used by a lot of > plugins - I can think of at least 3 places: AbiWord's image loader, > GdkPixbuf's "loader" architecture, and GTK+'s theme engine. Some of > these (GTK+'s theme engine bits come to mind) make heavy use of what > GObject calls "dynamic types" that get loaded/unloaded as necessary, > and the GModule that ultimately called > g_type_register_static(RSVG_TYPE_HANDLE, ...) may get unloaded. this is already broken and has to be fixed. if you want to be able to unload a type implementaiton, you MUST use g_type_register_dynamic. using g_type_register_static and unloading its implementaiton is as good as dlopen(); atexit(dlsym()); dlclose(); the alternative is of course to make the module effectively unloadable by means of g_module_make_resident or dlopen(self) once loaded. > Since > there is no way to signal that types need to be unregistered, this > causes subsequent registration of the RsvgHandle type to fail, and > lots of code to go belly-up. This is bad. > > Now, I don't intend to pass judgment on the type registration system. > I just want to come up with the best way to fix the problem I'm > encountering. I can think of a few solutions, but I welcome other > ideas and suggestions for implementing my proposals. > 3) Whatever you all come up with i'm not sure what exactly your problem is here. if it's just the combo of g_type_register_static + unloading, simply prevent unloading or use g_type_register_dynamic. if it's something else, i didn't manage to grasp it from your email ;) > Thanks for your help and understanding, > Dom --- ciaoTJ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Potential need for librsvg API breakage
Hi, So I'm currently faced with a dilemma that's hitting a lot of users, causing their applications to crash and otherwise behave badly. I'd appreciate if people might offer any insight they had on the issue. In the 2.16.x series, librsvg's fundamental "type", the RsvgHandle, became a subclass of GObject, and is registered via g_type_register_static(). AFAIK, this relationship isn't exposed in any way that the public ABI is concerned (i.e. RsvgHandle is just a anonymous typedef in the header file). The problem is that librsvg is a library that gets used by a lot of plugins - I can think of at least 3 places: AbiWord's image loader, GdkPixbuf's "loader" architecture, and GTK+'s theme engine. Some of these (GTK+'s theme engine bits come to mind) make heavy use of what GObject calls "dynamic types" that get loaded/unloaded as necessary, and the GModule that ultimately called g_type_register_static(RSVG_TYPE_HANDLE, ...) may get unloaded. Since there is no way to signal that types need to be unregistered, this causes subsequent registration of the RsvgHandle type to fail, and lots of code to go belly-up. This is bad. Now, I don't intend to pass judgment on the type registration system. I just want to come up with the best way to fix the problem I'm encountering. I can think of a few solutions, but I welcome other ideas and suggestions for implementing my proposals. 1) Make helper-processes that do the heavy lifting. Have the plugins call those processes via a wire protocol (see also: The Gimp). The helper-process calls type registration. Problem goes away. Pros: No API breakage Cons: A decent amount of work. Performance penalties in at least 2 places (pixbuf loading, theme engine) where performance actually matters. 2) Break API. Involves changing documentation, removing type registration, etc. Probably need to tweak libtool bits to suggest interface breakage. Pros: No performance hit Cons: The obvious. Plus, Rsvg makes use of other GObject-based libraries (libgsf, gnome-vfs) that may still in-turn exhibit problems. 3) Whatever you all come up with Thanks for your help and understanding, Dom -- "I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex." -Jack Handy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
