It turns out that RasterImage's implementation of FrameRect is the only caller of FrameBlender::RawGetFrame outside of FrameBlender itself. We're going to start storing animated frames in the SurfaceCache, and while it wouldn't be impossible to implement FrameBlender::RawGetFrame with the new design, it will add more complexity than I'd like. FrameRect is actually only called in one place: ProgressTracker::SyncNotify, which is typically called when an imgRequestProxy gets cloned. In that situation, generally the new imgRequestProxy is being used by a new nsImageFrame or other client of imgIContainer which hasn't yet drawn itself for the first time. Therefore, it's not important to get the smallest possible invalidation rect for the current frame - and I'm not even sure it's desirable (though client code shouldn't be so naive that it would matter). In this bug, the code in ProgressTracker::SyncNotify will be changed to always invalidate the entire image. For the vast majority of images, this produces identical results to the old approach, but the calculation is much cheaper. (Since we don't have to look up a frame and so forth.) For images with no intrinsic size, we fall back to nsIntRect::GetMaxSizedIntRect(), which is exactly what VectorImage::FrameRect always returned in any case. (Since some SVG images have an intrinsic size, the new approach is thus "better" in this case, though presumably client code would client the invalidation rect to their bounds anyway.) The rest of the patch will just consist of ripping out all the FrameRect implementations.

Here's the patch.

Ack, messed up the patch upload. *Here's* the patch.

Try job here: https://tbpl.mozilla.org/?tree=Try&rev=8b17f7fce49f

Try looks green.

Thanks for the review! Pushed: https://hg.mozilla.org/integration/mozilla-inbound/rev/3f32666fc1dc