Re: An alternative to gdk-pixbuf

[Bastien Nocera <hadess hadess net>]

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
> > > > viewing.  
> > >
> > > This is debatable. If I'm viewing a 4000x4000 RGB image on a
> > > hidpi
> > > display I'm already pushing gdk-pixbuf and cairo to their limits
> > > because of the scaling factor applied to the window — not only
> > > the
> > > buffer gets loaded uncompressed to allow for zooming, but the
> > > image
> > > 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;
> > > but
> > > 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
> > really
> > fixable:
> > https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30
> >
> > Viewers should use GEGL, and GEGL should be taught about more
> > formats.
> > 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
> large
> 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
> bytes
> 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).

<snip>
> > >  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
> > > still
> > > use it. Moving pixbuf loaders to separate processes, and wrap
> > > them
> > > 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
> > API
> > 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
> > test
> > suite.
>
> 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.

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