This patch implements two things:
1. Add one extra type, nsStyleImageType::eStyleImageType_Url, and puts data of
this type in nsStyleImage::mUrlData.
2. Export SetURLValueData and GetURLValueData from nsStyleImage
With these chnages, we can simply use nsStyleImage::mUrlData to replace
Layer::mSourceURI in the next patch.
MozReview-Commit-ID: E20MEzXv8cg
This patch does the following in addition to a simple move:
* change the type of the pointers from RefPtr to nsCOMPtr
* move it from mozilla::css namespace to mozilla
MozReview-Commit-ID: 72MYq6kWm4s
nsStyleContext::CalcDifference had an optimization where, when we knew
that the old and new style context have the same rule node, we knew that
the only change hints that would need to be handled are those in the
"not handled for descendants" category, generated due to explicit
'inherit' values on reset properties. This was because any changes due
to differences in inherited properties should only have generated
"handled for descendants" change hints (and thus would already have been
handled on an ancestor).
Before bug 931668, this let us avoid calling CalcDifference on structs
that only would have generated hints that we knew we already would have
handled. However, after bug 931668, we compare all structs anyway so
that we can set the aEqualStructs outparam, so we don't gain anything
from this optimization. We can still return these change hints we know
will not need to be handled, and rely on ElementRestyler::CaptureChange
to filter them out.
MozReview-Commit-ID: Ld1s2Js0i6r
If nsStyleImageRequest::Resolve() has been called, we cache the DocGroup and
use it for dispatching events for the clean up task. Otherwise, it's safe to
do clean up task on non-main thread.
MozReview-Commit-ID: BXalEkc6dBm
I think there are three advantages of this change:
1. removes some dependencies from layout / painting code to pre-computed
value stuff in the style system;
2. makes it easier to audit usage of specific fields in style structs
(which is probably a side effect of the first one);
3. potentially improves performance since it doesn't go through the
unnecessary general logic in ExtractComputedValue.
Also, combined with the part before, we get a unified list for visited-
dependent properties so that we can ensure the assertion here and the
style difference calc code are consistent.
MozReview-Commit-ID: 5B9aN7CfRgI
During painting we do some image decoding, but we want to send the image progress notifications from that decoding async. The CSS image renderer checks if the image is complete before painting it. So if the decoding we did during painting resulted in the images becoming complete there is no way to tell that during the same paint. Thus making that decoding a waste of time.
So we add a limited way of telling if the result of a StartDecoding call has resulting in an image that is ready to paint so we can get that result during the same paint.
I would have prefered to change StartDecoding to just return a bool but that would have made the bool an outparam, which would make every StartDecoding call uglier with extra code. Changing it to a notxpcom function would have fixed that, but I'm not sure if that is safe.
