nsBMPEncoder produces either BMPv3 or BMPv5 files. (See the Version enum which
only has VERSION_3 and VERSION_5 values, and ParseOptions()'s handling of the
|version| parameter.
Nonetheless, there is some code to handle encoding of BMPv2 files. This patch
removes this.
nsICODecoder's reading and writing of little-endian values can be simplified
greatly.
Also, ReadBPP() was highly dodgy: BMP's bpp field is 16-bit
but ReadBPP() read it as if it's 32-bit. I think this currently works because
the bpp field is followed by the 32-bit compression field which is usually 0
for BMPs within ICOs!
- GetBitsPerPixel() and GetWidth() are no longer used.
- GetHeight() is now only used within nsBMPDecoder and can be renamed and
inlined into the header.
- GetImageData() can be inlined into the header.
The FileHeader and V5InfoHeader structs are shared by the BMP decoder and
encoder. But most of the fields within those structs are actually unused by the
decoder. It makes things clearer if we create a decoder-only struct that
contains the used fields, and then make FileHeader and V5InfoHeader only used
by the encoder. This patch does that.
This patch also renames BMPFileHeaders.h as BMPHeaders.h, which is now a better
name for it.
This patch implements proper color-scaling, instead of bit-shifting, and uses
it for 16bpp images.
It also cleans up the code relating to color masking in the process, by making
BitFields a proper class and introducing the Value class within it.
This fixes sub-optimal handling of four images in bmpsuite.
Two-space indents is the Gecko standard, and it's what nsBMPDecoder.cpp uses.
This patch changes nsBMPEncoder.h to use two-space indents as well. This will
help avoid possible mis-indentation if code is moved from the .h to the .cpp or
vice versa (as subsequent patches in this bug will do).
Also, it changes some of the // comments on public methods to doxygen-style ///
comments.
Also add crashtest with a corrupt animated PNG image that causes a leak to be reported (thanks to these MOZ_COUNT calls). This leak is fixed by the patch on separate bug 1237709.
We have 52 passes and 5 known fails. Three of the passes have higher fuzziness
allowances than they should, so really there are 8 files that we need to
improve on.
This patch is a major overhaul of nsBMPDecoder.
The patch improves the code in the following ways.
- It converts nsBMPDecoder to use StreamingLexer, which makes it much easier to
read.
- It adds a detailed comment about the BMP format at the top of
nsBMPDecoder.cpp.
- It fixes lots of inconsistent indenting.
- It moves |bihsize| from |mBFH| to |mBIH| to match the file format and common
sense. The avoids the need for the confusing LENGTH/INTERNAL_LENGTH
distinction.
- It renames most of the types in BMPFileHeader.h, so they have better names,
in StudlyCaps form, and within the new |bmp| namespace.
- It removes the BMP_HEADER_LENGTH struct and inlines its values directly into
the two places they were used.
- It removes the MOZ_LOG logging done on some of the failure cases. (Most
failure cases lacked logging so why bother with some?)
- It removes over 200 lines of code, despite the addition of the big format
comment.
The patch changes the way BMPs are decoded as follows.
- It adds stricter testing of the InfoHeader length, rejecting files with bad
values.
- It moves all header sanity checking that can lead to file rejection into the
metadata decode phase. (Previously, bpp/compression consistency checking did
not occur during a metadata decode.)
- It removes BMPINFOHEADER::ALPHABITFIELDS, which was (a) a weird WinCE-only
thing, and (b) we didn't actually allow it, and (c) we used the value 4
instead of 6(!).
- It rejects the previously-accepted compression==RLE4 && bpp=1 combination
because it doesn't make sense.
- It removes a fudge in RLE absolute mode handling that permitted one pixel too
many in a row but only if the row's width was odd(!)
- It now rejects a file with a negative gap between the color table and the
pixel data.
The patch leaves the following problems unaddressed.
- If bpp==32 we totally ignore compression==BITFIELDS and treat it like
compression=RGB.
- Transparency as specified in WinBMPv{4,5} isn't handled at all.
These will be fixed in follow-ups.
All these changes affect (for the better) the results of the following tests
that will be added in part 2:
- g/pal8v4.bmp
- g/pal8v5.bmp
- q/pal8os2sp.bmp
- q/pal8os2v2.bmp
- q/pal8os2v2-16.bmp
- b/badheadersize.bmp
- b/badpalettesize.bmp
- b/badrle.bmp
MakeUnique and its underlying |new| call will crash the program on
failure. This code was clearly written with fallible allocations in
mind, so let's make the allocations actually be fallible.
Currently we don't implement transparency at all in BMP images except for an
odd-duck case of BMPs within ICOs.
This patch does the following.
- It implements transparency properly for 16bpp and 32bpp images via bitfield
masking. (For 32bpp images this also requires handling colors via bitfield
masking.) The patch maintains the existing BMP-within-ICO transparency
handling.
- It also reworks BitFields::Value::Set().
* It now works correctly if the run of 1s goes all the way to bit 31 (the
old code didn't set mBitWidth).
* If the mask is 0, will give an mRightShift of 0 (old code gave 32, and
right-shifting by 32 is dodgy).
* It's now easier to read.
- It renames transparent.bmp as transparent-if-within-ico.bmp. Ironically
enough this file currently uses BITFIELDS compression and is WinBMPv5 format,
which means it contains well-specified alpha data. In order to use it to test
the hacky BMP-within-ICO transparency scheme the patch changes it to be
WinBMPv3 format with RGB compression (i.e. no compression). I left the
now-excess bytes (including the bitfields) in the info header in place
because that's allowed -- thanks to the start of the pixel data being
specified by the |dataoffset| field -- they'll just be ignored.
- It tweaks the naming of the relevant gtests and some of their finer details
to work with the new way of doing things.
This fixes all four remaining failures in bmpsuite.
Currently we don't read BMP bitfields during metadata decoding. But we'll need
to in order implement alpha, because we need to know during metadata decoding
if alpha is used.
This patch moves code around to achieve this (and adds the required
mMayHaveTransparency field). The change has no noticeable effect for now.
The conversion is as follows:
- GraphicsFilter::FILTER_NEAREST == gfx::Filter::POINT
- GraphicsFilter::FILTER_GOOD == gfx::Filter::GOOD
- GraphicsFilter::FILTER_BEST == gfx::Filter::LINEAR
Also typedef GraphicsFilter to gfx::Filter; this will be removed in the next
patch.
These changes mean ToFilter() and ThebesFilter() are no longer needed.
|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
|getReportsForThisProcess| differs from |getReports| in that it is limited to current process and is synchronous. When asynchronous memory reporters are added the function will no longer be able tobe synchronous. There isn't much utility in only measuring the current process, so we can remove the function and switch existing users to |getReports|.
Before the previous patch we would (wrongly) loop through the decoded frames even though we didn't have all of the frames of the animation. This had the beneficial side effect of advancing mCurrentAnimationFrameTime to aTime (the current time). With the previous patch we stop at the last decoded frame and don't advance mCurrentAnimationFrameTime, so it can lag behind. The problem with this is that when we have finished decoding we will then try to catch mCurrentAnimationFrameTime up, and this will jump us to a random point in the animation. So we need to advance mCurrentAnimationFrameTime ourselves.
If we were blocked on network/decoding then displaying the last available decoded frame is the correct frame to be displaying. So we are up to date. So we advance mCurrentAnimationFrameTime to the current time.
mImage->GetNumFrames() is the current number of decoded frames (that the RasterImage knows about), so it only represents the last frame of the animation if we are done decoding.
If we are not fully decoded, and we are on the last decoded frame, just stay on the last decoded frame. When more frames get decoded (or we determine that we are the last frame of the animation) we will advance.
One might expect that if |nextFrameIndex == mImage->GetNumFrames()| then |GetRawFrame(nextFrameIndex)| would return a null surface. But that is not the case because the decoding thread can insert frames into the surface cache that the RasterImage hasn't acknowledged yet (because it has to do so on the main thread, which we are currently running on).
This is why moving animated images to the surface cache is likely the cause of this bug.
This introduces an issue that is explained in, and fixed by the next patch.
http://hg.mozilla.org/mozilla-central/rev/411f18fdffeb (bug 1186796) had a mistake in it.
It changed ImageSurfaceCache::LookupBestMatch to use a for loop instead of using a callback to iterate each entry of the hashtable. The callback was called with the surface key of its entry, and it used the name |aSurfaceKey| for that key. ImageSurfaceCache::LookupBestMatch uses the name |aSurfaceKey| for the key we are looking for. So when the code from the callback was moved into the for loop in ImageSurfaceCache::LookupBestMatch the meaning of |aSurfaceKey| changed, but the code was not updated.
Various bits depend on RefPtr.h to provide RefCounted<T> and RefPtr<T>.
It will be easier to manage an automatic conversion from RefPtr<T> to
nsRefPtr<T> if we split out the dependency on RefCounted<T> first.
The wrinkle here is that while we can pass a UniquePtr to
ConvertHostARGBRow, we can't pass UniquePtr to
EncodeImageDataRow{24,32}, as the latter get called with raw pointers
out of our control.
These functions are only used in nsBMPDecoder.cpp; we don't need them
anywhere else. The only other place they might get used would be the
BMP encoder, but the encoder appears to have its own routines for
setting pixel data, which don't overlap very well with the decoder's.
This is straightforward mapping of PR_LOG levels to their LogLevel
counterparts:
PR_LOG_ERROR -> LogLevel::Error
PR_LOG_WARNING -> LogLevel::Warning
PR_LOG_WARN -> LogLevel::Warning
PR_LOG_INFO -> LogLevel::Info
PR_LOG_DEBUG -> LogLevel::Debug
PR_LOG_NOTICE -> LogLevel::Debug
PR_LOG_VERBOSE -> LogLevel::Verbose
Instances of PRLogModuleLevel were mapped to a fully qualified
mozilla::LogLevel, instances of PR_LOG levels in #defines were mapped to a
fully qualified mozilla::LogLevel::* level, and all other instances were
mapped to us a shorter format of LogLevel::*.
Bustage for usage of the non-fully qualified LogLevel were fixed by adding
|using mozilla::LogLevel;| where appropriate.
This conversion was done with the script:
find . -name '*.cpp' -o -name '*.h' -o -name '*.mm' -o -name '*.idl' | \
egrep -v 'cairo-win32-refptr.h|RefPtr.h|TestRefPtr.cpp' | \
xargs sed -i -e 's/mozilla::TemporaryRef</already_AddRefed</g' \
-e 's/TemporaryRef</already_AddRefed</g'
Manual fixups were performed in the following instances:
- We handled mfbt/RefPtr.h manually so as to not convert TemporaryRef itself
into already_AddRefed.
- The following files had explicit Move() calls added to make up for the lack
of a copy constructor on already_AddRefed:
dom/base/ImageEncoder.cpp
dom/media/MediaTaskQueue.{h,cpp}
dom/media/webaudio/PannerNode.cpp
- A redundant overload for MediaTaskQueue::Dispatch was deleted.
- A few manual fixups were required in mfbt/tests/TestRefPtr.cpp.
- Comments, using declarations, and forward declarations relating to
TemporaryRef in dom/canvas/ and gfx/layers/ were changed to refer to
already_AddRefed.
