Created attachment 173471 [details]
test image

I noticed a rather bizarre problem. When zoomed in (or just 1:1) on an image so the scroll bars appear, the scroll bars can fail to cover the whole image properly, so that the right and bottom edges get a few pixels shaved off. This seems to throw out the whole geometry of the scrolling.

Of course a demonstration is worth a thousand words, so Steps To Reproduce:

1. Download the attached demonstration image. Actually any will do, but it's useful to be looking at the same thing.
2. Shrink the eog window so the image is zoomed out to show the whole thing.
3. Click "1" (ie. zoom to "normal size", which is 1:1)
4. Scroll to the bottom right corner with the scroll bars. You'll notice the red border can no longer be seen.
5. Increase the size of the window again. The borders reappear, and the scrollbars mysteriously move toward their centers.
6. Use the scrollbars (which have now moved) to scroll "off the edge of the picture". The red border is repeated, filling the "empty space" with red.

This problem didn't exist in 2.30.2 so I've done a git bisect and the offending revision seems to be this one:

ceadfd9141867358aea715ea060a2abe18e7846a is the first bad commit
commit ceadfd9141867358aea715ea060a2abe18e7846a
Author: Felix Riemann <friemann@gnome.org>
Date:   Thu May 13 21:37:41 2010 +0200

    Finish making EogScrollView GSEAL-compatible.
    
    Eog should be completely GSEAL-compatible now.
    Completes bug 606883.

:040000 040000 14f140ef07da6da59a5c94cffc22f3c72ab8f449 f5c898aa8ffde3b2a8c3517340be412dcb78dc34 M	src

This revision modifies eog-scroll-view.c in particular making changes like this in update_scrollbar_values:
-		priv->hadj->page_size = MIN (scaled_width, allocation->width);
+		page_size = MIN (scaled_width, allocation.width);

I observe (read: speculate) that these changes mean that new values are only sometimes actually inserted into priv->hadj, and that these new values are sometimes important. On the basis of this I wrote the attached ad-hoc (ie. probably not commit-quality) patch which fixes the problem so far for me. Of course it seems likely that the root cause is something deeper than this

I discovered this bug on eog 2.32.0. I haven't been able to test on trunk, since I lack the libraries required to build the recent versions. The relevant code in update_scrollbar_values has in fact been modified since 2.32.0, so this bug may not apply to trunk.

ADDENDUM:
Having done some more testing, it looks like my patch is not a complete solution. Sometimes the horizontal scroll bar seems to disappear entirely at step 3, depending somehow on how the window is resized. This could be because what I've noticed is not the whole story, or just revealing a seperate bug. The former seems more likely to me.