This will be used by layers as a replacement for ImageContainer's
ContainerProducerID for tracking if the same imgIRequest/imgIContainer
own the cached WebRenderImageProvider.
Differential Revision: https://phabricator.services.mozilla.com/D126598
This provides the framework to allow ISurfaceProvider objects to
implement WebRenderImageProvider. It is straightforward for rasterized
providers (DecodedSurfaceProvider, and SimpleSurfaceProvider). Later
parts in this series will provide the necessary changes for blob
recordings and for animatedi images.
Differential Revision: https://phabricator.services.mozilla.com/D126597
In later parts in this series, GetImageProvider will replace
GetImageContainerAtSize. This will be a more specialized and lower
overhead means to get a wr::ImageKey for a particular surface.
Differential Revision: https://phabricator.services.mozilla.com/D126596
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
This is a fairly significant update, so required a few changes to Gecko code, but I've commented on the interesting details, so they should be easy to find
Differential Revision: https://phabricator.services.mozilla.com/D129465
This WebRenderImageProvider/ISurfaceProvider subclass provides the
implementation for blob recordings. This is mostly just taking the
functionality that was previously in SourceSurfaceBlobImage.
Differential Revision: https://phabricator.services.mozilla.com/D126602
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
This will be used by layers as a replacement for ImageContainer's
ContainerProducerID for tracking if the same imgIRequest/imgIContainer
own the cached WebRenderImageProvider.
Differential Revision: https://phabricator.services.mozilla.com/D126598
This provides the framework to allow ISurfaceProvider objects to
implement WebRenderImageProvider. It is straightforward for rasterized
providers (DecodedSurfaceProvider, and SimpleSurfaceProvider). Later
parts in this series will provide the necessary changes for blob
recordings and for animatedi images.
Differential Revision: https://phabricator.services.mozilla.com/D126597
In later parts in this series, GetImageProvider will replace
GetImageContainerAtSize. This will be a more specialized and lower
overhead means to get a wr::ImageKey for a particular surface.
Differential Revision: https://phabricator.services.mozilla.com/D126596
We no longer use SourceSurfaceMappedData because we only support
SourceSurfaceSharedData-backed imgFrame in the SurfaceCache now.
Differential Revision: https://phabricator.services.mozilla.com/D126595
Rather than change every use of IntSize/Rect/Point in image/, this patch
attempts to draw the line at the relevant parts of the decoding pipeline
to prevent confusion about which size and orientation we are working
with.
Differential Revision: https://phabricator.services.mozilla.com/D126381
This attribute is not used in Gecko, but exists for use by other
applications. Specifically, the APP_TYPE_EDITOR type is given permission
to load privileged images as tested by browser_docshell_type_editor.js.
Before these changes, that test passed because the docshell was loaded
in a different process, so the cache was empty when each load occurred,
but after my changes the process ends up being re-used, so the image
cache bypasses this check.
This changes the image cache key to also include the app type
information so that it will be compared before re-using the entry.
Depends on D126405
Differential Revision: https://phabricator.services.mozilla.com/D126557
This attribute is not used in Gecko, but exists for use by other
applications. Specifically, the APP_TYPE_EDITOR type is given permission
to load privileged images as tested by browser_docshell_type_editor.js.
Before these changes, that test passed because the docshell was loaded
in a different process, so the cache was empty when each load occurred,
but after my changes the process ends up being re-used, so the image
cache bypasses this check.
This changes the image cache key to also include the app type
information so that it will be compared before re-using the entry.
Depends on D126405
Differential Revision: https://phabricator.services.mozilla.com/D126557
These are just small clean-ups. They're not non-unified build errors.
The function extractAttributeValue can be made static and doesn't need a forward declaration. All the callers of this function are in this .cpp file, after the function definition.
Depends on D126419
Differential Revision: https://phabricator.services.mozilla.com/D126420
Building with `ac_add_options --disable-unified-build` on macOS hits the following -Wunused-const-variable warning-as-error:
image/decoders/icon/nsIconURI.cpp:39:22 [-Wunused-const-variable] unused variable 'kIconURICID'.
`kIconURICID` was added in bug 1583044. The only use of `kIconURICID` was later removed in bug 1589337, leaving `kIconURICID` still defined but unused.
Differential Revision: https://phabricator.services.mozilla.com/D126419
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
We don't stop other animations and such, so seems weird to do it only
for animated images. This line comes from bug 70030, but we no longer
provide "Esc" as a shortcut for Stop(), so it's probably no longer
relevant for users.
Differential Revision: https://phabricator.services.mozilla.com/D125815
The logic to allow parsing of the multiple colr boxes is in the parent
update of mp4parse-rust to 72eb355. This change adds a confirmatory test in
gecko and updates telemetry to add new new "both" case for colr tracking.
Differential Revision: https://phabricator.services.mozilla.com/D125744
media/libjpeg/1050342.diff is no longer necessary and a correction
appears to have been made in the library. Chromium no longer uses this
patch either.
media/libjpeg/assembly-tables.diff and media/libjpeg/externalize-table.diff
require significant changes in order to apply. This may be done in a
future followup patch, but is deemed less important than updating
libjpeg-turbo.
With these patches, an update to libjpeg-turbo 2.1.1 should apply
cleanly and build.
Differential Revision: https://phabricator.services.mozilla.com/D125458
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
In practice we already only use SourceSurfaceSharedData as our
rasterized image backing. This means we no longer need to lock the data
to keep it in memory (when we used volatile memory), nor to try to
optimize the surface for the DrawTarget.
Differential Revision: https://phabricator.services.mozilla.com/D124476
This commit merely adds a test to validate the fix which occurs in the
mp4parse-rust code updated in the previous commit.
Differential Revision: https://phabricator.services.mozilla.com/D123991
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
This will allow experimenting with different representations of
the spatial tree (such as interning and/or providing stable
indices during display list building). It may also simplify
future changes to the public API to expose the spatial tree
directly.
As part of these changes, refactor how the debug representation
for the capture format is (de)serialized, to make it simpler to
add different payload vector types in future.
Differential Revision: https://phabricator.services.mozilla.com/D122183
Update mp4parse_capi API to receive pixi data from parser
There are some necessary changes in nsAVIFDecoder.cpp to accommodate the mp4parse_capi changes. Aside from the addition of `BitsPerChannelToBitDepth`, to facilitate a bit of logging, there should be no functional changes. This is a prerequisite to [[ https://bugzilla.mozilla.org/show_bug.cgi?id=1696045 | bug 1696045 ]], which will add telemetry around the `pixi` box.
Differential Revision: https://phabricator.services.mozilla.com/D123273
Supplying a visibility rect to the display list builder when recording
an SVG image blob will allow the display list builder to trim out
unnecessary items and make the recordings smaller. This is particularly
important when we have an SVG image used as an atlas.
This patch also simplifies the call path for the recordings. This allows
us to avoid unnecessary clips and transforms and shrink the recording
further, as well as make the code more auditable.
Differential Revision: https://phabricator.services.mozilla.com/D122125
This occurred due to a signature mismatch with
gfxUtils::DrawPixelSnapped. A previous patch in bug 1712855 put the
wrong field in the opacity parameter. It implicitly converted a bool to
a float silently, causing the opacity to be 0.0.
Differential Revision: https://phabricator.services.mozilla.com/D121628
It has been unsupported since bug 1323303, > 4 years ago.
This removes MOZ_ENABLE_SKIA but keeps USE_SKIA for moz2d for now
Differential Revision: https://phabricator.services.mozilla.com/D120933
This patch launches content processes with the `MOZ_HEADLESS` env var set
if they're using GTK with an X11 display (and there's no other reason
they'd need GTK).
The goal is to avoid exhausting Xorg's default limit of 256 clients if
there are many content processes due to Fission. If these conditions
are met, the content process doesn't need to eagerly connect to the X
server. This does not affect the sandbox policy, and content processes
can still use X if needed for, e.g., WebGL.
The boolean pref `dom.ipc.avoid-gtk`, set by default, controls this
feature. In the future it could also be extended to minimize GTK use
with Wayland displays.
Note that disabling `widget.non-native-theme.enabled`, which is also
enabled by default, will restore the use of X11 in all content processes
even if this pref is set; the alternative is that widgets wouldn't render
in that case.
This change will also save some memory for now-unnecessary instances of
GTK's global state, and improve content process startup time.
Remove also the temp pref dom.ipc.remote-mozIcon because it cannot work
anymore with the content process being headless.
Differential Revision: https://phabricator.services.mozilla.com/D112197
When we rasterized SVG images on the main thread of the content process,
we would call gfxUtils::DrawPixelSnapped with aUseOptimalFillOp set to
false. We should do the same when recording them.
Differential Revision: https://phabricator.services.mozilla.com/D116398
This patch allows animated SVG images to take advantage of blob
recordings like static SVG images. While before this patch, they would
use fallback blob recordings, this has the advantage of reusing the blob
key on an update. This helps avoid unnecessary scene rebuilds, as well
as reusing the same texture allocation for the rasterized blob.
Differential Revision: https://phabricator.services.mozilla.com/D111839
Bug 1712147 restricted JPEG-XL (controlled by preference image.jxl.enabled) to be only `true`
if MOZ_JXL is set and ifdef-ed the caller. This patch ifdef-s the function definition.
Differential Revision: https://phabricator.services.mozilla.com/D116100
This removes the check from static prefs, mainly since it's hard to check MOZ_JXL in JS side. It can be a bit confusing but generally shouldn't be harmful.
Differential Revision: https://phabricator.services.mozilla.com/D115704
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
Fix for ConvertYCbCrToRGB32 to use full range convert functions for full range data.
Some changes of libyuv are backported from newer version, to get support of full range BT.709 and BT.2020 colorspace.
Differential Revision: https://phabricator.services.mozilla.com/D105937
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
This creates a new leaf nsDisplayWrapper item for consumers that just want an empty wrapper, with a Paint method that asserts. This lets us leaves Paint pure-virtual on nsDisplayWrapList, and lets the compiler force us to implement it for the other leaf types.
It also disables flattening of transform/opacity items. This is because they flatten the items even when used with FlattenedDisplayItemIterator, even though this doesn't add markers to replace them (only FLB does this). We could in theory fix this, but I don't think FLB performance matters much any more.
Differential Revision: https://phabricator.services.mozilla.com/D114676
We don't support storing blob recordings in the surface cache at this
time so we should never look at it. It is possible that one may request
a blob recording, and have a previous rasterization available in the
cache because it was used in canvas or as a repeating background image.
We want to explicitly avoid the cache in that case.
Differential Revision: https://phabricator.services.mozilla.com/D115136
We don't support storing blob recordings in the surface cache at this
time so we should never look at it. It is possible that one may request
a blob recording, and have a previous rasterization available in the
cache because it was used in canvas or as a repeating background image.
We want to explicitly avoid the cache in that case.
Differential Revision: https://phabricator.services.mozilla.com/D115136
We don't support storing blob recordings in the surface cache at this
time so we should never look at it. It is possible that one may request
a blob recording, and have a previous rasterization available in the
cache because it was used in canvas or as a repeating background image.
We want to explicitly avoid the cache in that case.
Differential Revision: https://phabricator.services.mozilla.com/D115136
This patch hooks up the ImageIntRegion to the blob recording and makes
any necessary adjusts to the display list creation to take advantage of
it.
Differential Revision: https://phabricator.services.mozilla.com/D114986
This patch has no functional change beyond changing prototypes and
adding storage for ImageIntRegion for each ImageContainer.
Differential Revision: https://phabricator.services.mozilla.com/D114984
We want to use ImageRegion as one of the selection criteria to find a
valid ImageContainer for VectorImage. To avoid slightly different
floating point values causing us to recreate the recording, let's just
store it as integers.
Differential Revision: https://phabricator.services.mozilla.com/D114983
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
This should be mostly straight-forward, since we have code for this
anyways for image-set() and srcset.
The only thing is that we were using floats for resolution, but since
EXIF allows you to scale each axis separately, we now need to pass an
image::Resolution instead.
The main outstanding issue is the spec comment mentioned in the previous
patch, about what happens if you have srcset/image-set and the image
density specified together. For now I've implemented what the
image-set() spec says, but this is subject to change before shipping of
course.
Differential Revision: https://phabricator.services.mozilla.com/D113265
In some BMP files, data offset is set to 0 and in this case pixel data immediatly follow color table so don't fail in such a case.
Differential Revision: https://phabricator.services.mozilla.com/D113395
Moving mIsDrawing to SVGDocumentWrapper allows us to avoid depending on
VectorImage in a future patch, and instead only keep a reference to
SVGDocumentWrapper. This helps avoid a circular dependency.
Differential Revision: https://phabricator.services.mozilla.com/D111903
COM is required for calls to SHGetFileInfo for moz-icon, but we only currently
require that for the file content process. We may want to use it in the future
for the privileged about content process, in which case we will have to forgo
win32k lockdown there unless moz-icon is remoted.
Depends on D112960
Differential Revision: https://phabricator.services.mozilla.com/D112961
The assert in question is overly conservative. The dirty rects may be
calculated using a more conservative estimate of the whole frame, and
after the animation has completed its first pass, we may have determined
that it is unnecessarily too large and shrink it accordingly. There may
still be frames lingering with the old larger rect however, and trip
this assert falsely.
Differential Revision: https://phabricator.services.mozilla.com/D113155
This removes the code in Gecko that was only allowing opaque
compositor surfaces, now that the underlying work in WR and
SWGL to support these is complete.
Differential Revision: https://phabricator.services.mozilla.com/D112831
This makes us match Blink and WebKit on how to render an iframe whose src
attribute is an image URL. They seem to have always used 0 margin in this
case, and this seems preferable from an author's perspective (since the
standard HTML-body margin feels kind of arbitrary, when viewing an image).
Note that this change does also mean that images will be slightly closer to the
upper-left of the page, if they're viewed directly and then printed. This
shouldn't cause them to be clipped or cause other issues; they'll still be
offset from the page edge by the printed-page margins, as well as any
unprintable areas that we get from the printer.
Differential Revision: https://phabricator.services.mozilla.com/D110294
After applying D102448,
uriloader/exthandler/tests/mochitest/test_nullCharFile.xhtml starts to fail.
The reason is that it adds image sniffer into net-content-sniffers which is not
expected.
Such that, this patch
- adds two other sniffers category:
- orb-content-sniffers
- The sniffers that are needed in ORB.
- net-and-orb-content-sniffers
- The sniffers that are in either orb-content-sniffers or net-content-sniffers.
- changes the way to ensure we only use the sniffers in the
requested category.
Differential Revision: https://phabricator.services.mozilla.com/D107207
After applying D102448,
uriloader/exthandler/tests/mochitest/test_nullCharFile.xhtml starts to fail.
The reason is that it adds image sniffer into net-content-sniffers which is not
expected.
Such that, this patch
- adds two other sniffers category:
- orb-content-sniffers
- The sniffers that are needed in ORB.
- net-and-orb-content-sniffers
- The sniffers that are in either orb-content-sniffers or net-content-sniffers.
- changes the way to ensure we only use the sniffers in the
requested category.
Differential Revision: https://phabricator.services.mozilla.com/D107207
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
If GetAnimated fails when we're getting a static request, because e.g.
the image is not yet fully loaded, we still create a frozen image, but
in that case we can do better and avoid the WR fallback.
Depends on D108197
Differential Revision: https://phabricator.services.mozilla.com/D108198
Note that this patch only transforms the use of the nsDataHashtable type alias
to a directly equivalent use of nsTHashMap. It does not change the specification
of the hash key type to make use of the key class deduction that nsTHashMap
allows for in some cases. That can be done in a separate step, but requires more
attention.
Differential Revision: https://phabricator.services.mozilla.com/D106008
Well, mostly thread-safe, in the sense that on shutdown we might free
them, but that is pre-existing and can't happen for the code-path that
I'm about to touch.
We could probably just avoid freeing these transforms if we wanted...
Differential Revision: https://phabricator.services.mozilla.com/D104946
Well, mostly thread-safe, in the sense that on shutdown we might free
them, but that is pre-existing and can't happen for the code-path that
I'm about to touch.
We could probably just avoid freeing these transforms if we wanted...
Differential Revision: https://phabricator.services.mozilla.com/D104946
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
There are no code changes, only #include changes.
It was a fairly mechanical process: Search for all "AUTO_PROFILER_LABEL", and in each file, if only labels are used, convert "GeckoProfiler.h" into "ProfilerLabels.h" (or just add that last one where needed).
In some files, there were also some marker calls but no other profiler-related calls, in these cases "GeckoProfiler.h" was replaced with both "ProfilerLabels.h" and "ProfilerMarkers.h", which still helps in reducing the use of the all-encompassing "GeckoProfiler.h".
Differential Revision: https://phabricator.services.mozilla.com/D104588
CLOSED TREE
Backed out changeset f6519420f910 (bug 1678487)
Backed out changeset 9beae015d19b (bug 1678487)
Backed out changeset 029cc10d2477 (bug 1678487)
Well, mostly thread-safe, in the sense that on shutdown we might free
them, but that is pre-existing and can't happen for the code-path that I'm
about to touch.
We could probably just avoid freeing these transforms if we wanted...
Differential Revision: https://phabricator.services.mozilla.com/D104946
This new approach to weak references is roughly modeled after the approach used
by Rust's Arc<T>, and uses an atomic compare-and-swap loop to perform weak to
strong reference upgrades. This approach ends up moving the strong reference
count out of the tracked object and into the weak reference object, as the
strong reference count atomic needs to outlife the object itself.
Rust's Arc Weak::upgrade implementation:
d98d2f57d9/library/alloc/src/sync.rs (L1806-L1837)
Differential Revision: https://phabricator.services.mozilla.com/D102245
This new approach to weak references is roughly modeled after the approach used
by Rust's Arc<T>, and uses an atomic compare-and-swap loop to perform weak to
strong reference upgrades. This approach ends up moving the strong reference
count out of the tracked object and into the weak reference object, as the
strong reference count atomic needs to outlife the object itself.
Rust's Arc Weak::upgrade implementation:
d98d2f57d9/library/alloc/src/sync.rs (L1806-L1837)
Differential Revision: https://phabricator.services.mozilla.com/D102245
The only way that this can happen is if we get through the
ShouldTreatAsCompleteDueToSyncDecode check returning true in the case of
the image being errored.
https://hg.mozilla.org/integration/autoland/rev/645a4d6461ca was
supposed to deal with this, but my guess is that there is a slight race
condition in which the error status isn't there at the beginning, but is
there after the StartDecoding call.
It seems returning BAD_IMAGE rather than painting transparent if we hit
a broken image is a better thing to do than what we're doing now, and
should fix the intermittent issue.
Differential Revision: https://phabricator.services.mozilla.com/D101361
From what I can see in source history, pal8v4.bmp started out with a fuzzy of (3, 6376) on all platforms. Then one day aarch64-windows started producing a result of (1, 899) and so that platform's expectations were adjusted.
In the upcoming clang 12, the behavior of this test gets "fixed" in that we go back to those 6376 differing pixels like on other platforms. The max difference rises to 4 though. In light of the fact that aarch64-windows is seeing less priority these days, I can't justify digging into the exact code reason for the change, so this patch just updates the fuzzy setting to allow these values.
Differential Revision: https://phabricator.services.mozilla.com/D100823
This patch implements the transparency support for AVIF image files.
To convert the decoded YCbCr and Alpha data to RGBA, a function named
`ConvertYCbCrAToARGB` is created to do this job in the following
procedure:
ConvertYCbCrAToARGB:
If the layout of the YCbCr is I420
Calling libyuv::I420AlphaToARGB
Else
Fill RGB data converted by ConvertYCbCrToRGB in ARGB buffer first
Insert the alpha data to ARGB buffer
On the other hand, this patch refactors the nsAVIFDecoder a bit to make
the lifetime of the parsed data and decoded image data clearer. They
won't live longer than Parser object and {Dav1d, AOM}Decoder object.
This should improve the code readability.
This patch also adds a transparent image test (TransparentAVIFTestCase)
to check the FLAG_HAS_TRANSPARENCY is posted or not. The test image file
`transparent.avif` is from Bug 1654462.
Differential Revision: https://phabricator.services.mozilla.com/D98951
Import the improvements made in mp4parse-rust repo. The changes would
save some redundant copy when calling avif related APIs and provide the
ability to get the alpha data of the parsed avif image.
Differential Revision: https://phabricator.services.mozilla.com/D98950
Import the improvements made in mp4parse-rust repo. The changes would
save some redundant copy when calling avif related APIs and provide the
ability to get the alpha data of the parsed avif image.
Differential Revision: https://phabricator.services.mozilla.com/D98950
I was running into issues where these names would conflict with the type's own Get/Set methods
and these names have the added benefit of indicating a bit more that atomic stuff is going on.
Differential Revision: https://phabricator.services.mozilla.com/D99268
When loading a progressive jpegs with non-interleaved DC scans,
we add a check to see if we have already seen data from all DC
channels and only start rendering when this is the case.
Differential Revision: https://phabricator.services.mozilla.com/D95683
In https://hg.mozilla.org/integration/autoland/rev/471ad96ddc3e we changed this from calling |Surface().IsFullyDecoded()| to calling Seek because IsFullyDecoded always returns false for large enough animations because we don't keep around all of their frames.
In the old model, where mIsCurrentlyDecoded tracks if the image is fully decoded, we don't want to set mCompositedFrameInvalid to true if simply if the image isn't fully decoded because the current frame could be available.
In the new model, where mIsCurrentlyDecoded tracks if the current frame is available, we definitely do want to mark mCompositedFrameInvalid if the current frame is not available.
Depends on D96944
Differential Revision: https://phabricator.services.mozilla.com/D96945
In https://hg.mozilla.org/integration/autoland/rev/471ad96ddc3e we changed this from calling |Surface().IsFullyDecoded()| to calling Seek because IsFullyDecoded always returns false for large enough animations because we don't keep around all of their frames.
However RequestRefresh/AdvanceFrame call GetFrame. Seek is intended to be used for display purposes, GetFrame is intended to be used for advancing the frame purposes. And Seek and GetFrame can actually returns different results if it is the first frame that we are asking for.
Differential Revision: https://phabricator.services.mozilla.com/D96944
Andrew Osmond
Jon Bauman
Sandor Molnar
Jeff Muizelaar
Joel Maher
Gerald Squelart
Evgenia Kotovich
Noemi Erli
Emilio Cobos Alvarez
Alexandru Michis
Mike Hommey
Sean Feng
Kershaw Chang
Olli Pettay
Michelle Goossens
criss
Nika Layzell
Butkovits Atila
Chris Peterson
Matt Woodrow
Florian Quèze
Glenn Watson
Paul Zuehlcke
Ben Hearsum
Christoph Kerschbaumer
Tom Ritter
Timothy Nikkel
Jed Davis
Alexandre Lissy
Sebastian Hengst
Kris Wright
Kagami Sascha Rosylight
Yuan Tong
Csoregi Natalia
Dorel Luca
Andi-Bogdan Postelnicu
Iulian Moraru
Calixte Denizet
Valentin Gosu
Bob Owen
Daniel Holbert
Tom Tung
Simon Giesecke
Jeff Gilbert
Bogdan Tara
Markus Stange
Brindusan Cristian
Jonathan Kew
Jan de Mooij
Masatoshi Kimura
Narcis Beleuzu
David Major
Andi-Bogdan Postelnicu
Chun-Min Chang
Kartik Gautam
Alexis Beingessner
Moritz Firsching
Sylvestre Ledru
Razvan Maries