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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list