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 726087 - Image rendering is terribly slow
Image rendering is terribly slow
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
3.3.x
Other Linux
: Normal major
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
Depends on:
Blocks:
 
 
Reported: 2014-03-11 06:12 UTC by Sulphur
Modified: 2015-12-18 15:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sulphur 2014-03-11 06:12:30 UTC
Using version 3.3.1 of gThumb (on Ubuntu 14.04), images are rendered terribly slow. When switching from one to another (say, by using page up/down), a blurry image appears quickly, then sits there for about five seconds before the clear picture takes its place.

The last version of gThumb I used before 3.3.1 was 3.0.2 (so I'm not quite sure when the regression was introduced), which it did not have this problem; even large high-resolution pictures taken with a DSLR displayed instantaneously. 

Thanks.
Comment 1 Michael Chudobiak 2014-03-11 12:33:39 UTC
I've noticed this too, on 3.3.1 on Fedora 20. Image loading can be painfully slow.
Comment 2 Sulphur 2014-03-11 16:20:35 UTC
I just tested gThumb on a live USB image (same OS, same gThumb version), but it seemed that the images rendered quickly. I'm really not sure why that would be the case.
Comment 3 Paolo Bacchilega 2014-03-11 18:03:07 UTC
Does it happen with any image type? Different image types have different image loaders and it is possible that a specific image loader is slower than others.
Comment 4 Michael Chudobiak 2014-03-11 18:29:37 UTC
A sample image:

http://www.avtechpulse.com/downloads/IMG_20131213_181613.jpg

It takes a ~2 seconds to load on my system Fedora 20 system with git master gthumb (3.3.1).

On a different Fedora 20 system, with gThumb 3.2.6, it loads nearly instantly.

- Mike
Comment 5 Nili 2014-03-12 14:01:15 UTC
For me is a little slow too now. Used to be really fast on last old style 3:3.2.6-1 since new layout is changed, now is a little slow when I compare with a different imageviewer.

Using #! crunbang walforf 11 - debian testing / jessie.

3:3.2.6-1 for me was the super fast.

Just load an folder with 100 image HQ like 3000x2000 or 4500x3200 res just click one image to opened as Aibara OP said delay and is accompanied by a blurry then appear normal after 2 or 3 sec. The problem is not the load of image or their organization to gTHUMB (the load has remain the same, quick... but opening an HQ image is a little slwo which wasn't on last version). 

I'm still using 3.3.1 and love it, but really i miss 3.2.6 which was best gThumb ever at least for me.

Regards,
Nili
Comment 6 reynaerde 2014-05-09 03:58:18 UTC
I can confirm this problem for gThumb version 3.2.7, the version that was eventually shipped with Ubuntu 14.04. Image rendering is much slower than with previous versions and for large images it can take up to several seconds. 

Paolo, I tested it with several large images which I saved as .jpg, .png and .tiff. All of them have the slow rendering problem. 

However, as opposed to Fedora and Crunchbang/Debian as other reported above, all versions of gThumb in the 3.2.x series already have this problem on Ubuntu 14.04. So it might be related to other packages or libs that were included with Ubuntu and Fedora at different times, rather than something that was introduced with gThumb 3.3.x.
Comment 7 Sulphur 2014-05-09 20:56:43 UTC
I did some testing on Ubuntu 14.04. 

Version 3.2.7, included in the repositories, is slow too, as Reynaerde points out. For a large .jpg, it might take 2 seconds for it to show up on screen. Occasionally everything becomes extra slow and takes several seconds beyond that, but 2 seconds is the best case scenario. 

Nili mentioned that 3.2.6 worked fine, but I am in agreement with Reynaerde: when I tried 3.2.6 the same exact problem occurred: at least 2 seconds to load a large image. I'm not sure why it would work for Nili and not for us, save the OS version. 

That would perhaps point to a library issue, but when I installed version 3.0.2, the version included with Ubuntu 13.10, and the problem did *not* occur: the same series of images all loaded *instantaneously.* So unless that older version is calling on different libraries, I don't think they are the problem.
Comment 8 Romano Giannetti 2014-05-19 00:42:28 UTC
I have the same effect in 14.04. Moreover, in my laptop it seems that the image is never really sharp --- it is very difficult to assess the images that way. 

Example on the same image: eog (which is not exactly a good performer) and gthumb: http://imgur.com/Rzbcwym - http://imgur.com/BgXsJVH 

On 100% view the two are more or less the same, but the scaled version is definitely more blurry on gthumb. Has there been a change in scaling? 

[:~] % apt-cache policy gthumb
gthumb:
  Installed: 3:3.3.1.is.3.2.7-0ubuntu1
  Candidate: 3:3.3.1.is.3.2.7-0ubuntu1
  Version table:
 *** 3:3.3.1.is.3.2.7-0ubuntu1 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status

Did not happen with the version on 13.10. It was fast and reliable.
Comment 9 reynaerde 2014-05-19 05:27:47 UTC
gThumb 3.3.2 and 3.2.8 were released yesterday, but nothing about the slow rendering problem was mentioned in the release notes. I will wait until I can find 3.2.8 in the repositories to test, but those willing to build the new versions themselves can of course do so.

Though I had not noticed it before, I can also confirm the problem addressed by Romano (comment #8). When an image is zoomed out to fit the screen, it is much blurrier in gThumb than in other image viewers.
Comment 10 Sulphur 2014-05-19 18:36:23 UTC
Go to the Viewer tab in Preferences, then turn the Zoom quality to Low.

This should solve the problem with the blurry images, as gThumb's "high quality" zoom actually blurs the image (perhaps good for small, pixelated images, but bad for nice high-res ones). 

Incidentally, turning the setting to low also makes rendering a lot faster! I'll have to do some more testing, but now even high-res pictures are loading quickly. This might have been the cause of this "bug".
Comment 11 reynaerde 2014-05-20 00:23:05 UTC
Aibara, while setting zoom quality to Low does indeed make gThumb faster, it is still a whole lot slower than it used to be. It is also much slower than other image viewers. You can check with a folder than contains hundreds of high-resolution images. Browse through them quickly and you will notice gThumb becoming extremely slow.

Setting zoom quality to low also results in, well, low quality image rendering. Whether it is noticeable seems to depend on the resolution of the image and the size of your gThumb window though. 

I tried gThumb version 3.3.2 that was released yesterday, but it does not solve the problem.
Comment 12 Sulphur 2014-05-21 03:45:47 UTC
Yes reynaerde, you are correct, it is not the solution, unfortunately. Setting the zoom quality to low makes gThumb usable for me, at least, but still not as fast as it was in the 3.0 series (which was very fast even with zoom quality set to high!). 

The high and low zoom settings in 3.0.2 are only slightly different when viewing a scaled high-res image. The low zoom setting of 3.2.7 is just about the same too (why it takes longer to load I don't know), but the high setting is just terrible and blurry. The issues may be related, though I've opened a separate bug for blurry issue here: https://bugzilla.gnome.org/show_bug.cgi?id=730489
Comment 13 Sulphur 2014-05-21 04:29:37 UTC
Paolo had asked about image types, so I tested this problem with a series of images in three different formats: jpg, png, and tif. The problem affects all three.
Comment 14 Steve Rainwater 2014-06-26 20:22:20 UTC
I'm experiencing this issue too. When I try to go through a gallery of images and hit the "page up" or "page down" to go to the next image, it takes right around 9 seconds for the next image to appear. 

I'm running gThumb 3.2.8 on Fedora 20. Images are not unusual in any way that I can see. They are JPEGs, about 4MB each, 3648x5472, generated by a Canon DSLR.

Older versions of gThumb that I used to use could go to next/prev images almost instantly, I don't think I noticed the problem until the recent upgrade to Fedora 20.
Comment 15 Bill 2014-07-22 03:22:15 UTC
I also get the slow loading or rendering of jpg images ever since upgrading from f19 to f20. Current gthumb 3.2.8. Large images are especially bad. I did a comparison with gwenview and that is still fast at scrolling through a directory containing large images
Comment 16 nik 2014-09-04 01:36:40 UTC
When switching from one image to another I believe seeing 3 images: First the thumbnail just scaled up. Then it takes multiple seconds until a second very sharp image is shown (visible for a fraction of a second). The third and final image is blurry.

While resizing the window I always see "the sharp image" which becomes blurry the moment I stop moving.

/nik
Comment 17 reynaerde 2014-09-21 10:10:04 UTC
Not sure if it is rude to ask, but is there any update on this? It has been half a year now and the status of this bug is still unconfirmed.

For those using Gnome 3.10 or higher it is also not possible to use the older but much faster gThumb 3.1. This is because gThumb 3.1 in combination with Gnome 3.10 introduces a bug that causes thumbnails to display incorrectly. As a result, Ubuntu 14.04 and Fedora 20 users can only opt for gThumb 3.2 and 3.3 both of which are affected by the slow rendering problem.

If anybody knows how to get gThumb 3.1 to work on a system with Gnome 3.10, I would also love to hear it!
Comment 18 Steve Rainwater 2014-10-10 19:20:15 UTC
I tried installing the F20 binary of gthumb 3.3.2-4 found here:

 http://koji.fedoraproject.org/koji/taskinfo?taskID=7635579

It definitely renders much faster than 3.2.8 on F20. Instead of taking 10 seconds to see the next image, I see a very blurry version of the next image immediately and after about 5 seconds, it begins to resolve into a clear image. It's still much slower than other viewing programs but it's on the right track by cutting the time in half from 3.2.8. Hopefully further improvements can be made. Until a new stable release is out, I've had to abandon gthumb altogether as it's just not usable for photography work anymore. I've switched to something called Ristretto which is not as nice overall as gthumb but at least I can actually view images in it. Looking forward to returning to gthumb once this bug is squashed!
Comment 19 reynaerde 2015-02-12 01:11:29 UTC
Good news: I just tested version 3.3.3 of gThumb that was released a few days ago and it is as fast as it was before! Please test it for yourselves though.

https://mail.gnome.org/archives/gthumb-list/2015-February/msg00000.html
Comment 20 Michael Chudobiak 2015-12-18 15:35:05 UTC
3.4.1 seems pretty zippy, so I'll close this as fixed.