Re: An alternative to gdk-pixbuf

On Sun, 2018-09-09 at 01:23 +0200, Magnus Bergman wrote:
On Fri, 07 Sep 2018 12:51:32 +0200
Bastien Nocera <hadess hadess net> wrote:

Gegl is great for image editing. But not as much for simple

This is debatable. If I'm viewing a 4000x4000 RGB image on a
display I'm already pushing gdk-pixbuf and cairo to their limits
because of the scaling factor applied to the window — not only
buffer gets loaded uncompressed to allow for zooming, but the
viewer needs to render a CPU-scaled down copy of the image.

Sure, for viewing a 500x400px image macro for a meme we're fine;
we're fine with gdk-pixbuf as well, so there's really no need to
change to a different image loading library.  

I concur, 4000x4000 would likely OOM your machine, and it's not

Viewers should use GEGL, and GEGL should be taught about more
That still leaves many GIF files unhandled though, and I'm not sure
we'd want apps writing their own GIF loader, seeing how complicated
that is.

How do you mean it's not fixable? Of course it's not fixable that
processing larger amounts of data will require more processing power.
So I think it's kind of obvious that creating thumbnails for many
images will take it's time. But that shouldn't need be too much of a
problem. Without looking too deeply into it, it looks like a problem
with nautilus to me. Obviously it's a bad idea to to run the
thumbnailers synchronously (which I can't imagine Nautilus does), and
it's also bad to run too many memory hungry tasks in parallel. But
that must be fixable, right? Like limiting the the total size in
of files being allowed to be processed in parallel, for example.

It's not fixable without breaking the API and ABI of gdk-pixbuf. And
nautilus doesn't thumbnail images itself (there's a thumbnailer that
gets sandboxed by the thumbnailing code), or do it synchronously (the
thumbnailers are out-of-process).

 The animation API is pretty much a garbage fire, so it may go on
the chopping block as well. Of course, deprecated API will keep
working as well—or as badly—as it works today, so people can
use it. Moving pixbuf loaders to separate processes, and wrap
in sandboxes, would be a fairly good thing to do; it need to be
decided at run time, though, because there are many users of
GdkPixbuf that already run in a sandbox, which prevents creating
smaller sandboxes inside it.  

That'd be best left to an API that can do that natively, with the
being thought out ahead of time.

In the short term, my wishlist/TODO list would be:
- somebody writes a GIF loader that is readable, and passes the

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
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.

- we disable every loader by default except the ones that the core
desktop needs
- image viewers that rely on gdk-pixbuf ship their additional
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]