Currently we only support high quality scaling on OS X. We remain performant on that platform because Coregraphics caches a copy of the scaled image keyed on the destination surface. This means we only need to scale the first time we draw it, and subsequent draws use the scaled copy. To support this on other platforms we need a place to cache and a mechanism for deciding what should be discarded and when. Ideally, the mechanism here would be built into cairo, however, I think it makes sense to prototype it in Firefox to make sure it matches what we need first. Unless we have reasons particular reasons to do otherwise we should match what Coregraphics does because it's semantics seem to work pretty well for us currently.

Not a bad idea; the infrastructure doesn't even have to be in cairo, since we can just use the cairo user data facility for this.

From a preliminary look at the requirements I don't see any reason why this can't be built into imgContainer somehow. Should be easier with the new architecture.

Here is some research on what other browsers do on Windows: Scrolling a single large image downscaled: - Opera: Fast - IE: Slow - Chrome: Fast - Safari: Slow Scrolling a single large image downscaled painted twice: - Opera: Slow - IE: Slow - Chrome: Fast - Safari: Slow Scrolling a single large image downscaled to two different sizes: - Opera: Slow - IE: Slow - Chrome: Slow - Safari: Slow

On OS X: Scrolling a single large image downscaled: - Firefox: Slow - Safari: Fast Scrolling a single large image downscaled painted twice: - Firefox: Slow - Safari: Fast Scrolling a single large image downscaled to two different sizes: - Firefox: Fast - Safari: Fast The Firefox results are pretty weird, especially the last one.

See also bug 468496, where we would really like to be able to scale locally (not in the OS graphics layer) to avoid bugs and/or extreme slowness in Cairo's EXTEND_PAD mode on Linux and (apparently) also Mac. Caching the scaled images would be necessary for that to be performant, too.

To the extent that this feature may cause performance issues, maybe the team can create a -moz style to specify what type of resample filter is applied. When high quality scaling was introduced in IE7, MS used a style called <a href="http://msdn.microsoft.com/en-us/library/ms530822%28VS.85%29.aspx">-ms-interpolation-mode</a>. It is obsolete in IE8. Not that I'm suggesting taking a lead from MS. :) WRT caching, my use case may be worth considering. I'm a die-hard fluid designer and intend to include an oversized image (1280px wide) in my img tag, then set the width to a percentage, rather than a fixed pixel width. From there, I intend to make the image container resizable by allowing the user to drag the border (via JavaScript). My concern is that FF may create a new cache copy of the resized image on every mousemove event, which could create a bigger performance hit than necessary. Waiting until mouseup to cache could avoid this. I'm very glad the team is looking at this.

(In reply to comment #6) > My concern is that FF may create a new cache copy of the resized image on every > mousemove event, which could create a bigger performance hit than necessary. > Waiting until mouseup to cache could avoid this. Just to make sure we're on the same page, this is definitely not the case right now. We cache only the decoded image at full size, and resize on draw. That being the case, we're also going to make sure your use case doesn't break horribly when we get to this. :)

The link below shows the HTML-only version of a dynamically sized image. I will post a link to the scripted version once I complete it, probably next weekend. The HTML differs slightly from my original description: I set the img tag's width to 100% and set the containing div's width to 40%. http://www.knowzy.com/bugzilla-517294-noscript.htm

As promised, here's sample code where the image is resizable by dragging the right border. The JavaScript adjusts the width of the image container relative to the starting X position of the mouse cursor. The image itself remains at 100% width. Let me know if you have questions on the code or suggestions on a better approach to resizing the image. http://www.knowzy.com/bugzilla-517294-scripted_resize.htm

Related or dupe of Bug #486918 maybe ?

Is there a plan to move forward on this bug (which has seen no real progress since its creation two years ago)? I appreciate that core Firefox devs have other priorities, but perhaps some of the work could be delegated. From what I can see there are two parts to this bug: 1a) Decide on where caching should be implemented 1b) Decide on caching / discarding semantics 2a) Implement caching mechanism, perhaps piggybacking off earlier caching work 2b) Implement caching / discarding semantics and integrate with image resizing 2c) Integrate and enable Lanczos scaler (which jrmuizel already wrote) The first part may require some discussion among core Firefox devs, but shouldn't be too much work if the right people get pinged. After that, new bugs can be filed the second part, which can then be mentored, and fixed by interested volunteers. If that sounds reasonable, can the first part be prioritized for Firefox 11?

(In reply to Emanuel Hoogeveen from comment #11) > If that sounds reasonable, can the first part be prioritized for Firefox 11? I'm happy to participate in any such design discussion, but I think it's only worth having if we have a reason to believe that somebody's going to work on it. Are you volunteering? ;-)

(In reply to Bobby Holley (:bholley) from comment #12) > Are you volunteering? ;-) If that's what it takes, yeah ;) I don't have a lot of experience working on a project as big as Firefox, but I guess I can learn.

(In reply to Emanuel Hoogeveen from comment #13) > (In reply to Bobby Holley (:bholley) from comment #12) > > Are you volunteering? ;-) > If that's what it takes, yeah ;) I don't have a lot of experience working on > a project as big as Firefox, but I guess I can learn. Awesome! Feel free to ping me with any questions. :-) Given his cairo expertise, I think Jeff is the best person to outline how this should go down. Jeff, can you weigh in? Joe and I can chime in anywhere we have input.

Jeff (jrmuizel that is), can you comment here?

This was completely implemented in bug 486918.