The imgLoader code consistently uses the term `loadingPrincipal` for
the principal that is called the `triggeringPrincipal` everywhere else.
This aligns the naming to avoid confusion in later changes.
We're currently fairly vague and inconsistent about the values we provide to
content policy implementations for requestOrigin and requestPrincipal. In some
cases they're the triggering principal, sometimes the loading principal,
sometimes the channel principal.
Our existing content policy implementations which require or expect a
loading principal currently retrieve it from the context node.
Since no current callers require the principal to be the loading
principal, and some already expect it to be the triggering principal
(which there's currently no other way to retrieve), a choice was made
to pass the triggering principal whenever possible, but use the loading
principal to determine the origin URL.
Per Issue #2033 we don't support expanding RGB to RGBA yet, so this opacity
check will always return RGBX, which makes images with transparent backgrounds
show up with a black background instead. Feel free to readd once we backport
Mozilla bug 1551088.
Based on Mozilla phab D122159, intended for bug 1709815.
Also moved the temporary RGBA and premultiplication fixes to a macro, since
progressive decoding also needs these fixes.
We have a BGR/RGB channel ordering mismatch here. to at least
provide proper display, a quick&dirty byte swap on the output
buffer will fix this for now, but we should look into seeing where
the surface mismatch is caused.
std::swap() should optimize pretty well in any of the used
compilers, but if necessary, a full buffer ASM routine can be
slotted in (although on current hardware I doubt this will be
even noticeable as it is)
The mp4parse Rust component has been removed in Issue #58. It doesn't seem
like the decoder uses any mp4parse function, so seems like it's safe to
remove it.
Removed const DecoderType named GetType() because we don't have it in our
Decoder.h.
I've decided to abandon the OS_RGBA backporting effort and instead went for
using OS_RGBA's value which is R8G8B8A8. Turns out that there is much more
going on in Mozilla's version of CreateSurfacePipe than I've expected, like
the aInFormat and aOutFormat thing which I really don't want to delve into
right now. Looking at the code it looks like all JPEG-XL images are expected
to have an alpha channel anyway, so I think my workaround should be safe.
I also removed the dependency in OrientedIntSize and used Size() from gfx/2d/
Point.h like our PNG and GIF decoders currently do. Migrating our decoders
to OrientedInt types should be done in another PR instead.
Also also changed the coding style to be closer to UXP's.
Also also also, I made a mistake in Part 1's commit message; the commit used
for libjxl is 192ddd90fdf0c69cd1db1c8d7850db036dd87f4b.
Vim control lines were re-introduced or not entirely cleaned up.
This nukes them again.
Removing from the rest of js, caps, chrome, config, devtools, docshell,
image, intl. More to come.
The first part also means that Compact no longer needs the SurfaceCache lock (used to be via CreateChunk->CanHold),
which avoids potential deadlocks during shutdown that m-c 523950 would otherwise cause
Controlled by image.animated.decode-on-demand.threshold-kb, default 256MB
Includes squashed bugfixes/regressions:
- m-c 1444537: Shutting down the decode pool should make animated decoders bail early
- m-c 1628606: Make sure to mark the surface cache entry available before sending the frame complete notification
- m-c 1502275: Skip recreating the decoder after redecode errors if an animated image is reset
- m-c 1443232: Don't insert frames into our AnimationFrameBuffer that we consider in error and unusable
Includes squashed changes of:
- m-c 1317907: Refactor FrameAnimator::GetCompositedFrame to be a bit simpler
- m-c 1351434: bugfix
- m-c 686905: Enable the pref image.mem.animated.discardable to allow discarding of animated images
