This prevents copies and avoids the hack we have to avoid this, which
right now is using nsDependent{C,}String.
Non-virtual actors can still use `nsString` if they need to on the
receiving end.
Differential Revision: https://phabricator.services.mozilla.com/D152519
All its members are optional, so we can just use it as a plain struct
rather than Maybe<> all around, which simplifies the code and prevents
silly bugs like bug 1779592.
Mostly automatic via:
rg -l 'SVGImageContext' . | xargs sed -i 's/Maybe<SVGImageContext>/SVGImageContext/g'
With trivial build fixes.
Not intended to change behavior.
Differential Revision: https://phabricator.services.mozilla.com/D151846
I've also tested the behavior in Chrome and I think this is
the correct way of doing it. Chrome also only notifies the
cached entry once, it won't notify it even if I manually
trigger it after pageload.
Differential Revision: https://phabricator.services.mozilla.com/D138346
Instead treat these protocols as "never-expiring" protocols, and clean
up revalidation code while at it.
Depends on D132347
Differential Revision: https://phabricator.services.mozilla.com/D132348
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
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
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
Turns out my patch above causes some failures because chrome:// channels
don't have cache information, so we conservatively assume they always
expire, which causes some interesting timing issues in a single test.
Fun stuff.
Tweak the code so that SubresourceCacheValidationInfo has the
pre-existing data:// URI special-case and also special-cases chrome://
URIs.
Differential Revision: https://phabricator.services.mozilla.com/D124921
Turns out my patch above causes some failures because chrome:// channels
don't have cache information, so we conservatively assume they always
expire, which causes some interesting timing issues in a single test.
Fun stuff.
Tweak the code so that SubresourceCacheValidationInfo has the
pre-existing data:// URI special-case and also special-cases chrome://
URIs.
Differential Revision: https://phabricator.services.mozilla.com/D124921
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
