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:

#696
#504
#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:

feh/src/slideshow.c

Lines 109 to 111 in 70a7b06

	if ((w = winwidget_create_from_file(l, WIN_TYPE_SLIDESHOW)) != NULL) {
	success = 1;
	winwidget_show(w);

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:

feh/src/events.c

Lines 432 to 434 in 70a7b06

	if ((w->w != ev->xconfigure.width)
	|| (w->h != ev->xconfigure.height)) {
	D(("assigning size and rerendering\n"));

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 856cb97?

[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.