Re: State of gdk-pixbuf
Hi Bastien, for what is worth here are the pathes that we need to apply downstream on windows: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdk-pixbuf2 Regards On Thu, Oct 23, 2014 at 4:31 AM, Bastien Nocera had...@hadess.net wrote: Hey, I've spent a couple of days triaging all the gdk-pixbuf bugs, wrangling patches, and testing what was testable. The bugs left over basically fall in a few categories: - Bugs or feature requests in the loaders. There's quite a few of them that could probably be handled in minutes, or maybe in a couple of hours if one doesn't know a particular format. It would be great to have an OPW or GSoC project based on those. - API additions. A few of those for animation features which we might or might not want to support, quite a few for async versions of existing functions, or variants of existing functions (stream-based loading). - GDI loader bugs - Pixops bugs (Argh [1]) - Handling of huge images - Cairo interaction support The last 3 are related in that GdkPixbuf is a format that doesn't lend itself to handling big images (especially black and white pictures would balloon in memory usage), and that its coverage for acceleration in manipulation and compositing is small (basically unaccelerated on anything but 32-bit x86 and Solaris). I think we need to start looking at a replacement for pixops, and a replacement for the GdkPixbuf format. I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) Cheers PS: Now is a good time to look at your pet feature, dig in a little, and get your patches reviewed. [1]: https://bugzilla.gnome.org/buglist.cgi?product=gdk-pixbufbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=pixops [2]: https://bugzilla.gnome.org/show_bug.cgi?id=491507#c13 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of gdk-pixbuf
On Thu, 2014-10-23 at 08:39 +0200, Ignacio Casal Quinteiro wrote: Hi Bastien, for what is worth here are the pathes that we need to apply downstream on windows: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gdk-pixbuf2 It would be great if you could review the patches that are already in bugzilla, and make sure that gdk-pixbuf upstream is usable for Windows. Cheers On Thu, Oct 23, 2014 at 4:31 AM, Bastien Nocera had...@hadess.net wrote: Hey, I've spent a couple of days triaging all the gdk-pixbuf bugs, wrangling patches, and testing what was testable. The bugs left over basically fall in a few categories: - Bugs or feature requests in the loaders. There's quite a few of them that could probably be handled in minutes, or maybe in a couple of hours if one doesn't know a particular format. It would be great to have an OPW or GSoC project based on those. - API additions. A few of those for animation features which we might or might not want to support, quite a few for async versions of existing functions, or variants of existing functions (stream-based loading). - GDI loader bugs - Pixops bugs (Argh [1]) - Handling of huge images - Cairo interaction support The last 3 are related in that GdkPixbuf is a format that doesn't lend itself to handling big images (especially black and white pictures would balloon in memory usage), and that its coverage for acceleration in manipulation and compositing is small (basically unaccelerated on anything but 32-bit x86 and Solaris). I think we need to start looking at a replacement for pixops, and a replacement for the GdkPixbuf format. I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) Cheers PS: Now is a good time to look at your pet feature, dig in a little, and get your patches reviewed. [1]: https://bugzilla.gnome.org/buglist.cgi?product=gdk-pixbufbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=pixops [2]: https://bugzilla.gnome.org/show_bug.cgi?id=491507#c13 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Ignacio Casal Quinteiro ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of gdk-pixbuf
On Wed, Oct 22, 2014 at 10:31 PM, Bastien Nocera had...@hadess.net wrote: Hey, I've spent a couple of days triaging all the gdk-pixbuf bugs, wrangling patches, and testing what was testable. Thanks for doing that! The last 3 are related in that GdkPixbuf is a format that doesn't lend itself to handling big images (especially black and white pictures would balloon in memory usage), and that its coverage for acceleration in manipulation and compositing is small (basically unaccelerated on anything but 32-bit x86 and Solaris). I think we need to start looking at a replacement for pixops, and a replacement for the GdkPixbuf format. I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) When I last talked to Soeren about it (several years ago), pixman didn't support the pixel format that gdk-pixbuf is using. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of gdk-pixbuf
hi; On 23 October 2014 11:55, Matthias Clasen matthias.cla...@gmail.com wrote: I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) When I last talked to Soeren about it (several years ago), pixman didn't support the pixel format that gdk-pixbuf is using. pixman supports RGBA (r8g8b8a8 and r8g8b8x8) since 2011, because it's used on big-endian architectures as well as being a requirement for OpenGL ES 2.0. this means that it should be possible to feed a GdkPixbuf pixel buffer to a pixman_image_t internally back and forth without copies, or, even better, to replace the GdkPixbuf internal storage and pixops with pixman_image_t and pixman operators. it should also be possible to create a tiled buffer composed by pixman_image_t tiles for large image data. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: State of gdk-pixbuf
On Thu, 2014-10-23 at 13:02 +0100, Emmanuele Bassi wrote: hi; On 23 October 2014 11:55, Matthias Clasen matthias.cla...@gmail.com wrote: I'm particularly interested to know what cairo, pixman and other image manipulation libraries can do for us. Benjamin surely has comments[2] :) When I last talked to Soeren about it (several years ago), pixman didn't support the pixel format that gdk-pixbuf is using. pixman supports RGBA (r8g8b8a8 and r8g8b8x8) since 2011, because it's used on big-endian architectures as well as being a requirement for OpenGL ES 2.0. this means that it should be possible to feed a GdkPixbuf pixel buffer to a pixman_image_t internally back and forth without copies, or, even better, to replace the GdkPixbuf internal storage and pixops with pixman_image_t and pixman operators. Indeed, that's one of the options we can take that wouldn't break ABI compatibility. it should also be possible to create a tiled buffer composed by pixman_image_t tiles for large image data. I have no idea what the API would look like for that. There's still the problem of handling huge files, especially the ones in grayscale or bw. The uncompressed in-memory usage would balloon compared to what it could use if we kept it in grayscale/bw [1]. Which gets us to the problem discussed in: https://bugzilla.gnome.org/show_bug.cgi?id=491507 We could start hiding the backing store and use cairo or pixman internally. gdk_pixbuf_get_pixels() would need to convert from whatever is the native format, to the GdkPixbuf format. Which would break applications expecting it to change the backing storage (say, adding borders to pixbufs). I'd probably do that with a slight ABI break, adding API to change the internal representation to the GdkPixbuf native format. Applications that used to call _get_pixels() could be ported with a one-liner. Applications that want to be able to handle bigger images can then do their modifications at the drawing stage. In any case, short-term, fixing all the pixops buglets by using pixman would be a great step forward, and would lower our maintenance burden (not that pixops bugs saw much more than inhaling through clenched teeth and words of kind-of-encouragement). Cheers [1]: https://bugzilla.gnome.org/show_bug.cgi?id=666391 and all the dupes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
