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 733213 - Jerky transition when opening some photos from the grid
Jerky transition when opening some photos from the grid
Status: RESOLVED FIXED
Product: gnome-photos
Classification: Applications
Component: general
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME photos maintainer(s)
GNOME photos maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-07-15 16:05 UTC by Allan Day
Modified: 2015-01-23 15:34 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allan Day 2014-07-15 16:05:16 UTC
I have these images in ~/Downloads - https://cloud.gnome.org/public.php?service=files&t=56c4e757ee67a4c1bcd0063579513506

When I open "dia gnome 2013.jpg" from the grid, the transition feels jerky and uneven. There is an obvious pause before the image grid fades out. The crossfade is so slow/uneven that I actually see a faint image of the photo behind the grid as it transitions in. It's pretty fast opening the image from nautilus using eog.

If the transition is going to take a long time, I would recommend avoiding a crossfade. Instead, fade out the grid and then fade in the image as two sequential animations.
Comment 1 Debarshi Ray 2014-07-30 10:37:43 UTC
(In reply to comment #0)
> When I open "dia gnome 2013.jpg" from the grid, the transition feels jerky and
> uneven. There is an obvious pause before the image grid fades out. The
> crossfade is so slow/uneven that I actually see a faint image of the photo
> behind the grid as it transitions in. It's pretty fast opening the image from
> nautilus using eog.

Are you really sure that they show up very fast in eog? One of the images (GNOME hispanio.jpg) freezes eog (and the rest of my system) for a while towards the end. After looking at perf, my guess is that the JPEG decoder is chewing up a lot of CPU.
Comment 2 Debarshi Ray 2014-07-30 12:48:21 UTC
This is a bit weird. It behaves differently on Pranav's system, where things are not so slow with eog.

I think one option could be to first load the thumbnail, which we already have, and then slowly transition in the real image when we have loaded it. That might help with making the transitions smoother.
Comment 3 Debarshi Ray 2015-01-23 13:58:20 UTC
Can you please try gnome-photos Git master. The following commit should speed things up. It would be even better if you could test it with the Git masters of babl and gegl. Please edit gnome-photos/configure.ac to use gegl-0.3 if you do that.

commit 04d201fff34fe37d27c22583be37ff558bb91f2d
Author: Debarshi Ray <debarshir@gnome.org>
Date:   Fri Jan 23 12:40:41 2015 +0100

    gegl-gtk-view-helper: Optimize blitting

    Use Babl's cairo-ARGB32 format. It has some optimizations and is
    noticeably faster than the equivalent B'aG'aR'aA u8.

    From gegl-gtk commit 3d28897caf9ee0bd091ea93df5a2a00fe4355302
Comment 4 Debarshi Ray 2015-01-23 15:34:16 UTC
From IRC:

15:31 <rishi> Can we consider                                                   
      https://bugzilla.gnome.org/show_bug.cgi?id=733213 and                     
      https://bugzilla.gnome.org/show_bug.cgi?id=731391 closed ?
15:32 <aday> based on the minimal testing i've done here, i'd say yes