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.
--HG--
rename : image/BMPFileHeaders.h => image/BMPHeaders.h
extra : rebase_source : 2227679b8aef25e48d3e8e7d38a3ba79a57c40d3
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.
--HG--
rename : image/test/gtest/transparent.bmp => image/test/gtest/transparent-if-within-ico.bmp
extra : rebase_source : 2f4838d04bbae4fac00cc69e8d75469105a5de3b
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.
--HG--
extra : rebase_source : 32106149bf064f0e44ec9dcf8f013612dceacbb7
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.
The bulk of this commit was generated with a script, executed at the top
level of a typical source code checkout. The only non-machine-generated
part was modifying MFBT's moz.build to reflect the new naming.
CLOSED TREE makes big refactorings like this a piece of cake.
# The main substitution.
find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \
xargs perl -p -i -e '
s/nsRefPtr\.h/RefPtr\.h/g; # handle includes
s/nsRefPtr ?</RefPtr</g; # handle declarations and variables
'
# Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h.
perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h
# Handle nsRefPtr.h itself, a couple places that define constructors
# from nsRefPtr, and code generators specially. We do this here, rather
# than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename
# things like nsRefPtrHashtable.
perl -p -i -e 's/nsRefPtr/RefPtr/g' \
mfbt/nsRefPtr.h \
xpcom/glue/nsCOMPtr.h \
xpcom/base/OwningNonNull.h \
ipc/ipdl/ipdl/lower.py \
ipc/ipdl/ipdl/builtin.py \
dom/bindings/Codegen.py \
python/lldbutils/lldbutils/utils.py
# In our indiscriminate substitution above, we renamed
# nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up.
find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \
xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g'
if [ -d .git ]; then
git mv mfbt/nsRefPtr.h mfbt/RefPtr.h
else
hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h
fi
--HG--
rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
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.
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
--HG--
extra : rebase_source : 8ddc2f5fccce6998348097ff9f0a1072d273cdf4
The patch removes 455 occurrences of FAIL_ON_WARNINGS from moz.build files, and
adds 78 instances of ALLOW_COMPILER_WARNINGS. About half of those 78 are in
code we control and which should be removable with a little effort.
--HG--
extra : rebase_source : 82e3387abfbd5f1471e953961d301d3d97ed2973
