[haiku-development] Re: Image icons for images in Tracker
- From: Joseph Groover <looncraz@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 02 Mar 2012 11:10:56 -0600
On 3/2/2012 03:50, Gabriel Harrison wrote:
Wow this is a lot of information but it all seems logical. Let me
spend some time feeling out all these areas. If you still have your
old code lying around to look at Joseph, that would also be great.
Thanks for all this. I'll play with it over the weekend and see what
kind of progress I can make.
Thanks,
Gabriel
I'll have time to dig through my massive depots later, I'd thought I'd
give you a quick note as to how I achieved it, and also a couple of
patent warnings (ugh...).
My approach was a two-part system, the first part was Tracker's icon
search. I rewrote Tracker to use PNG icons stored as attributes on a
file (any file), then fall-back to PNG system icons on failure. When
the failure occurred an external application was launched, in the
background, to scan the folder for iconable images at low-priority. It
would then generate an icon for each image, and apply that image as an
attribute with a preview modification time as an attribute (never got
around to verifying those...).
I went through many different steps to get to that point... none of
which are standard w/ the way Haiku does icons.
Now here's the patent issue I promised:
Microsoft patented a couple of caching mechanisms for image preview in
the 90s... they hold patents which cover the following two methods:
1. Applying the image preview as an attribute of the file ( oops on my
part ;-) )
2. Creating a thumbnail database as a file in the folder containing images.
The patents do NOT cover a method I decided to use in LoonTracker (
something I may still complete one day.... ).
Store thumbnails and file modification dates relative to those
thumbnails as an archived BMessage of the parent folder.
That has quite a few advantages, as well. Just read the entire BMessage
in one or two disk operations and you can integrate the data into the
IconCache so it will check if the file in question has a preview icon
from a memory location.
From memory, I stored a struct for each entry in the BMessage:
typedef struct ImageThumbnailCacheEntry{
BString file; // by name
bigtime_t file_mtime; // modification time at time of
thumbnail generation
bool entry_accessed; // if false when IconCache
flushes the (updated) cache back to the folder, the entry is deleted
size_t thumbnail_data_size;
void * thumbnail_data; // I used PNG format
// accessor functions for IconCache
const char* FileName()...
bigtime_t FileModificationTime()...
bool GetThumnail(BBitmap*)...
bool GenerateNewThumbnail()...
bool UpdateThumbnail()... // only calls
GenerateNewThumbnail if mtime has changed
}...;
I think this would have been better implemented as a full-blown class.
Be mindful: generating a thumbnail can be quite slow, you will probably
want to check the environment for safe mode and prevent thumbnails...
without DMA, bitmap acceleration, and a whole host of other performance
features you can make the system quite sluggish... and you will most
certainly want to do as much threading as possible. I planned on
running a thread relative to the IconCache that would silently call
UpdateThumbnail() across the list of structs.
I'll see if I have the code above as well ( I should have that, for
certain ) and I'll modify it to be a class, maybe you could use it...
Hrm... I'm quite late... gotta run!
--The loon
Other related posts:
