gtk2 only: Some images keep scaling down.

[CamilleScholtz]

This only happens when using the gtk2 version, certain (random it seems) images keep scaling the window down till it's invisible, here's a webm: https://sr.ht/mTIN.webm

[phillipberndt]

I've seen that before, and thought I'd had fixed it..

• Are you familiar with git bisect, and could you check which version exactly reintroduces the bug?
• Which WM is that?

[CamilleScholtz]

Oh I'm very sorry, I forgot I was using the release version instead of git master, it's indeed fixed in the git master. A new release would be nice, since the last release was 40+ commits ago.

[phillipberndt]

Yeah, I know.. the only thing keeping me from it is that the actions branch isn't completed yet, but might obsolete some commits from master which aren't released yet. I'll try to speed things up a little :sweat_smile:

[CamilleScholtz]

It seems like a recent commit has reintroduced this bug.

[phillipberndt]

I'm apparently not affected this time. Could you check which commit exactly reintroduced the bug, please?

git bisect start HEAD "@{23 days ago}"
make clean pqiv && ./pqiv some_test_files
git bisect [good or bad]
-> repeat from step 2

should do the trick.

[phillipberndt]

I tried reproducing this on various machines, with Debian based Distributions running GTK 2.24.23, using Metacity, KWin, fvwm, xfwm4, openbox, mutter, awesome, i3 and icewm, all without success.

[CamilleScholtz]

Sorry, I forgot to respond, I checked though pretty much every commit and it seems like the bug has never been fixed, I don't know what causes it, or why I thought it was fixed, but maybe something with my configs. I'm currently using:

• Image: https://sr.ht/o9kF.jpg

NOTE: It only seems to happen with square-ish images, and especially with width images like the link I posted, never with pictures that are higher than they are width.

• pqiv: pqiv git master (version 2.4-116-g9671e82)
• config.make:

DESTDIR=
PREFIX=/usr
GTK_VERSION=2
CROSS=
EXECUTABLE_EXTENSION=
PKG_CONFIG=pkg-config
EXTRA_DEFS=
BACKENDS_BUILD=static

BACKENDS=archive_cbx poppler wand gdkpixbuf 

NOTE: I tried enabling only the gdkpixbuf backend, and it still happens, same when only enabling the wand backend.

• Window manager: openbox (git master, https://github.com/danakj/openbox)
• Config: https://github.com/onodera-punpun/dotfiles/tree/punpun/openbox

NOTE: Same happens when using the default rc.xml.

• gtk: gtk2 version 2.24.29

[phillipberndt]

Perfect, thanks! openbox master is affected here as well. This also helped me to remember where the issue surfaced last time. It was in i3: https://github.com/i3/i3/issues/1032

Upon loading an image, I hint the WM to enforce the aspect ratio of pqiv's window, and to resize it to the correct size. If a WM does not process the aspect ratio exactly the same way GTK does, due to rounding errors, it might assess that the size requested by GTK is off by one pixel. GTK, on the other hand, has some code in place to retry, but is also slightly off, resulting in a loop which is responsible for what you see. I'd say that both sides are to blame here. But, in my experience, it should be much easier to get the openbox devs to fix this than to get the GTK devs to even admit that this is a bug. If you'd like to report this to them, note that the example that I attached to the i3 bug does apparently not suffice to reproduce the issue in openbox.

However, since this is the second WM that has this issue, I'll also see if I can manage to come up with a workaround.

[phillipberndt]

I just committed a workaround that works for me. Can you confirm that it fixes the bug?

[CamilleScholtz]

Yup, this indeed fixes the bug, thanks (again)!

[CamilleScholtz]

I'll try playing around with the openbox source and send them a PR if I manage to fix it, although is seems like the openbox development is kinda death.

This bug manifests itself also in mpv, however they just add a single black pixel line to the sides of a video (as seen in this image: https://sr.ht/jl9y.png), you might want to check how they circumvent this bug (if they do that is).

[CamilleScholtz]

Erm, I'm really sorry to be such a bother, but I'm reopening this issue again.

Upon closer inspection it seems like the fix you pushed only fixes the issue if the offending image (always seems to be a width image like I mentioned earlier in this issue) is the first or only image to be opened. However when opening a bunch of images, the scaling bug reoccurs.

[phillipberndt]

I can't reproduce this in a 1500x1000 Xephyr screen, with Openbox 3.6 compiled from the github master, with an unmodified rc, pqiv in its default configuration & various other images (such that your testcase is in the middle) with different aspect ratios!?

[CamilleScholtz]

Seems to be fixed now.

On further testing it seems to have been fixed by:

"pqiv will now no longer enforce an aspect ratio in its window, because of recurring bugs due to this feature. You can restore this behaviour using the new --enforce-aspect-ratio option."