If there is an active provider which has yet to produce a frame, any
calls to SurfaceCache::Lookup will return MatchType::PENDING. If
RasterImage::Lookup gets the above result while given FLAG_SYNC_DECODE,
it will attempt to start a new decoder. It is entirely possible that
when we try to insert the new provider into the SurfaceCache, it cannot
because the original provider finally did produce something. In that
case we should abandon attempting to redecode and retry our lookup.
These asserts are somewhat faulty given the
image.downscale-during-decode.enabled preference is a live preference
and thus can change at any time. Given the decision to downscale is made
on the main thread, and it is asserted on a decoder thread, this will
always be inherently racy. Most of the time this isn't a problem, but
with our automated tests, we frequently flip this preference, and the
assertion may fail unnecessarily with an unrelated image. The reftests
themselves verify downscaling did or did not occur based upon comparison
to the reference, and don't require the assert for verification.
There are two other means from which a caller can get the current state
which originally ignored validation -- GetImageStatus and
StartDecodingWithResult. These methods are used by layout in some
circumstances to decide whether or not the image is ready to display. As
observed in some web platform tests, in particular
css/css-backgrounds-3/background-size-031.html, we may actually validate
and purge the cache for images under test. The state given by the
aforementioned methods was misleading, because validation changed it.
Now they take into account validation, and do not imply any particular
state while validation is in progress.
IProgressObserver::SetNotificationsDeferred is now used just for
ProgressTracker to track when there is a pending notification for
an observer. It has been renamed to MarkPendingNotify and
ClearPendingNotify to make a clear distinction.
When cache validation is in progress, imgRequestProxy defers its
notifications to its listener until the validation is complete. This is
because the cache may be discarded, and the current state will change.
It attempted to share the same flags with notification deferrals used by
ProgressTracker to indicate that there is a pending notification, but
this has problematic/confusing. Hence this patch creates dedicated flags
for notification deferrals due to cache validation.
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <