When not using blob recordings for vector images we use simple surface providers. When we get an invalidation we will call SurfaceCache::InvalidateImage which will set a dirty bit on all blob recordings and remove all other surfaces from the surface cache. And if it finds a blob recording we will call ResumeHonoringInvalidations. This is not enough to invalidate in the case of a non-animated vector image using the webrender GetImageProvider path. Even though the surface isn't in the surface cache anymore it is still cached on the frame and when we tell it about the invalidation it will just has the image provider to update its key. That will call this code
https://searchfox.org/mozilla-central/rev/cdddec7fd690700efa4d6b48532cf70155e0386b/image/DecodedSurfaceProvider.cpp#222
which will just share the same surface as before the invalidation happened again. That will let us handle one invalidation but it still won't fix the bug, we need to call ResumeHonoringInvalidations so that we handle further invalidations.
When not using the image provider path, we don't save an image provider on the frame, that alone would avoid this problem. But we also call ResumeHonoringInvalidations for every successful call of VectorImage::Draw.
* * *
imported patch asvfref
Differential Revision: https://phabricator.services.mozilla.com/D174450
This pref exists only for fuzzers so they don't waste time on overly large images. The way fuzzers set the pref requires it to be live.
Differential Revision: https://phabricator.services.mozilla.com/D198498
This pref exists only for fuzzers so they don't waste time on overly large images. The way fuzzers set the pref requires it to be live.
Differential Revision: https://phabricator.services.mozilla.com/D198498
Large image sizes slow down fuzzing for webp and aren't likely to catch any more issues. We will still want to fuzz without this pref to catch any large image issues though.
Differential Revision: https://phabricator.services.mozilla.com/D188156
To release the images, `ClearReleasingImages` basically takes all the `RefPtr<Image>` out of `mReleasingImagesOnMainThread` under a lock and then clears them, all on the main thread. This can be safely done before as late as XPCOMShutdownFinal on the main thread in order to avoid leaks.
Differential Revision: https://phabricator.services.mozilla.com/D160624
If the surface cache entry is a placeholder (because we haven't decoded any frames yet) then a surface cache lookup will not return anything, so we can't get ahold of the AnimationSurfaceProvider to call reset on it.
I also looked at the other places we call Lookup on the surface cache and it seems correct to me for them to not get the surface if it's still a placeholder.
Differential Revision: https://phabricator.services.mozilla.com/D143894
Because these images are loaded as embeds/objects we can't get a hold of them to apply most usual methods of waiting for decode (img.decode, using a special powers image notifications observer). This should hopefully be enough to avoid hitting this in automation.
Backout the patch for bug 1722422 (the one that changed it from an assert to a leak) because I think it's easier to classify/recognize the assert than the leak in the logs.
Differential Revision: https://phabricator.services.mozilla.com/D139464
Destroying an already_AddRefed if it holds a non-null pointers asserts because it leaks. But we want the leak here, so leak in a way that doesn't assert.
Differential Revision: https://phabricator.services.mozilla.com/D139266
Destroying an already_AddRefed if it holds a non-null pointers asserts because it leaks. But we want the leak here, so leak in a way that doesn't assert.
Differential Revision: https://phabricator.services.mozilla.com/D139266
If a vector image does not have an intrinsic size as returned by
VectorImage::GetWidth and VectorImage::GetHeight, currently factor-of-2
scaling is disabled. With this patch, we just assume a default size of
100x100, adjusted by the intrinsic ratio if available, to get the
baseline size for determing appropriate factor-of-2 sizes.
Differential Revision: https://phabricator.services.mozilla.com/D133395
Now that we no longer have the extra layer of ImageContainers providing
a superficial level of caching/reuse of existing blob recordings, we
need some way to share recordings. This part adds support to
SurfaceCache to store BlobSurfaceProvider objects.
This includes the specialized code for invalidating SVG images. In
particular this is useful for animated SVG images. In general we want to
avoid changing the image key whenever possible so that we avoid
reallocating the underlying buffers in the compositor process for the
rasterized blob images.
We also need to track the ImageIntRegion used by the recording. If a
caller only wants a slice of the SVG image, then we need to track this
differentiation in our cache entries. At this time, we don't allow
substitutes for entries with a region exclusion.
Differential Revision: https://phabricator.services.mozilla.com/D126603
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
Now that we no longer have the extra layer of ImageContainers providing
a superficial level of caching/reuse of existing blob recordings, we
need some way to share recordings. This part adds support to
SurfaceCache to store BlobSurfaceProvider objects.
This includes the specialized code for invalidating SVG images. In
particular this is useful for animated SVG images. In general we want to
avoid changing the image key whenever possible so that we avoid
reallocating the underlying buffers in the compositor process for the
rasterized blob images.
We also need to track the ImageIntRegion used by the recording. If a
caller only wants a slice of the SVG image, then we need to track this
differentiation in our cache entries. At this time, we don't allow
substitutes for entries with a region exclusion.
Differential Revision: https://phabricator.services.mozilla.com/D126603
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
Now that we no longer have the extra layer of ImageContainers providing
a superficial level of caching/reuse of existing blob recordings, we
need some way to share recordings. This part adds support to
SurfaceCache to store BlobSurfaceProvider objects.
This includes the specialized code for invalidating SVG images. In
particular this is useful for animated SVG images. In general we want to
avoid changing the image key whenever possible so that we avoid
reallocating the underlying buffers in the compositor process for the
rasterized blob images.
We also need to track the ImageIntRegion used by the recording. If a
caller only wants a slice of the SVG image, then we need to track this
differentiation in our cache entries. At this time, we don't allow
substitutes for entries with a region exclusion.
Differential Revision: https://phabricator.services.mozilla.com/D126603
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
An image container can keep a surface alive longer than it can remain in
the cache, if it is indeed kept in the cache. We should cross reference
our memory report generated from the SurfaceCache against any surfaces
stored in our ImageContainer objects to ensure they are all reported.
This is of particular importance for blob recordings which are not put
into SurfaceCache. While the recordings themselves have their own memory
reporting inside of WebRender, it would be good to know what recordings
we are keeping alive from the content side to help break it down.
Differential Revision: https://phabricator.services.mozilla.com/D115517
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Current gecko dispatches tasks of releasing image::Image to main thread at some places. The task was dispatched individually. Then there were cases that the releasing took long time. It increased peak memory usage and caused a problem like Bug 1639280. When main thread is very busy like WebGL, it takes longer time until the Image is released on main thread. If Images are released quickly on main thread, we could reduce peak memory usage.
When SurfaceCache::ReleaseImageOnMainThread() is called, there could be already an ongoing task for releasing Image. It could reduce a duration until release on main thread.
Differential Revision: https://phabricator.services.mozilla.com/D82864
This patch also tries to remove the event target entirely if it would
default to the main thread on a null event target.
Depends on D67634
Differential Revision: https://phabricator.services.mozilla.com/D67635
--HG--
extra : moz-landing-system : lando
