Re: An alternative to gdk-pixbuf
- From: Magnus Bergman <magnus bergman snisurset net>
- To: Bastien Nocera <hadess hadess net>
- Cc: Emmanuele Bassi <ebassi gmail com>, GTK Devel List <gtk-devel-list gnome org>
- Subject: Re: An alternative to gdk-pixbuf
- Date: Mon, 10 Sep 2018 22:29:32 +0200
On Mon, 10 Sep 2018 11:31:42 +0200
Bastien Nocera <hadess hadess net> wrote:
I've written loader for GIF that simply wraps abydos. In lines of
code it's about a quarter the size of the current loader, even
including
the GIF plugin for abydos. It might even be slightly smaller with
the whole of abydos included in the equation. On the downside it
probably doesn't pass the test suite since I haven't tried it. But
I will, and hopefully publish the whole thing in a couple of days.
That's unfortunately not mergeable, and unless you use a library for
your GIF plugin in abydos, would just be shifting the potential bugs
to the abydos code base.
I do use a library (or two). I've written one plugin that uses giflib
and one that uses ImageMagick. I assumed using giflib would be a
straighter path, but it wasn't. Firstly it only supports reading images
from disk (but abydos automatically creates temporary files then needed
so that didn't add any extra code at least). Secondly it doesn't do
much more than unpacking the pixels. How to interpret what comes out is
left as an exercise for the user, and requires a bit of knowledge about
the GIF formats and it's quirks. So that plugin isn't built by default.
ImageMagick on the other hand did much more to be of help, and required
far less code to use. So shifting the responsibility to ImageMagick
seems reasonable, I think.
I tested them both on all the GIF images included in the gdk-pixbuf
test suit. Both plugins mostly work, but to varying degree. The one
based on giflib segfaults with 1_partyanimsm2.gif (because the
allocation containing the pixels which giflib provides is less than the
images width x height, I haven't yet looked deeper into it). The
ImageMagick based plugin on the other doesn't crash at least, and all
the invalid images are correctly classified as invalid. The image
1_partyanimsm2.gif still shows as garbage except the first frame. The
image aero.gif has the frame delay set to zero for every frame but the
first. I'm not sure how that should be interpreted, so I simply
exchanged zero values for a small delay (0.02 seconds). I will read up
on the GIF format and hopefully get things working better.
It's available here if you want to try it out:
http://snisurset.net/code/abydos/
- we disable every loader by default except the ones that the core
desktop needs
- image viewers that rely on gdk-pixbuf ship their additional
loaders
in the app's Flatpak[1].
I don't care much for Flatpak in particular. But generalised and
rephrased as, leave it to the distributors to decide, I agree that
this is absolutely the best approach.
Without Flatpak, you're just removing image format support from image
viewers, as many packaging guidelines in distributions forbid the
bundling of libraries. They'd want to ship a single copy of the gdk-
pixbuf loaders, and the applications wouldn't have any protection from
files that the loaders would trip over.
I'm not arguing against that. I just think it's an issue best left
entirely to distributors (including the choice between bundling and
dependencies).
How and where to implement sandboxing is an interesting question still.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]