GNOME Bugzilla – Bug 522803
fix pixbuf loader scaling for large ratios
Last modified: 2018-05-22 13:07:19 UTC
I've found that some images (which have a high uncompressed size / but a low bit-count) stall Nautilus for a while while it tries to generate the content. In my case, the images are typically 'gif' or 'png' and are either very tall (eg. 10,000px) or very wide. It's possible to specify a file size limit for live thumbnail generation - but it isn't an effect limiting factor in this case. Inadvertently navigating to a directory which contains one of these images, means I'm out of action for a small but noticeably-frustrating amount of time. Could an extra limit (maybe using time to process/generate) be imposed? Other information:
I don't think you can guess how much time it will take to generate the thumbnail before you do it. Also, you can still use the directory while the thumbnail is being created, as the thumbnailer runs in a separate thread. Maybe the image resolution could be used though. @Pavel: please do not confirm bugs with wrong fields (as this one).
Experienced the problem again last night - the image was a png at approx 500px by 14000px and it had a filesize of around 50kb. I couldn't do anything while the thumbnail was generating so I ended up having to turn thumbnails off. Computer is 1.6ghz pentium m, with 1gig. Let me know if you need any more information.
A sample image would be helpful. Can you attach your 500x14000 image here? Some gdk scaling routines perform VERY poorly at high scale-down ratios. See bug 80925. In gthumb, I found gdk_pixbuf_scale_simple to be unusable for scaling down by >100. I modified gthumb to use two scaling steps (first /10, then /N as needed). Your image is probably scaling at 14000 / 128 = 109.4. We would need to identify where exactly the image is being scaled... - Mike
Created attachment 108466 [details] image - png format - large dimensions - small file size here's an image which causes the freeze mentioned above...
This is a gdk-pixbuf issue. Re-assigning.
Created attachment 108604 [details] [review] Fix large-ratio scaling in pixbuf loader, v1 Here is a patch to use two-stage scaling in the pixbuf loader when the scaling factor exceeds 64. I used a test folder that had four 15000x400 tif images and four 15000x400 png images (solid colors). Without the patch, it took Nautilus 4 minutes and 30 seconds to thumbnail the folder. With the patch, it took 8 seconds. Obviously, the gdk_pixbuf scaling functions have serious problems with large ratios. This is a band-aid patch, until a math wiz can fix the functions properly. However, since bug 80925 has been open for 6 years, I don't think we should wait longer for some sort of fix, any fix. - Mike
Renaming bug for clarity.
*ping*
*ping* - who's into pixbuf? i'd love to get this in for 2.14
Andre, It is bug 80925 that really, really, needs to be fixed. I don't see how gtk can be used on embedded small-screen gizmos until it is fixed. Can you mark it as a blocker bug, or club someone on the head, or flap your arms madly, so it'll be fixed? My patch above would stop pixbuf from freezing, but it's just hiding the real problem. - Mike
I don't see any reason to put a workaround for this in gdk-pixbuf-scaled-anim.c ... which is far from the most common instance of scaling. If someone wants to work on this ... I think they just have to go ahead and fix the scaling code in GdkPixbuf. (No fear of old bugs allowed!) The simple approach to fixing the scaling code is: Scale the source down by factors of two until the minimum of the width and height scale factors is <= 2. (Preferrably not using the current code, but a special-cased scaler instead.) Call the current scaling code. It's not going to be as good as a complete rewrite, but it doesn't require much thought or research. Slightly tricky bits: - What to do if the source at some scale step has an odd width or height. Simplest thing to do, and probably OK is to just replicate the last column/row. - Not scaling the whole source image when you are only rendering a portion. Compute the "preimage of the destination" in the source (a double-value rectangle), round it out to a larger rectangle that has integer coordinates (and avoids the odd-width/height problem above if possible) and then scale that down by powers of two.
*** Bug 582125 has been marked as a duplicate of this bug. ***
*** Bug 754722 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/14.