Re: GnomeDesktopThumbnail API replacement

[Debarshi Ray <rishi is lostca se>]

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.

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.

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.

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

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

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.

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

(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