Manage invalidation policy directly in the image decoder

RESOLVED FIXED in mozilla37

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: seth, Assigned: seth)

Tracking

unspecified
mozilla37
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Right now, Decoder is fairly naive about sending invalidations - it just collects whatever the decoder implementation classes give it, and relies on RasterImage::FinishedSomeDecoding to apply policy. However, it's tricky to get the logic right in FinishedSomeDecoding, and in bug 1079627 it will become essentially impossible. On top of that, sending spurious invalidations from a decoder (which is running off-main-thread) to FinishedSomeDecoding running on the main thread is hugely wasteful if we're going to immediately drop those invalidations.

This patch gives Decoder the responsibility for managing this policy directly. It implements the following rules:

If Decoder::SetSendPartialInvalidations(true) was called before Decoder::Init, then we will send partial invalidations for the first frame, and nothing afterwards, because invalidations for subsequent frames should come from the animation playback code.

If Decoder::SetSendPartialInvalidations(false) was called before Decoder::Init (or if SetSendPartialInvalidations wasn't called at all; this is the default), then we will send no partial invalidations for the first frame, and instead send a single invalidation for the entire first frame when it's complete.
Here's the patch. Note we call SetSendPartialInvalidations(true) if mHasBeenDecoded is false. This should produce the same results as the existing code, where we avoid sending partial invalidations if we've been decoded before.
Attachment #8544318 - Flags: review?(tnikkel)
Attachment #8544318 - Flags: review?(tnikkel) → review+
Thanks for the review! Try job here:

https://tbpl.mozilla.org/?tree=Try&rev=c805585ab778
https://hg.mozilla.org/mozilla-central/rev/b61e84480e2e
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
You need to log in before you can comment on or make changes to this bug.