[haiku] Re: Thumbnail generation feedback
- From: John Scipione <jscipione@xxxxxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sun, 29 Aug 2021 13:06:30 -0400
On Sun, Aug 29, 2021 at 10:18 AM Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
wrote:
Hey John,
first of all, nice, and long awaited feature! Thanks for working on this!
Thank you for your feedback, always welcome and I know it can be hard to
pour over a bunch of code to figure out the little details in it. This
feature has been a long time coming and will be a bit more time before it
really gets fully flushed out.
However, there are lots of details that need improvement IMO:
1) I don't think it's needed to make this a setting (once it works well
enough)
I anticipated that there might be some problems (e.g. crashes) with this
feature once it sees wider testing being hammered on rather than just by
me. We've already seen a couple for instance
https://dev.haiku-os.org/ticket/17225. I could be wrong but I have a
feeling that some of our translators may have some thread-safety issues
that are being revealed here.
Once these issues get ironed out my idea is to keep the setting but to turn
it ON by default instead of off. That way you'll get thumbnails unless you
don't like them then you can go to Tracker preferences and turn them off.
For now let’s keep it off to avoid introducing too many problems.
2) I don't like that you always store 128x128 pixels, no matter the
actual aspect ratio. Instead, the default Tracker icon layout should be
changed to a grid. Or, as long as that's not there, you could just
pretend the thumbnail to be 128x128, instead of storing it that way --
you have a special code path for thumbnails, anyway.
Up until this point I've only been thinking of whether or not we want to
generate thumbnails smaller than 128x128, not bigger! I eventually settled
on just the one size 128x128 once webp made the file size small enough to
possibly fit in the inode. There are two things to consider here. Firstly,
thumbnail generation can be expensive so we don't want to do too much of
it. Secondly, upscaling images doesn't produce very nice looking results so
I'm trying to avoid it if I can.
3) For a thumbnail 128x128 is very little, especially with 4K, it's just
tiny images. 512 pixels sound much more useful there. However, then it
would make sense to have a setting for high resolution thumbnails, as
the size requirements will be more noticeable. Even though most
thumbnails are about 3 KB, they usually still fit in a 4K node in 128x128.
The easy way to do this would be to create new thumbnail attributes to hold
those sizes i.e. Media:Thumbnail:512. Another way is to store the largest
size thumbnail in the the Media:Thumbnail attribute instead of always
storing 128x128. The sticking point for this working is that I'd have to
detect what thumbnail size has been stored in the attribute somehow. Just
by looking at the attribute data I don't know what the icon size is. I
might have to create another attribute to store the thumbnail size, but I'd
like to avoid this if possible.
4) It would be great to always update the MIME type, if there is none.
That could be a setting. Also, I think "Window" is not a good place for
this setting. How about a new "Icons" category, where you could also
move the volume icon controls to?
You are stepping on my idea for the future Tracker preferences a little bit
but that's ok. I'd like to remove the sidebar from Tracker preferences and
lay out the settings in boxes all in one window like how Deskbar
preferences looks/works now. If I were to create another box in Tracker
preferences that would have to fit in the main window later. This probably
wouldn't be a big deal in the end, so *shrug* ok.
5) I have tested with a folder with 54 images. At first, only two of
them had the MIME type set (as I copy those from my digital camera, they
are rarely moved or touched, and thus don't get a MIME type by default
in Tracker). Those two got their preview. However, when I then selected
all, and moved them a bit, so that they all got a MIME type, only a
couple of them got a thumbnail. I had to close, and reopen the folder
several times until all thumbnails were there.
Thumbnails rely on the BEOS:TYPE attribute to be present before they are
generated. Needing a BEOS:TYPE attribute is not different from how we get
the default paint smear image icon, it also relies on BEOS:TYPE and if it's
not there you'll get the generic file icon. As you've observed you may have
to select the icons to get the BEOS:TYPE to pop in. This is not great but
unfortunately it's how Tracker has always worked. This part of Tracker
needs some improvement.
The fact that only the two images in your folder that had a BEOS:TYPE
attribute on them got thumbnails generated for them is not shocking, that's
basically how Tracker file type identification has always worked.
However, it should have begun identifying and generating thumbnails once
you selected the images without having to close and reopen the window
several times. You could go in the images folder using Terminal and delete
BEOS:TYPE as well as the Media:Thumbnail and CreationTime attributes to see
the whole process happen again.
Maybe thumbail gen is simply going too slow, perhaps because of you only
having a single (virtual) core while I’ve been testing on 4.
It seems to compute a couple of images at once, and only the first batch
will succeed. Even though I only have a single CPU in VirtualBox for
performance reasons, it computed 8 images or so at once, which will just
take longer in this case.
Thumbnail generation happens all at once and pops the icons in as they are
generated. There is no rate limiting on how many thumbnails/threads can be
going at once... but there probably should be. It will only generate
thumbnails for the images you're currently looking at, but as you scroll a
window with many images in it Tracker will spawn more and more thumbnail
generation threads without limit.
It sounds like what you’re seeing is a log jam of too many threads not
enough processors so the thumbnail generation process is taking a long time.
Other related posts:
