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.
(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
Related or dupe of Bug #486918 maybe ?
8 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 486918
You need to log in before you can comment on or make changes to this bug.