[KimDaBa] Speeding up scrolling

[Robert L Krawitz]

   From: "Jesper K. Pedersen" <blackie at blackie.dk>
   Date: Tue, 11 Jan 2005 07:33:08 +0100

   I'm not sure I like this soluion, simply because whoever asked for
   an image might rightfully expect it to show up eventually.
   Nevertheless it sounds like when a new item gets in, the old one is
   paused, while the new is processes, which is of course wrong.

What's actually going on (in the current source base) is the opposite
-- the items are processed in the order in which they came in (since
the thumbnails don't have the priority bits set), so if you scroll
rapidly, it can't display the thumbnails until it gets caught up.

I agree that the patch I sent isn't the right thing, but it may give
some ideas.

   I'm currently fighting the *beeeeeeeep* thumbnail view, and all my
   kimdaba time today will likely go in that direction, but I'll have
   a look at it when I'm done. Till then, please be gentle with your
   pagedown key ;-)

A couple of other ideas:

1) Tag thumbnail requests in a special way allowing the thumbnail view
   to dequeue the requests en masse (it's not a good idea to force the
   thumbnail view, or the individual thumbnails, to dequeue themselves
   individually -- the time required to dequeue them would be
   quadratic, so if there's a backlog of several thousand requests, it
   could take a while).

   Perhaps a way to do it would be to have an image manager iterator,
   allowing a client to selectively dequeue requests.  This would be
   somewhat hazardous, since the lock would have to be held for the
   lifetime of the iterator, including code outside the image
   manager's control.  However, it would allow the thumbnail view to
   easily clobber requests outside of the current visible set of
   thumbnails.

2) Allow a request to specify that it's dequeueable, and when the
   queue backlog reaches a certain amount, automatically dequeue the
   requests.

3) Specify another state for the status return (in addition to success
   or failure, that a request was dequeued).  This would allow the
   request to be resubmitted.  Obviously, you'd have to watch out for
   resubmission storms.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton