Fix incorrect zoom at init with `--scale-down`

[adsr]

Hello. When using the --scale-down option, images render incorrectly at first on my setup (Xfce). After resizing feh, the image renders correctly. The following issues may be related:

https://github.com/derf/feh/issues/696 https://github.com/derf/feh/issues/504 https://github.com/derf/feh/issues/494

I don't have any experience with Xlib, but I did narrow it down to a race condition occurring between winwidget_create_from_file and winwidget_show here:

https://github.com/derf/feh/blob/70a7b06654217ae291659976fd8b8b4827ec379b/src/slideshow.c#L109-L111

For example, if I set a breakpoint on winwidget_get_geometry (which is invoked by both of the above functions) and simply continue on both breaks, the image renders properly.

The comment about ConfigureNotify in winwidget_show caught my eye, and I noticed that the ConfigureNotify handler was also invoked when resizing the window (which fixes rendering), except that it falls into this branch:

https://github.com/derf/feh/blob/70a7b06654217ae291659976fd8b8b4827ec379b/src/events.c#L432-L434

Forcing this to occur in winwidget_show by invalidating the width property seems to fix the issue. Obviously not ideal but this seems to be a painless workaround, at least on my setup, until there is a real fix.

[derf]

Hi, thanks for taking a look at this problem!

Unfortunately, it doesn't seem to be quite that trivial. On my i3wm setup, feh's --scale-down renders images correctly, but with a small flicker right after startup due to showing the first image in an inappropriate size and then immediately re-rendering it. With your proposed patch, this flicker becomes more noticeable, because feh is taking a few milliseconds longer before it re-renders the image in the correct resolution.

I'll leave this PR open in the hope that I (or someone else) will have the capacity to get back to it, dig a little deeper into the leads you found, and maybe properly resolve it eventually.

[derf]

Could you check whether this issue still occurs with 856cb97e527c2cde795f42960fab3a22612471cb?

[adsr]

Hi it was still happening at 856cb97, but seems to be fixed on HEAD (00daaac). Bisected to 2ac79ea as the fix commit.

[derf]

That's good to hear, thanks for checking. I'll close this PR, as the underlying issue should no longer be present.