This patch introduces TerminalState and changes LexerTransition::mNextState to
be a Variant<State, TerminalState>. This means that SUCCESS and FAILURE no
longer need to be part of State.
Some things to note:
- This simplifies the handling of Lex()'s return value, which is nice.
- The patch splits Terminate() into TerminateSuccess() and TerminateFailure().
- |const State& aNextState| wouldn't work for the first arg to
LexerTransition's ctor due to errors in Variant construction that I didn't
understand. I had to change it to |State aNextState|.
gfxRect can be implicitly constructed from IntRect, which hides a number of
implicit conversion points, makes Moz2Dification harder, and has some
surprising effects.
This patch removes the implicit constructor and replaces it with an explicit
conversion function:
gfxRect ThebesRect(const IntRect&)
This is the obvious outcome of removing the constructor.
But there is also a second, less obvious outcome: currently we do a number of
IntRect-to-Rect conversions using ToRect(), which (surprisingly) works because
it turns into an implicit IntRect-to-gfxRect conversion (via the implicit
constructor) combined with an explicit gfxRect-to-Rect conversion (via
ToRect()). I.e. we do two conversions, going from a Moz2D type to a Thebes
type and back to a Moz2D type!
So this patch also changes these conversion. It moves this existing function:
Rect ToRect(const IntRect&)
from gfx2DGlue.h -- where it doesn't really belong because it doesn't involve
any Thebes types -- to gfx/2d/Rect.h, templatifying and renaming it as
IntRectToRect() in the process.
The rest of the patch deals with fall-out from these changes. The call sites
change as follows:
- IntRect-to-gfxRect conversions:
- old: implicit
- new: ThebesRect()
- IntRect-to-Rect conversions:
- old: ToRect()
- new: IntRectToRect()
This ID will be null for non-controlled documents and also for image cache
entries for which a document is not available, and it will be the numerical
value of the document pointer for controlled documents.
This effectively makes sure that a controlled document doesn't share its
image cache entries with anything else.
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.
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 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.
mTouchedTime is not appropriate for this as it is updated when an image
load re-uses the same imgRequest, especially as it has one second
granularity. A timestamp that is updated every time the backing file is
re-read should work better.
A millisecond granularity timestamp would be preferable, and would be
achievable on most or all supported platforms. But some older
filesystems have timestamp granularity of a second or worse, notably
ext3 and FAT32 (and even ext4 filesytems created with inode_size < 256
bytes, e.g. with 'mke2fs -t small' - see
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps
for details.)
