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|.
--HG--
extra : rebase_source : f405a67fdf0f1bb712409eafecb21ac9b59d6db0
This fixes failures for
image/test/reftest/bmp/bmpsuite/b/{badrle.bmp,shortfile.bmp} with the Skia
back-end.
--HG--
extra : rebase_source : 6c5b967cebf43cf5d49d0e532619bdd1c8ccc69e
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()
--HG--
extra : rebase_source : e4e4c2ad10b36ecad4d57d1630158f3374e403be
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.
--HG--
extra : rebase_source : eaa1ddd801872c14860e3bd81645bc99d56d8e4b
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!
--HG--
extra : rebase_source : 5fd43dedc036dca5bc2ff79b029855dc76d62515
- 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.
--HG--
extra : rebase_source : f902f7ce6513e54eaa7fe6210b4ff3ff6865c4bf
This requires delaying the creation of the BMP decoder used by the ICO decoder.
--HG--
extra : rebase_source : 629a2ac387a9c8ee1a520c70733adb10cc156aa8
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
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.
--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
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.
Mason Chang
sajitk
David Anderson
Nicholas Nethercote
Phil Ringnalda
Nathan Froyd
Sotaro Ikeda
Ryan VanderMeulen
Timothy Nikkel
Ehsan Akhgari
Seth Fowler
Birunthan Mohanathas
Seth Fowler