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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
