GNOME Bugzilla – Bug 770266
Image flickering / not showing up properly with high res pictures on hidpi screens
Last modified: 2021-06-19 08:45:53 UTC
Created attachment 333977 [details] gdk-debug=all On a HiDPI screen with 2x UI scaling factor, displaying high resolution images (36Mpx) doesn't not work, flickers and is really slow. On up to date arch 64bit.
Created attachment 333978 [details] Example result
Can I provide any extra information to help?
Hello?
Bug still present in 3.22.1, does anybody care?
I meant 3.20.5 on gnome 3.22.1... Also worth nothing the problem does not occur on wayland (but then there are other problems that I will report separately).
eog doesn't have any special treatment for HiDPI screens right now but expects GTK+ to just do the right thing in that case... (nor do I have the necessary hardware) Does the flickering eventually stop? For the moment I can only imagine that the fadeout of the overlay buttons produces redraws that are too large which causes flickering. But it should eventually stop flickering then when the animation is finished (assuming you didn't move the mouse triggering it again). Another option: Can you retry with image smoothing disabled in the options? Maybe there is some edge case here when eog redraws the image with the filtered variant. Can you capture the output eog does with EOG_DEBUG=1? Try not to move the mouse over the UI then. Weird that it's working in Wayland and not in X11, usually that is the other way around.
The flickering eventually stops but in a "bad" (grey image) state. It is an image smoothing issue indeed. Setting org.gnome.eog.view interpolate to false solves the issue. So I guess it is a cairo problem?
(In reply to François Guerraz from comment #7) > Setting org.gnome.eog.view interpolate to false solves the issue. So I guess > it is a cairo problem? Well, I am getting the impression, but the only difference in the two drawing cycles (as you may have noticed) is the filtering parameter that is given to cairo, but that would mean something is odd in the filtering code which should make it happen to more people I think. It's still odd that it works in Wayland for you, so it might also be something driver related if not something totally obscure in eog itself. Does it work on 100% zoom? This should be a single drawing cycle. Maybe you could try reverting the commits 8169e0ac6447ebeb1d1e809213ce82b814b62550 and 88c4f54eb9cee69b1eebef462df27f76119bec62. That should make eog do one-pass drawing again even if filtering is enabled.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/eog/-/issues/ Thank you for your understanding and your help.