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

Reply via email to