Re: An alternative to gdk-pixbuf
- From: Federico Mena Quintero <federico gnome org>
- To: Emmanuele Bassi <ebassi gmail com>, magnus bergman snisurset net
- Cc: GTK Devel List <gtk-devel-list gnome org>
- Subject: Re: An alternative to gdk-pixbuf
- Date: Thu, 06 Sep 2018 13:03:03 -0500
On Wed, 2018-09-05 at 17:28 +0100, Emmanuele Bassi via gtk-devel-list
wrote:
In the near future, I'll very likely deprecate most of GdkPixbuf's
API, except for the I/O operations; I'd also be happy to seal off
most of its internals, within the ABI stability promise, to avoid
leakage of internal state.
Related to this - I just wrote a braindump on gdk-pixbuf issues and
historical baggage. I hope it's useful for people trying to clean up
this swamp:
https://people.gnome.org/~federico/blog/my-gdk-pixbuf-braindump.html
Magnus - thanks for showing us Abydos. The parts of the API that
intersect with gdk-pixbuf's look okay. I think you may find this
useful:
https://developer.gnome.org/programming-guidelines/stable/index.html.en
I think your API could improve with some of the material there around
memory management and error reporting. Internally, the code needs
checks in all the malloc()-like functions; some of the arithmetic
(especially in assertions) needs to avoid overflows. I couldn't find
any tests. The SVG plug-in needs to handle error results from librsvg.
The Magick plug-in for PNG and JPEG has no error handling; also you may
want to call cairo_surface_mark_dirty() when you are done writing
pixels to it. The netpbm plugin does a bunch of system calls and
doesn't check for errors.
The parts of your API that deal with pagination / variants / animation
frames - I'm not sure if a gdk-pixbuf replacement would need them, but
I'm coming from the viewpoint of my braindump above.
Federico
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]