I consider use case of displaying many small image files (PNG etc). Storing thumbnails can double folder size with no reason. I have many screenshots, schematics, mockups etc. that can be previewed in Tracker.
2 Likes
I think it can be a problem for user who want a fast starting system. The programs and other non-writable system parts of the system need space and then we have in the future more big size apps and games, the system be slower (correct me if i am false here). If we generate every start of the system thumbnails the system need more time to start and it need more default hdd space.
On live CDs this would run never?
-
Would it be possible to use image preview in Tracker Add-on to use with a folder (ImagesâŚ)? Generate them in RAM?
-
Have a Viewer like Albums to give attributes (thumbnails, comments, ratings) to the images? Improve the program Albums?
-
Use Image preview in the Window menu by selecting the images, so now all the images in the folder would have to be generated at once?
-
Use a translator to handle the generation for attributes by saving?
I could look at the modification date instead of a CRC32 but I would have to store the modification date in an attribute or somewhere when I generate a thumbnail âThumbnail modification dateâ so that I have something to compare against to know that the modification date has changed and so the thumbnail needs to be regenerated. It doesnât fundamentally change what Iâm doing, calculating a CRC32 is fast, generating a thumbnail is relatively slow so I check the CRC32 before proceeding to do the heavy lifting of generating a thumbnail. Iâm not sure using the modification date is better than this, but perhaps it is because I wouldnât have to read the file contents that way, just the modification date so that may be faster. I only need the BStatable of a file instead of the BNode for those of you that understand what that means in terms of the Storage Kit. Of course I need the BNode to read and write the attribute but that comes in the next step and might not be needed if thereâs no reason to generate a thumbnail.
Recall that I only generate and store thumbnail attributes for the image sizes you actually view so itâs not like I generate all sizes at once, if you never look at a folder at 64x64 for example youâll never store any 64x64 icon attributes. Yes these attributes uses disk space, it trades disk space for cpu time. If you open a folder with 10,000 images in it, itâs beneficial that this process happens once instead of every time you open the folder IMHO.
I do store the attribute in RAM on file systems that donât support attributes, the thumbnails are generated and displayed, but not stored. A good example of where this happens is when you look at images on a CDROM or other read-only medium. Obviously I canât store the attributes there, but I can still generate the thumbnails and show them to you. It takes more CPU time this way but you still get thumbnails, they just need to be regenerated every time you open a folder with image files on it.
I also added an off switch for this feature in Tracker settings if you donât want thumbnails. If youâre concerned about the space/time/ram usage, turn it off and no more thumbnails will be generated.
Applications generating thumbnails on save is unnecessary because saving the file will modify it, which will trigger Tracker to regenerate the thumb for you automatically assuming the file is visible. If itâs not visible, for example if itâs in a folder that isnât open then thereâs no reason to regenerate the thumbnail until next time you open the folder. That said, having a server that runs in the background, i.e. Index Server that generates thumbnails for you while nothing else is going on might be something we want to do later on.
Concerning what Jim said that we could display additional information about a file. I think the most appropriate place for that kind of thing would be in the file information dialog. When you Get info on an image file it could display image specific information like the image width and height or if you Get info on a video it could show runtime length, video format, audio format, stuff like that. That information would need to be in attributes and itâs something Tracker could generate. We know if a file is an image or a video by the mime type that we calculate and the Translation kit gives us the ability to parse information on audio, video, and image files.
8 Likes
WowâŚthis is impressive 
Why donât u have created a patch for this yet? Is it still not stable enough?
Thumbnails can be generated on demand only for visible items in Tracker and in another thread. Before generation is finished for particular item, show original icon or some stub.
4 Likes
I think most implementations do it this way, no?
Thumbnails are already generated in another thread because each Tracker window is its own thread⌠although I suppose I could spawn another 'nother thread for the thumbnails. But why would I throw the results out when I was done, to save disk space? Bad plan. Everybodyâs a criticâŚ
1 Like
Using window thread will cause window to freeze when thumbnails are generated. Thumbnail generator thread can be one for Tracker process.
There are no meaning to save 32x32 thumbnail for 32x32 PNG image. Thumbnail storing on disk only have meaning for large images.
1 Like
If a computer or other device doesnât have room for thumbnails, it certainly doesnât have room for the original images.
2 Likes
I only need the BStatable of a file instead of the BNode for those of you that understand what that means in terms of the Storage Kit. Of course I need the BNode to read and write the attribute but that comes in the next step and might not be needed if thereâs no reason to generate a thumbnail.
Well you will still need a BNode to access the thumbnail generation date, unless that is stored in the parent directory and not per file (an advantage for dates here: youâd need only one date to compare with, for all files in a folder). But indeed Iâd say this strategy could be changed later, letâs get the thing merged and working first, and improve it later if needed 
When you Get info on an image file it could display image specific information like the image width and height or if you Get info on a video it could show runtime length, video format, audio format, stuff like that.
A few month ago I added an âAttributesâ tab to the Get Info window which shows the attributes in a column list view. So all thatâs needed is for the information to be populated.
Iâm still not a big fan of the idea of doing this all in Tracker, to me it seems better to do it in each app that generates files. Two reasons for this: I assume the apps know better whatâs relevant to store, and know things in a lot more details than what a translator can provide. And, it avois having to spawn a thread to scan all files in the background (or use the window thread and prevent user interaction while the scanning and attribute generation goes on, which could take some time in a machine with slow cpu or slow storage). Iâd say Tracker can be used as a fallback for files that have no type attribute yet, at the same time it âidentifiesâ them.
Sure, it needs more work in applications, but doesnât it fit the Haiku approach of doing things at the right place and time? I feel that doing it in Tracker is catching the problem at the wrong place because itâs cheaper in development efforts, but the disk access to rescan all files every time we open a directory is going to make Tracker as painfully slow as Windows file manager?
1 Like
I see these (valid) points. But having this set at Tracker level will let you switch it on/off globally, without affecting the original icon or other attributes on the physical file I supposeâŚ
Please, please add this! Iâve been wishing for this since beta1! If possible Iâd even push for support up to 512 by 512 icons like on the Mac â Haikuâs advantage is that icons are vector not raster, so theyâd scale up seamlessly without pixelation and artifacts. Itâd literally be the perfect system for this!
1 Like
CRC I would think wonât scale very well⌠If you CRC 20MB from each file and have 1000 files in a directory you have to read 20GB to check if they have changed
1 Like
Just my 2 cents but:
Can we begin by using the existing implementation which would probably be 100% better compared to no implementation at all?
Then we could iterate and optimize based on real usage data. Since there would be an on/off switch somewhere I really see no problem to experiment with existing implementation as it is.
1 Like
What about Query windows? I can imagine a haiku user wanting to query for all JPEG images in the system⌠but then there is no thumbnail support in the results.
Tracker should have auto layouted grid view that is usable in query window and open/save dialog.
2 Likes
Knowing what Index Server was intended to do, it seems as though the process of Finding Images and giving them a Preview would be given to an IndexServerAddOn. However, I understand that Index_Server is currently incomplete. Perhaps this is bike shedding.
1 Like
Not exactly. If the thumbnails are stored on disk, we need to decide on the storage format at least, otherwise we will be making things complicated if we need to change the format (and make sure things arre cleanly migrated). This is not an issue if they are not stored, of course, and only rendered on the fly when opening the window.
Also it has to be done in a way that doesnât make the window freeze until all thumbnails are rendered, otherwise it would indeed be more annoying than no implementation.