After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769499 - Interpolation on zooming is slow
Interpolation on zooming is slow
Status: RESOLVED NOTABUG
Product: eog
Classification: Core
Component: image viewer
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: EOG Maintainers
EOG Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-03 23:17 UTC by sworddragon2
Modified: 2016-09-11 16:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description sworddragon2 2016-08-03 23:17:37 UTC
With Eye of GNOME 3.20.3 if I'm zooming to a non-original size I'm noticing that with every zoom interpolation is applied to the image where the transition from sharp to smooth is always visible. But with Eye of GNOME 3.18.2 this transition was not visible so I'm wondering if there is now a performance issue.
Comment 1 Felix Riemann 2016-08-15 18:00:49 UTC
Yes, before 3.20 the downscaling algorithm used was not very good but fast enough to be used in a single pass. Especially grainy pictures could come out really awkward looking as the grain literally intensified. Other images showed extreme aliasing artifacts.

Since 3.20 we use an improved algorithm in cairo that produces a much better quality, that however is too slow for one-pass drawing. So, I switched to two-pass drawing again.

See bug 665897.
---
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 665897 ***
Comment 2 sworddragon2 2016-08-17 12:10:43 UTC
Since this ticket got marked as a duplicate does it mean the behavior got changed so that the interpolation is not noticeable anymore? If not I think this ticket should be marked as INVALID instead.
Comment 3 sworddragon2 2016-09-04 11:40:38 UTC
Also I'm noticing that the interpolation is always redone if the window gets changed. I'm not sure if this is intended too.
Comment 4 Felix Riemann 2016-09-11 14:49:24 UTC
h(In reply to sworddragon2 from comment #2)
> Since this ticket got marked as a duplicate does it mean the behavior got
> changed so that the interpolation is not noticeable anymore? If not I think
> this ticket should be marked as INVALID instead.

Getting the interpolation to become not noticable is something I don't think can be achieved with eog's drawing code unless the interpolation as is becomes much faster. The only thing that might be worth playing around with is the delay that eog waits before trigering the interpolated redraw.

(In reply to sworddragon2 from comment #3)
> Also I'm noticing that the interpolation is always redone if the window gets
> changed. I'm not sure if this is intended too.

The interpolation is hooked to the drawing events to the image. So, if anything causes the image are to become "dirty" it will trigger the re-interpolation. Normally GTK tries to make the area to be redrawn as small as possible. So, what exactly do you change?
Comment 5 sworddragon2 2016-09-11 16:14:33 UTC
(In reply to Felix Riemann from comment #4)
> The only thing that might be worth playing around with
> is the delay that eog waits before trigering the interpolated redraw.

There is currently an additional delay implemented? Removing it could maybe help as currently zooming in images looks really broken. Maybe I should also consider disabling the interpolation in case there is an option for it.


(In reply to Felix Riemann from comment #4)
> The interpolation is hooked to the drawing events to the image. So, if
> anything causes the image are to become "dirty" it will trigger the
> re-interpolation. Normally GTK tries to make the area to be redrawn as small
> as possible. So, what exactly do you change?

Switching the window with the task bar (for example from the image to the browser and then back to the image again) is enough to cause the interpolation to trigger. Maybe this case is a GTK+ bug?