Re: GtkImageView for EOG

["BJörn Lindqvist" <bjourne gmail com>]

Hello Federico! You have resurrected a really old thread and I gather
there is not much interest in GtkImageView, so this will be purely
theoretical.

On 10/30/07, Federico Mena Quintero <federico ximian com> wrote:
> On Mon, 2007-09-24 at 01:25 +0200, BJörn Lindqvist wrote:
>
> > The three lost features are AFAICT, EOG:s delayed filtering,
> > incremental zoom and fullscreen upscaling. If you zoom in on an image,
> > EOG first displays the image using nearest filtering and triggers a
> > timer which does the bilinear filtering when it times out.
> > GtkImageView also uses much larger zoom increments that EogScrollView.
> > Zooming goes from 100% to 150% to 200% while in EogScrollView you have
> > to zoom in 15 times to increase the zoom by the same amount.
>
> Looks like you just destroyed the secret sauce of EOG :)

Secret sauce is for McDonald's! :) Secret implies it is different,
unknown and behaves different from what I'm accustomed to. Kind of
exactly the opposite of what I want in a desktop component app.

> * You want zooming to be smooth and fast.  Since machines are not fast
> enough to do bilinear filtering of full-screen images, EOG does this in
> two stages.  The first stage is a super-fast, synchronous pass with no
> interpolation where the whole window is painted.  This tricks your eyes
> into seeing the zoomed image instantly.

It doesn't trick my eyes. When I zoom in, EOG kind of flickers one
frame before displaying the image correctly. Yes, I know it is the
NEAREST filtering pass showing an initial view of the image, but to me
it looks like flicker. The effect is especially pronounced when you
are viewing a very large image of a map or some other detailed image
zoomed out. The NEAREST rendering produces a view that is totally
different from the BILINEAR rendering so you still have to wait the
extra milliseconds until the BILINEAR pass is done before you can
focus on the image.

Image viewers on mobile phones on the other hand, does it quite well
because they use a better first pass rendering so the differences
aren't that big.

Also, on upscales (zoom > 100%) the scaling is so fast that you don't
need the NEAREST rendering at all. It is very well optimized all
thanks to you and Owen. :)

> The second stage is an asynchronous, interruptible,
> bilinear-interpolated repaint where the window gets painted in small
> tiles.  If your machine is not fast enough to finish repainting the
> whole window before you change the zoom factor or scroll again, EOG
> will interrupt the painting process and resume it when it can.  This
> is all done in the idle loop, with no timers involved.  All that
> funny microtile code is to maintain an accurate view of the dirty
> region.

The code is quite genial, but IMHO, gThumb's method is better and
simpler.

> * You want zooming to be gradual.  If you change the zoom factor by too
> much, your brain will take some time to adjust its bearings after each
> change:  "what was I looking at?".  If you change the zoom factor by too
> little, you get annoyed that the "scroll wheel zooms too slowly".  This
> is why web pages scroll by a few pixels with the wheel, not by a
> page-ful.

Not sure you want that. EOG always annoys me in that I have to press
'+' 20 times to zoom in enough. It would be nice to have some kind of
zoom in animation between discreet zoom steps though.

> * Fullscreen upscaling:  what do you mean?

When viewing an image in fullscreen, it is upscaled so that it expands
to the screen boundaries.


-- 
mvh Björn