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 522803 - fix pixbuf loader scaling for large ratios
fix pixbuf loader scaling for large ratios
Status: RESOLVED OBSOLETE
Product: gdk-pixbuf
Classification: Platform
Component: pixops
git master
Other All
: Normal enhancement
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
: 582125 754722 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-03-16 18:36 UTC by lwhitmore
Modified: 2018-05-22 13:07 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
image - png format - large dimensions - small file size (16.74 KB, image/png)
2008-04-02 12:11 UTC, lwhitmore
  Details
Fix large-ratio scaling in pixbuf loader, v1 (2.54 KB, patch)
2008-04-04 12:57 UTC, Michael Chudobiak
needs-work Details | Review

Description lwhitmore 2008-03-16 18:36:35 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:
Comment 1 Cosimo Cecchi 2008-03-18 00:07:47 UTC
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).
Comment 2 lwhitmore 2008-03-18 13:24:18 UTC
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.
Comment 3 Michael Chudobiak 2008-04-01 20:16:40 UTC
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
Comment 4 lwhitmore 2008-04-02 12:11:15 UTC
Created attachment 108466 [details]
image - png format - large dimensions - small file size

here's an image which causes the freeze mentioned above...
Comment 5 Michael Chudobiak 2008-04-04 12:41:33 UTC
This is a gdk-pixbuf issue. Re-assigning.
Comment 6 Michael Chudobiak 2008-04-04 12:57:48 UTC
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
Comment 7 Michael Chudobiak 2008-04-04 13:08:28 UTC
Renaming bug for clarity.
Comment 8 André Klapper 2008-07-23 21:31:12 UTC
*ping*
Comment 9 André Klapper 2008-08-12 12:35:19 UTC
*ping* - who's into pixbuf? i'd love to get this in for 2.14
Comment 10 Michael Chudobiak 2008-08-12 13:00:36 UTC
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
Comment 11 Owen Taylor 2008-08-12 13:09:15 UTC
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.

Comment 12 Cosimo Cecchi 2009-05-13 07:53:54 UTC
*** Bug 582125 has been marked as a duplicate of this bug. ***
Comment 13 Michael Chudobiak 2015-12-25 15:42:41 UTC
*** Bug 754722 has been marked as a duplicate of this bug. ***
Comment 14 GNOME Infrastructure Team 2018-05-22 13:07:19 UTC
-- 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.