Image in fixed size window smaller than X11 desktop sometimes gets wrong zoom, reproducible.

[fidergo-stephane-gourichon]

INTRO/CONGRATS

First, thank for maintaining the excellent tool geeqie. I used it already 20 years ago before the fork when it was named gqview. For many years it was fast and bug-free (for my use cases).

Since Xubuntu 20.04 I have troubles, first #785 which was not important.

This one is more troublesome because it undermines trust about geeqie showing the actual image and not a cropped version.

ISSUE TYPE

• Bug Report

GEEQIE VERSION

/usr/bin/geeqie --version

Geeqie 1.5.1

What GTK toolkit is used to compile Geeqie?

Mmh, it's from official Ubuntu 20.04 repositories.

Appears to be gtk2, see below.

ldd /usr/bin/geeqie | grep -i gtk

    libgtk-x11-2.0.so.0 => /lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007f81b1987000)

OS / DISTRIBUTION

Xubuntu 20.04, running XFCE.

SUMMARY

Sometimes, when advancing through a directory of images, the zoom factor would change suddenly for some of the pictures.

Happens when the image window has a fixed size yet does not cover the whole X11 desktop, for example in multi-monitor setup.

STEPS TO REPRODUCE

Experimenting I refined the circumstances to reproduce this at will.

One way to make a fixed size window that does not cover the whole X11 desktop is:

• have an external monitor that is either on the left/right and taller than internal screen, or above/below internal screen and wider than it.
• ask window manager to make image window "full screen" (not asking geeqie to do it using f key). On xfwm4 it's Alt-F11, other window managers can do this.

Nearly any external monitor would be enough to reproduce the bug:

• In my example, the internal screen is 1920x1080 pixels.
• External screen is 1200x1920 pixels (1920x1200 rotated). Total desktop is therefore in a rectangle of 3120x1920 pixels.
• 1920x1200 not rotated would be enough also, because 1200 is bigger than 1080
• 1920x1080 rotated to 1080x1920 would be enough also, because 1920 is bigger than 1080
• even an external 1280x1024 pixels monitor, rotated, would be enough to reproduce, because 1280 is bigger than 1080
• or reduce definition of the main screen so that even a small external monitor is enough
• Or use a VM ;-).

Geeqie side:

• Open a directory with a number of pictures (as few as 10 might be enough, here 200+).
• Make sure file list is floating separate window.
• The floating separate window can be focused above image window, or unfocused below, or on an external screen, all these combinations can cause the bug.
• Zoom to fit (key X). Images have more lines than screen, so they are reduced to fit, leaving bars left and right.
• Press and hold PageDown. (I say hold because just a stroke is usually not enough, rarely, it is enough).
• After a fraction of a second geeqie has advanced a few images, release the key.

Expected

• Current picture shown with normal zoom to fit.
• Zoom ratio in tool window is consistent with both "zoom to fit" settings and image shown, here 1:~2.64 .
• Normal uniform bars on left and right.

Observed

• Current picture shown zoomed in, as if zoom changed. Not 1:1 as if pressed X.
• Zoom ratio in tool window is inconsistent with "zoom to fit" settings, showing 1:~1.48 . This is consistent with actual image zoom still.
• Pressing X does not change anything. This is unsurprising because the zoom-to-fit mode is already the current mode, but surprising because the picture definitely is not shown zoomed to fit screen.
• Pressing Z then X works around the bug, picture displayed normally.

But often, some internal state causes the bug to appear again.

Example :

• Press PageDown for next image. Next image also doesn't show correctly.
• Press PageUp to go back to previous image. It appears incorrect again the same way.
• Press PageUp to go back to the last image that was shown correctly. It appears correct as always.
• Press PageDown three times for next image. Images that appeared incorrect once appear incorrect again. Images never seen appear correct.

Another, striking example I have just now :

• Image 'a' shown, bug occurs
• Press PageDown, image 'b' shown, bug occurs
• Press PageUp, image 'a' shown, no bug!
• Press PageDown, image 'b' shown, no bug!
• Press PageUp, image 'a' shown, back to first step.
• This cycle can be repeated at will.
• I can unplug the external screen and focus float tool window on top and still continue this back-and-forth cycle showing the bug.

This suggests that geeqie caches information in several places and, when doing this cycle, fetches it from one place then the other then the first again. Surprising.

Additional information

• Observed since Xubuntu 20.04.

• Never observed in previous versions (1.4 and below).

• Sometimes bug happen when browsing without keeping PageDown pressed. Doing so just makes it easy to reproduce.

• Sometimes it even happens with first image shown on entering a directory.

• Bug can be reproduced at will putting the image window on external screen and tool window on internal screen (thus swapped compared to the described conditions). It looks like the necessary condition is that the image window dimensions is not the total desktop dimension.

Advanced analysis and hints

Internal screen is 1920x1080 pixels. External screen is 1200x1920 pixels (so, very tall). Total desktop is therefore in a rectangle of 3120x1920 pixels.

2848/1080 = 2.637037... ~ 2.64 is correct zoom ratio for a 1080-line window 2848/1920 = 1.483333... ~ 1.48 is the ratio that appears when bug occurs!

It looks like when the bug occurs, geeqie zooms the image to fit the total desktop (3210x1920 lines), and not the actual window dimensions (1920x1080 lines).

But the image window dimensions don't change, there is no window-related activity: bug is triggered by causing activity inside geeqie, for example keeping PageDown pressed.

Conclusion

• I'm pretty sure it is a bug in geeqie and not in X / window manager / whatever because nothing relevant external to geeqie changes between the bug and non-bug cases. Bug is triggered by causing activity inside geeqie.

• The bug occurs sometimes, but can be triggered easily keeping PageDown pressed (with the other preconditions). This suggests a race condition somewhere. Could it be that geeqie stores information about window dimensions in two places, the correct one covering the incorrect one most of the times, and the bug occuring when the wrong origin happens to take precedence?

[fidergo-stephane-gourichon]

I can't observe the problem any more, neither in 1.5.1, nor in latest master 955709e . I haven't change the hardware, only applied Ubuntu 20.04 update regularly. Perhaps the problem was in some dependency and was fixed there?

I guess we can close this, and reopen later if needed?

[fidergo-stephane-gourichon]

Woops, observed again with current master 1.6+git20210306-955709eb .

[fidergo-stephane-gourichon]

Hi @mowgli . As stated on https://github.com/BestImageViewer/geeqie/issues/786#issuecomment-792068830 the issue was observed again. Would you consider reopening? I'm willing to test fixes from any git branch.