Make them perform the image load (if needed), instead of copying the
image requests from the original document.
This is needed for CSS for stuff like:
@media print {
#foo::before {
content: url(bar.png);
}
}
And so on. For images, we should do this as well. Nothing prevents you
from doing:
<picture>
<source srcset="print.png" media="print">
<source srcset="screen.png" media="not print">
<img>
</picture>
And that should in theory work. It works after this patch, and I added a
test for that.
This patch is a bit bigger than I'd like, but I didn't find a more
reasonable way to split it up.
Making static docs able to do image loads is most of the patch and is
mostly straight-forward. This allows to remove the hacky "change the
loading document" thing that CSS images do, which is just working around
the CSP of the print document.
I need to enable background colors in printpreview_helper so as to be
able to have a reference page for all the different image types.
Differential Revision: https://phabricator.services.mozilla.com/D81779
If you do a diff, all of the different shared surfaces get merged together,
because the diffing process removes all PIDs from the paths. This means
you end up hitting an assertion when the diffing process tries to combine
entries with the same path but different kinds.
Differential Revision: https://phabricator.services.mozilla.com/D83585
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
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
If the scrollable div ends up as the first-encountered scrollframe, it gets a
big displayport that is just over 5000px CSS pixels tall (on GeckoView). When we
check for images being "nearly visible" we expand that displayport further by a
pref-controlled multiplier, which ends up doubling the displayport height to
over 10000 CSS pixels. So for the image to actually get detected as outside the
"nearly visible rect" it needs to be positioned further down in the iframe.
This test was previously passing on GeckoView because the scrollable div was
not getting detected as the first-encountered scrollframe; the root scrollframe
for the top-level document was the one getting the displayport even though it
didn't really need it. A later patch in this bug changes the first-encountered
scrollframe, causing this test to fail without this patch.
Differential Revision: https://phabricator.services.mozilla.com/D82777
It's possible only `OnStartRequest()` and `OnStopRequest()` was called, but no `OnDataAvailable()`. If so, when `OnStopRequest()` is being called, we would have no image but the channel status is a success.
Therefore, before setting the image container, we should also ensure we get the image already.
Differential Revision: https://phabricator.services.mozilla.com/D80744
We did not pass FLAG_HIGH_QUALITY_SCALING down to the document used to
rasterize the SVG to a surface, resulting in embedded raster images to
not use high quality downscaling.
Differential Revision: https://phabricator.services.mozilla.com/D56422
This test fails already on central if you change this line:
https://searchfox.org/mozilla-central/rev/027893497316897b8f292bde48dbb6da2391a331/image/test/unit/test_private_channel.js#93
by:
Ci.nsIReferrerInfo.EMPTY
Because the previous part of the test populates the image cache. The
test wants to check that the channel for the image load is properly
flagged as private and thus that the http cache is partitioned
appropriately, thus clearing the image caches seems sane.
While at it, also fix it so that we send a valid image instead of base64
text, though that change is not technically needed so feel free to ask
me to remove it.
Differential Revision: https://phabricator.services.mozilla.com/D79848
Make the stylesheet cache respect the same headers as the image cache
does. This makes no-cache stylesheets work as they do now, which is
useful for developers that want to develop sites locally, and for
shift-reloads, etc.
Differential Revision: https://phabricator.services.mozilla.com/D78659
We really should be color managing them. It was a mistake and
misunderstanding of how Chrome worked because of differences in how we
color manage canvas.
Differential Revision: https://phabricator.services.mozilla.com/D79295
We can perform the same function as RecyclingSourceSurface by checking
the ref count of the underlying surface directly. We need to ensure
WebRender is explicitly aware that it is a recycled surface, but that is
easily achieved by changing the type of the surface. This avoids
unnecessary heap allocations, particularly in the case where many
elements on the same page refer to the same animation (and thus
duplicating RecyclingSourceSurface objects).
Differential Revision: https://phabricator.services.mozilla.com/D77513
Make the stylesheet cache respect the same headers as the image cache
does. This makes no-cache stylesheets work as they do now, which is
useful for developers that want to develop sites locally, and for
shift-reloads, etc.
Differential Revision: https://phabricator.services.mozilla.com/D78659
If we hit an OOM or similar when creating a SourceBuffer for an image,
we will hit COMPLETE immediately as the next read that goes to the
SourceBuffer from a SourceBufferIterator. If the iterator has yet to do
a read, that means it will hit COMPLETE right away without giving
anything. This patch fixes the WebP decoder to handle this case, as well
as adds test cases for all of the current image decoders.
Differential Revision: https://phabricator.services.mozilla.com/D77131
Dynamically toggle support for displaying image/webp and image/avif according
to the values of the image.webp.enabled and image.avif.enabled prefs.
Differential Revision: https://phabricator.services.mozilla.com/D76977
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
This drops `followLinks` as 1) it has been no-op on UNIX for a long time and 2) its Windows implementation never had a proper symlink support.
Differential Revision: https://phabricator.services.mozilla.com/D75569
This drops `followLinks` as 1) it has been no-op on UNIX for a long time and 2) its Windows implementation never had a proper symlink support.
Differential Revision: https://phabricator.services.mozilla.com/D75569
Also, add `clang-format off` directives to files which are ignored by
.clang-format-ignore so that the editor isn't trying to reformat them
Differential Revision: https://phabricator.services.mozilla.com/D76217
Since AnimationState::UpdateState now depends on a specific frame of the animation being in the surface cache we need to call UpdateState whenever we add a new frame.
Depends on D73583
Differential Revision: https://phabricator.services.mozilla.com/D73584
It takes a frame count argument but probably never gets a value we haven't already seen in a NotifyProgress call, so this doesn't fix anything as far as I know.
Depends on D73564
Differential Revision: https://phabricator.services.mozilla.com/D73583
The img.decode promise for animated images that aren't in the document might not resolve in common cases. Specifically for animated images that have been decoded and then discarded, so that mCompositedFrameInvalid is true.
mCompositedFrameInvalid is cleared by either:
1) the image is fully decoded and NotifyDecodeComplete is called.
2) RequestRefresh is able to advance to the current frame.
We don't call RequestRefresh on animated images that aren't in the document and we only decode a certain number of frames ahead of the current frame (even for fully retained animation buffers), so neither of these will happen with long enough animated images.
So we need to make sure that mCompositedFrameInvalid eventually gets cleared any time a decode is requested (which the FrameAnimator gets notified about via GetCompositedFrame). We do that be calling UpdateState in GetCompositedFrame whenever mCompositedFrameInvalid is true and the image is in the surface cache.
This runs into a second problem: UpdateState uses |mIsCurrentlyDecoded = aResult.Surface().IsFullyDecoded()| to determine when to clear mCompositedFrameInvalid. As mentioned above, we don't fully decode animated images. Further, for animated images that are large enough we use a discarding animation buffer that never keeps around all the frames and so IsFullyDecoded always returns false. So we replace that with a check that we can seek to the current animated frame index.
Differential Revision: https://phabricator.services.mozilla.com/D73564
Raw Cr.ERROR don't get stack information, same as throwing JS literals instead
of `new Error()`s.
This was done automatically with a new eslint rule that will be introduced in
the next commit. One instance of a raw Cr.ERROR was not replaced since it is
used in a test that specifically checks the preservation of raw Cr values in
XPCJS. The rule will be disabled for that instance.
Differential Revision: https://phabricator.services.mozilla.com/D28073
It appears some websites assume we will not color manage untagged images
and encode metadata in the image's surface data. Chrome matches this
behaviour. We should probably do the same for webcompat.
Differential Revision: https://phabricator.services.mozilla.com/D73737
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- No support for ICC profiles (bug 1634741)
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
There are many limitations currently, but this prototype should successfully
render most basic AVIF images. Known limitations:
- No support for any derived image items (crop, rotate, etc.)
- No support for alpha planes
- The primary image item must be an av01 (no grid support)
- HDR images aren't tone-mapped
Differential Revision: https://phabricator.services.mozilla.com/D68498
Emilio Cobos Álvarez
Andrew McCreight
Frederik Braun
tkhan
Bogdan Tara
longsonr
Christoph Kerschbaumer
sotaro
Kartikaya Gupta
Sebastian Streich
Edgar Chen
Simon Giesecke
alwu
Andrew Osmond
Kris Maglione
Timothy Nikkel
Razvan Maries
Dorel Luca
Honza Bambas
Kershaw Chang
Csoregi Natalia
Andrea Marchesini
Noemi Erli
Masatoshi Kimura
Jon Bauman
Kagami Sascha Rosylight
Butkovits Atila
Mihai Alexandru Michis
wesj
Narcis Beleuzu
Coroiu Cristina
Cameron McCormack
Christian Holler (:decoder)
Sylvestre Ledru
Matt Woodrow
Ian Moody
Nathan Froyd