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
