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.
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
Since these are just interpreted comments, there's 0 impact on actual code.
This removes all lines that match /* vim: set(.*)tw=80: */ with S&R -- there are
a few others scattered around which will be removed manually in a second part.
In the original Windows clipboard BMP decoder implementation in
nsImageFromClipboard::ConvertColorBitMap, if the bitmap used bitfields
compression, it always adjusted the offset to the RGB data by 12 bytes.
It did this even for newer BMP header formats which explicitly include
space for the bitfields in their header sizes. This patch updates our
BMP decoder to do the same for clipboard BMPs, since we have observed
pasted BMPs using bitfield compression appearing incorrectly. To the
user this appears as if we read a color mask; completely red, blue,
green pixels at the start of the last row, causing all of the other rows
to start with the last three pixels of the previous row.
When we are reading large image data (i.e.: people using webp to stream
video instead of the native webm format; I'm looking at you, Giphy!)
we can run into the situation where the available data is not in a
contiguous buffer, and we need to either buffer additional data or
re-buffer from the start. If we don't do this, we can run into issues
because of buffer over-reading (causing corrupted data if allocated or
more likely crashes if not allocated).
Re-buffering is expensive, but this should be rare and limited to
dealing with unintended use for animated image formats.
This resolves#940.
