Re: GnomeDesktopThumbnail API replacement

[Bastien Nocera <hadess hadess net>]

On Tue, 2018-01-30 at 11:06 +0000, Debarshi Ray wrote:
> Hey,
>
> On Tue, Jan 30, 2018 at 10:46:30AM +0100, Bastien Nocera wrote:
> > On Mon, 2018-01-29 at 15:42 +0000, Debarshi Ray wrote:
> > > However, the edits are application-specific [2], so it is not
> > > reasonable to expect the generic OS-wide thumbnailers to be able
> > > to
> > > handle them.
> >
> > This is solved/worked-around when using Flatpak, as the cache is
> > private to the app.
>
> Yes, that's right. Although, the non-Flatpak case would probably
> linger on for a while?
>
> Also, it's not primarily about the location of the cache but the
> thumbnailer. To me, the real value in using the generic thumbnailers
> is not having to worry about all kinds of weird MIME type problems,
> sketchy files, and the various problems that arise from those things.

What files are you interested in thumbnailing that your application
doesn't support?

> One could imagine asking the generic thumbnailer to thumbnail the
> original file, and then have the application run the edits on top of
> it. However, that won't work if the image was cropped because you'd
> have to crop the original thumbnail and then proceed, which will
> affect the resolution of the final thumbnail. If I am not mistaken, I
> coded Photos' thumbnailer to load the image at a lower resolution if
> it wasn't cropped, else it loads at full scale and downscales later.

At this point, you could very well apply the edits and thumbnail
internally, as the app would know which one of the photos have edits
attached to them.

> I edited this bit from the blog because it was already getting too
> long. :)
>
> > > Secondly, it is important to be able to create and lookup
> > > thumbnails
> > > of a specific size, as opposed to enumerated constants with pre-
> > > determined presets.
> >
> > This is a problem with the thumbnail spec's storage section. Jon
> > added
> > a larger version quite some time ago, and somebody would need to go
> > through the process to make it any bigger.
>
> I see, ok. By larger version, you mean one for 512x512 icons?
>
> I haven't had the occasion to see what a N > 2 display looks like.  I
> can imagine that upscaling 512x512 raw pixels to cover 256x256
> logical
> pixels might be passable. It'd still be better than LoPPI, but not
> better than N=2 HiPPI. I don't know.

Seems to be 256x256:
https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#THUMBSIZE

Unfortunately, we (GTK+/GNOME) don't control the thumbnail spec. As
mentioned, any additions would need to go through discussions on xdg-
list.

> > > Last but not the least, I find it important to version the cache
> > > to
> > > tide over bugs in the thumbnailer.
> >
> > You don't need the whole cache to be versioned. Thumbnailers can
> > add
> > metadata to the thumbnails if they want, and doing:
> > gdk_pixbuf_save(pixbuf, "/path/to/thumbnail", "png", &error,
> >                 "tEXt::Thumb::Software::Version", "1.0", NULL);
> > is do-able from within the thumbnailer, and that extra metadata
> > would
> > be kept.
>
> Yes, that's right. It will be good if the generic thumbnailers would
> version their output like that. Maybe it should be added to the
> standard?

I'll add a "FORCE" flag to the API. As you'd control both the
thumbnailer and how it's called, you could do thumbnail the file, and
if the version in the GdkPixbuf is too old, re-run the thumbnailing
with the "FORCE" flag to force the thumbnail to be re-created.

> However, if all you have is one thumbnailer, then it's just
> convenient
> to version the entire cache and do a "rm -rf" when the version is
> bumped. :)

And is utterly wasteful if you have a shared thumbnail cache, as your
thumbnailer isn't the only one around.

> Also, it can be useful to version the whole cache, if for whatever
> reason, you decide to change its layout. I have been wondering if it
> would be good to add sub-directories for various sources. It could be
> for individual GOA accounts or at the provider level (eg., Flickr).
> It's not essential, but might make it easier or more flexible to
> remove the thumbnails for a disabled account. For the generic case,
> suppose the standard decides to use the actual sizes (ie., 128x128,
> 256x256) as folder sizes instead of "normal" and "large", because,
> you
> know, words like "new" and "large" are kind of risky.  What's beyond
> "new" or "large"? "Shiny" and "huge"? :)
>
> Anyway, I did it mostly for the convenience.

See above.

> > So there's definitely not much a thumbnailing API could do that
> > you'd
> > need. The thumbnailing API takes files, and wouldn't make taking 2
> > sources (file + serialised image operations) possible. You want a
> > private cache because the on-disk file itself doesn't change. You
> > want
> > bigger thumbnails, and the spec we implement doesn't allow that.
>
> Yeah, I am not really complaining. I understand the fundamental
> problem.  Yes, we are wasting some disk space and CPU by possibly
> thumbnailing the same file multiple times, but that's better than
> storing high resolution copies of the edited pixels and thumbnailing
> those using the generic APIs because the hi-res copies would be much
> larger than the duplicated thumbnails.

I don't understand the necessity of going through the thumbnailer when
you have edits on your photos. Surely the editor that added those edits
could save a thumbnail itself when it saves the edits to disk, no?

> (Once we have a decent codec API to load GeglBuffers that can replace
> GdkPixbuf for the image viewer/editor and thumbnailer case, it would
> already be something because the basic codecs would be more widely
> shared.)
>
> But the issues around sizes and versioning can be generally
> interesting, and you already covered that.
>
> Thanks for reading!
>
> Cheers,
> Rishi