Re: [Tracker] Specifying thumbnailers as a service

[Philip Van Hoof <spam pvanhoof be>]

On Mon, 2008-09-01 at 09:53 -0700, Brian J. Tarricone wrote:
> On Mon, 01 Sep 2008 10:49:31 +0200 Philip Van Hoof wrote:

> > I think canceling is overkill. Making a thumbnail doesn't take longer
> > than a minute (and a minute is an extreme case). Users don't cancel
> > that.
>
> Strongly disagree.  I have a laptop, and say I'm on battery power.  If
> I'm scrolling through a big list of images in my file manager, and it's
> requesting thumbnails, they all get queued. 

Then you must tell the developer of your filemanager that he should only
request thumbnails for visible items, and for items that are likely
going to become visible soon. Instead of immediately all items in the
opened directory.

He could just prioritize the visible ones, and in a timeout check, if
the window is not closing, request thumbnails for nearby invisible
items.

No need for cancels ...

Just requesting all and canceling the unfinished ones when the window is
closing, sounds like messy programming to me.

I'm pretty sure most filemanagers are already doing such optimizations
for their thumbnailing work. Maybe even more clever ones.

> Say I find the file I want near the end of the list (by file name, not 
> thumbnail) and close the file manager window... but the thumbnail service
> keeps chugging along, uselessly creating thumbnails for 10s or 100s of 
> files, pegging the CPU and wasting my battery life.  I wouldn't be 
> particularly happy about that.

But then again, that wouldn't happen if the developer of the filemanger
is clever and only requests thumbnails for items that are visible and
perhaps after that starts with requesting the nearby items (and if the
window is closing, stops sending more requests).

Also note that this specification doesn't require a filemanager to use
it. A filemanager can still do its own "specialized" thumbnailing, and
it can even put thumbnail cache in $HOME/.thumbnail (the availability of
a daemon doesn't mean that nobody else can write in that cache).

> Cancellation could be easily implemented by returning an ID from the
> Create request that can be used to cancel the operation.  On the daemon
> side, canceling the request could be as easy as killing a subprocess,
> depending on implementation...

Who says that the daemon will implement creating a thumbnail in a proces
that can be killed? To be honest wouldn't that be a very good architec-
ture for a thumbnailer service:

  Imagine the thumbnailer creating 15,000 processes in case the 
  filemanager's developer didn't do it right and therefore did request
  thumbnails for all of the 15,000 items in your "Photos"-folder?

  I fear for your laptop's battery more than I feared when a few extra
  thumbnails didn't get canceled, if 15,000 processes got launched.

  I wonder if the kernel on a modest ARM device will actually schedule
  that sufficiently preemptive for the UI of the mobile to be
  responsive enough for the user not to simply shut it down thinking the
  device simply crashed completely.

  I don't think anything would redraw for at least a few minutes.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be