Re: GnomeDesktopThumbnail API replacement

On Tue, 2018-01-30 at 11:06 +0000, Debarshi Ray wrote:

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

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

Last but not the least, I find it important to version the cache
tide over bugs in the thumbnailer.

You don't need the whole cache to be versioned. Thumbnailers can
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
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

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

But the issues around sizes and versioning can be generally
interesting, and you already covered that.

Thanks for reading!


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