gecko-dev/image/decoders/nsBMPDecoder.cpp

1014 строки
31 KiB
C++
Исходник Обычный вид История

Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// This is a cross-platform BMP Decoder, which should work everywhere,
// including big-endian machines like the PowerPC.
//
// BMP is a format that has been extended multiple times. To understand the
// decoder you need to understand this history. The summary of the history
// below was determined from the following documents.
//
// - http://www.fileformat.info/format/bmp/egff.htm
// - http://www.fileformat.info/format/os2bmp/egff.htm
// - http://fileformats.archiveteam.org/wiki/BMP
// - http://fileformats.archiveteam.org/wiki/OS/2_BMP
// - https://en.wikipedia.org/wiki/BMP_file_format
// - https://upload.wikimedia.org/wikipedia/commons/c/c4/BMPfileFormat.png
//
// WINDOWS VERSIONS OF THE BMP FORMAT
// ----------------------------------
// WinBMPv1.
// - This version is no longer used and can be ignored.
//
// WinBMPv2.
// - First is a 14 byte file header that includes: the magic number ("BM"),
// file size, and offset to the pixel data (|mDataOffset|).
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// - Next is a 12 byte info header which includes: the info header size
// (mBIHSize), width, height, number of color planes, and bits-per-pixel
// (|mBpp|) which must be 1, 4, 8 or 24.
// - Next is the semi-optional color table, which has length 2^|mBpp| and has 3
// bytes per value (BGR). The color table is required if |mBpp| is 1, 4, or 8.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// - Next is an optional gap.
// - Next is the pixel data, which is pointed to by |mDataOffset|.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
//
// WinBMPv3. This is the most widely used version.
// - It changed the info header to 40 bytes by taking the WinBMPv2 info
// header, enlargening its width and height fields, and adding more fields
// including: a compression type (|mCompression|) and number of colors
// (|mNumColors|).
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// - The semi-optional color table is now 4 bytes per value (BGR0), and its
// length is |mNumColors|, or 2^|mBpp| if |mNumColors| is zero.
// - |mCompression| can be RGB (i.e. no compression), RLE4 (if |mBpp|==4) or
// RLE8 (if |mBpp|==8) values.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
//
// WinBMPv3-NT. A variant of WinBMPv3.
// - It did not change the info header layout from WinBMPv3.
// - |mBpp| can now be 16 or 32, in which case |mCompression| can be RGB or the
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// new BITFIELDS value; in the latter case an additional 12 bytes of color
// bitfields follow the info header.
//
// WinBMPv4.
// - It extended the info header to 108 bytes, including the 12 bytes of color
// mask data from WinBMPv3-NT, plus alpha mask data, and also color-space and
// gamma correction fields.
//
// WinBMPv5.
// - It extended the info header to 124 bytes, adding color profile data.
// - It also added an optional color profile table after the pixel data (and
// another optional gap).
//
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
// WinBMPv3-ICO. This is a variant of WinBMPv3.
// - It's the BMP format used for BMP images within ICO files.
// - The only difference with WinBMPv3 is that if an image is 32bpp and has no
// compression, then instead of treating the pixel data as 0RGB it is treated
// as ARGB, but only if one or more of the A values are non-zero.
//
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// OS/2 VERSIONS OF THE BMP FORMAT
// -------------------------------
// OS2-BMPv1.
// - Almost identical to WinBMPv2; the differences are basically ignorable.
//
// OS2-BMPv2.
// - Similar to WinBMPv3.
// - The info header is 64 bytes but can be reduced to as little as 16; any
// omitted fields are treated as zero. The first 40 bytes of these fields are
// nearly identical to the WinBMPv3 info header; the remaining 24 bytes are
// different.
// - Also adds compression types "Huffman 1D" and "RLE24", which we don't
// support.
// - We treat OS2-BMPv2 files as if they are WinBMPv3 (i.e. ignore the extra 24
// bytes in the info header), which in practice is good enough.
#include <stdlib.h>
#include "ImageLogging.h"
#include "mozilla/Attributes.h"
#include "mozilla/Endian.h"
#include "mozilla/Likely.h"
#include "nsBMPDecoder.h"
#include "nsIInputStream.h"
#include "RasterImage.h"
#include <algorithm>
using namespace mozilla::gfx;
namespace mozilla {
namespace image {
namespace bmp {
struct Compression {
enum {
RGB = 0,
RLE8 = 1,
RLE4 = 2,
BITFIELDS = 3
};
};
// RLE escape codes and constants.
struct RLE {
enum {
ESCAPE = 0,
ESCAPE_EOL = 0,
ESCAPE_EOF = 1,
ESCAPE_DELTA = 2,
SEGMENT_LENGTH = 2,
DELTA_LENGTH = 2
};
};
} // namespace bmp
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
using namespace bmp;
/// Sets the pixel data in aDecoded to the given values.
/// @param aDecoded pointer to pixel to be set, will be incremented to point to
/// the next pixel.
static void
SetPixel(uint32_t*& aDecoded, uint8_t aRed, uint8_t aGreen,
uint8_t aBlue, uint8_t aAlpha = 0xFF)
{
*aDecoded++ = gfxPackedPixel(aAlpha, aRed, aGreen, aBlue);
}
static void
SetPixel(uint32_t*& aDecoded, uint8_t idx,
const UniquePtr<ColorTableEntry[]>& aColors)
{
SetPixel(aDecoded,
aColors[idx].mRed, aColors[idx].mGreen, aColors[idx].mBlue);
}
/// Sets two (or one if aCount = 1) pixels
/// @param aDecoded where the data is stored. Will be moved 4 resp 8 bytes
/// depending on whether one or two pixels are written.
/// @param aData The values for the two pixels
/// @param aCount Current count. Is decremented by one or two.
static void
Set4BitPixel(uint32_t*& aDecoded, uint8_t aData, uint32_t& aCount,
const UniquePtr<ColorTableEntry[]>& aColors)
{
uint8_t idx = aData >> 4;
SetPixel(aDecoded, idx, aColors);
if (--aCount > 0) {
idx = aData & 0xF;
SetPixel(aDecoded, idx, aColors);
--aCount;
}
}
static PRLogModuleInfo*
GetBMPLog()
{
static PRLogModuleInfo* sBMPLog;
if (!sBMPLog) {
sBMPLog = PR_NewLogModule("BMPDecoder");
}
return sBMPLog;
}
nsBMPDecoder::nsBMPDecoder(RasterImage* aImage)
: Decoder(aImage)
, mLexer(Transition::To(State::FILE_HEADER, FILE_HEADER_LENGTH))
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
, mIsWithinICO(false)
, mMayHaveTransparency(false)
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
, mDoesHaveTransparency(false)
, mNumColors(0)
, mColors(nullptr)
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
, mBytesPerColor(0)
, mPreGapLength(0)
, mCurrentRow(0)
, mCurrentPos(0)
, mAbsoluteModeNumPixels(0)
{
}
nsBMPDecoder::~nsBMPDecoder()
{
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Obtains the bits per pixel from the internal BIH header.
int32_t
nsBMPDecoder::GetBitsPerPixel() const
{
return mH.mBpp;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Obtains the width from the internal BIH header.
int32_t
nsBMPDecoder::GetWidth() const
{
return mH.mWidth;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Obtains the absolute value of the height from the internal BIH header.
// If it's positive the bitmap is stored bottom to top, otherwise top to bottom.
int32_t
nsBMPDecoder::GetHeight() const
{
return abs(mH.mHeight);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Obtains the internal output image buffer.
uint32_t*
nsBMPDecoder::GetImageData()
{
return reinterpret_cast<uint32_t*>(mImageData);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Obtains the size of the compressed image resource.
int32_t
nsBMPDecoder::GetCompressedImageSize() const
{
// In the RGB case mImageSize might not be set, so compute it manually.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
MOZ_ASSERT(mPixelRowSize != 0);
return mH.mCompression == Compression::RGB
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
? mPixelRowSize * GetHeight()
: mH.mImageSize;
}
void
nsBMPDecoder::FinishInternal()
{
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// We shouldn't be called in error cases.
MOZ_ASSERT(!HasError(), "Can't call FinishInternal on error!");
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// We should never make multiple frames.
MOZ_ASSERT(GetFrameCount() <= 1, "Multiple BMP frames?");
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Send notifications if appropriate.
if (!IsMetadataDecode() && HasSize()) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Invalidate.
nsIntRect r(0, 0, mH.mWidth, GetHeight());
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
PostInvalidation(r);
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
if (mDoesHaveTransparency) {
MOZ_ASSERT(mMayHaveTransparency);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
PostFrameStop(Opacity::SOME_TRANSPARENCY);
} else {
PostFrameStop(Opacity::OPAQUE);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
PostDecodeDone();
}
}
// ----------------------------------------
// Actual Data Processing
// ----------------------------------------
void
BitFields::Value::Set(uint32_t aMask)
{
mMask = aMask;
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
// Handle this exceptional case first. The chosen values don't matter
// (because a mask of zero will always give a value of zero) except that
// mBitWidth:
// - shouldn't be zero, because that would cause an infinite loop in Get();
// - shouldn't be 5 or 8, because that could cause a false positive match in
// IsR5G5B5() or IsR8G8B8().
if (mMask == 0x0) {
mRightShift = 0;
mBitWidth = 1;
return;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Find the rightmost 1.
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
uint8_t i;
for (i = 0; i < 32; i++) {
if (mMask & (1 << i)) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
break;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
mRightShift = i;
// Now find the leftmost 1 in the same run of 1s. (If there are multiple runs
// of 1s -- which isn't valid -- we'll behave as if only the lowest run was
// present, which seems reasonable.)
for (i = i + 1; i < 32; i++) {
if (!(mMask & (1 << i))) {
break;
}
}
mBitWidth = i - mRightShift;
}
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
MOZ_ALWAYS_INLINE uint8_t
BitFields::Value::Get(uint32_t aValue) const
{
// Extract the unscaled value.
uint32_t v = (aValue & mMask) >> mRightShift;
// Idea: to upscale v precisely we need to duplicate its bits, possibly
// repeatedly, possibly partially in the last case, from bit 7 down to bit 0
// in v2. For example:
//
// - mBitWidth=1: v2 = v<<7 | v<<6 | ... | v<<1 | v>>0 k -> kkkkkkkk
// - mBitWidth=2: v2 = v<<6 | v<<4 | v<<2 | v>>0 jk -> jkjkjkjk
// - mBitWidth=3: v2 = v<<5 | v<<2 | v>>1 ijk -> ijkijkij
// - mBitWidth=4: v2 = v<<4 | v>>0 hijk -> hijkhijk
// - mBitWidth=5: v2 = v<<3 | v>>2 ghijk -> ghijkghi
// - mBitWidth=6: v2 = v<<2 | v>>4 fghijk -> fghijkfg
// - mBitWidth=7: v2 = v<<1 | v>>6 efghijk -> efghijke
// - mBitWidth=8: v2 = v>>0 defghijk -> defghijk
// - mBitWidth=9: v2 = v>>1 cdefghijk -> cdefghij
// - mBitWidth=10: v2 = v>>2 bcdefghijk -> bcdefghi
// - mBitWidth=11: v2 = v>>3 abcdefghijk -> abcdefgh
// - etc.
//
uint8_t v2 = 0;
int32_t i; // must be a signed integer
for (i = 8 - mBitWidth; i > 0; i -= mBitWidth) {
v2 |= v << uint32_t(i);
}
v2 |= v >> uint32_t(-i);
return v2;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
MOZ_ALWAYS_INLINE uint8_t
BitFields::Value::GetAlpha(uint32_t aValue, bool& aHasAlphaOut) const
{
if (mMask == 0x0) {
return 0xff;
}
aHasAlphaOut = true;
return Get(aValue);
}
MOZ_ALWAYS_INLINE uint8_t
BitFields::Value::Get5(uint32_t aValue) const
{
MOZ_ASSERT(mBitWidth == 5);
uint32_t v = (aValue & mMask) >> mRightShift;
return (v << 3u) | (v >> 2u);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
MOZ_ALWAYS_INLINE uint8_t
BitFields::Value::Get8(uint32_t aValue) const
{
MOZ_ASSERT(mBitWidth == 8);
uint32_t v = (aValue & mMask) >> mRightShift;
return v;
}
void
BitFields::SetR5G5B5()
{
mRed.Set(0x7c00);
mGreen.Set(0x03e0);
mBlue.Set(0x001f);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
void
BitFields::SetR8G8B8()
{
mRed.Set(0xff0000);
mGreen.Set(0xff00);
mBlue.Set(0x00ff);
}
bool
BitFields::IsR5G5B5() const
{
return mRed.mBitWidth == 5 &&
mGreen.mBitWidth == 5 &&
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
mBlue.mBitWidth == 5 &&
mAlpha.mMask == 0x0;
}
bool
BitFields::IsR8G8B8() const
{
return mRed.mBitWidth == 8 &&
mGreen.mBitWidth == 8 &&
mBlue.mBitWidth == 8 &&
mAlpha.mMask == 0x0;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
uint32_t*
nsBMPDecoder::RowBuffer()
{
if (mDownscaler) {
return reinterpret_cast<uint32_t*>(mDownscaler->RowBuffer()) + mCurrentPos;
}
// Convert from row (1..mHeight) to absolute line (0..mHeight-1).
int32_t line = (mH.mHeight < 0)
? -mH.mHeight - mCurrentRow
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
: mCurrentRow - 1;
int32_t offset = line * mH.mWidth + mCurrentPos;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
return reinterpret_cast<uint32_t*>(mImageData) + offset;
}
void
nsBMPDecoder::FinishRow()
{
if (mDownscaler) {
mDownscaler->CommitRow();
if (mDownscaler->HasInvalidation()) {
DownscalerInvalidRect invalidRect = mDownscaler->TakeInvalidRect();
PostInvalidation(invalidRect.mOriginalSizeRect,
Some(invalidRect.mTargetSizeRect));
}
} else {
PostInvalidation(IntRect(0, mCurrentRow, mH.mWidth, 1));
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
mCurrentRow--;
}
void
nsBMPDecoder::WriteInternal(const char* aBuffer, uint32_t aCount)
{
MOZ_ASSERT(!HasError(), "Shouldn't call WriteInternal after error!");
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
MOZ_ASSERT(aBuffer);
MOZ_ASSERT(aCount > 0);
Maybe<State> terminalState =
mLexer.Lex(aBuffer, aCount, [=](State aState,
const char* aData, size_t aLength) {
switch (aState) {
case State::FILE_HEADER: return ReadFileHeader(aData, aLength);
case State::INFO_HEADER_SIZE: return ReadInfoHeaderSize(aData, aLength);
case State::INFO_HEADER_REST: return ReadInfoHeaderRest(aData, aLength);
case State::BITFIELDS: return ReadBitfields(aData, aLength);
case State::COLOR_TABLE: return ReadColorTable(aData, aLength);
case State::GAP: return SkipGap();
case State::PIXEL_ROW: return ReadPixelRow(aData);
case State::RLE_SEGMENT: return ReadRLESegment(aData);
case State::RLE_DELTA: return ReadRLEDelta(aData);
case State::RLE_ABSOLUTE: return ReadRLEAbsolute(aData, aLength);
default:
MOZ_ASSERT_UNREACHABLE("Unknown State");
return Transition::Terminate(State::FAILURE);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
});
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (!terminalState) {
return; // Need more data.
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (*terminalState == State::FAILURE) {
PostDataError();
return;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
MOZ_ASSERT(*terminalState == State::SUCCESS);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
return;
}
// The length of the mBIHSize field in the info header.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
static const uint32_t BIHSIZE_FIELD_LENGTH = 4;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadFileHeader(const char* aData, size_t aLength)
{
mPreGapLength += aLength;
bool signatureOk = aData[0] == 'B' && aData[1] == 'M';
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (!signatureOk) {
PostDataError();
return Transition::Terminate(State::FAILURE);
}
// We ignore the filesize (aData + 2) and reserved (aData + 6) fields.
mH.mDataOffset = LittleEndian::readUint32(aData + 10);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
return Transition::To(State::INFO_HEADER_SIZE, BIHSIZE_FIELD_LENGTH);
}
// We read the info header in two steps: (a) read the mBIHSize field to
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// determine how long the header is; (b) read the rest of the header.
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadInfoHeaderSize(const char* aData, size_t aLength)
{
mPreGapLength += aLength;
mH.mBIHSize = LittleEndian::readUint32(aData);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
bool bihSizeOk = mH.mBIHSize == InfoHeaderLength::WIN_V2 ||
mH.mBIHSize == InfoHeaderLength::WIN_V3 ||
mH.mBIHSize == InfoHeaderLength::WIN_V4 ||
mH.mBIHSize == InfoHeaderLength::WIN_V5 ||
(mH.mBIHSize >= InfoHeaderLength::OS2_V2_MIN &&
mH.mBIHSize <= InfoHeaderLength::OS2_V2_MAX);
if (!bihSizeOk) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
PostDataError();
return Transition::Terminate(State::FAILURE);
}
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
// ICO BMPs must have a WinVMPv3 header. nsICODecoder should have already
// terminated decoding if this isn't the case.
MOZ_ASSERT_IF(mIsWithinICO, mH.mBIHSize == InfoHeaderLength::WIN_V3);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
return Transition::To(State::INFO_HEADER_REST,
mH.mBIHSize - BIHSIZE_FIELD_LENGTH);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadInfoHeaderRest(const char* aData, size_t aLength)
{
mPreGapLength += aLength;
// |mWidth| and |mHeight| may be signed (Windows) or unsigned (OS/2). We just
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// read as unsigned because in practice that's good enough.
if (mH.mBIHSize == InfoHeaderLength::WIN_V2) {
mH.mWidth = LittleEndian::readUint16(aData + 0);
mH.mHeight = LittleEndian::readUint16(aData + 2);
// We ignore the planes (aData + 4) field; it should always be 1.
mH.mBpp = LittleEndian::readUint16(aData + 6);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
} else {
mH.mWidth = LittleEndian::readUint32(aData + 0);
mH.mHeight = LittleEndian::readUint32(aData + 4);
// We ignore the planes (aData + 4) field; it should always be 1.
mH.mBpp = LittleEndian::readUint16(aData + 10);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// For OS2-BMPv2 the info header may be as little as 16 bytes, so be
// careful for these fields.
mH.mCompression = aLength >= 16 ? LittleEndian::readUint32(aData + 12) : 0;
mH.mImageSize = aLength >= 20 ? LittleEndian::readUint32(aData + 16) : 0;
// We ignore the xppm (aData + 20) and yppm (aData + 24) fields.
mH.mNumColors = aLength >= 32 ? LittleEndian::readUint32(aData + 28) : 0;
// We ignore the important_colors (aData + 36) field.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// For WinBMPv4, WinBMPv5 and (possibly) OS2-BMPv2 there are additional
// fields in the info header which we ignore, with the possible exception
// of the color bitfields (see below).
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Run with NSPR_LOG_MODULES=BMPDecoder:4 set to see this output.
MOZ_LOG(GetBMPLog(), LogLevel::Debug,
("BMP: bihsize=%u, %d x %d, bpp=%u, compression=%u, colors=%u\n",
mH.mBIHSize, mH.mWidth, mH.mHeight, uint32_t(mH.mBpp),
mH.mCompression, mH.mNumColors));
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// BMPs with negative width are invalid. Also, reject extremely wide images
// to keep the math sane. And reject INT_MIN as a height because you can't
// get its absolute value (because -INT_MIN is one more than INT_MAX).
const int32_t k64KWidth = 0x0000FFFF;
bool sizeOk = 0 <= mH.mWidth && mH.mWidth <= k64KWidth &&
mH.mHeight != INT_MIN;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (!sizeOk) {
PostDataError();
return Transition::Terminate(State::FAILURE);
}
// Check mBpp and mCompression.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
bool bppCompressionOk =
(mH.mCompression == Compression::RGB &&
(mH.mBpp == 1 || mH.mBpp == 4 || mH.mBpp == 8 ||
mH.mBpp == 16 || mH.mBpp == 24 || mH.mBpp == 32)) ||
(mH.mCompression == Compression::RLE8 && mH.mBpp == 8) ||
(mH.mCompression == Compression::RLE4 && mH.mBpp == 4) ||
(mH.mCompression == Compression::BITFIELDS &&
(mH.mBpp == 16 || mH.mBpp == 32));
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (!bppCompressionOk) {
PostDataError();
return Transition::Terminate(State::FAILURE);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Post our size to the superclass.
uint32_t realHeight = GetHeight();
PostSize(mH.mWidth, realHeight);
mCurrentRow = realHeight;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Round it up to the nearest byte count, then pad to 4-byte boundary.
// Compute this even for a metadate decode because GetCompressedImageSize()
// relies on it.
mPixelRowSize = (mH.mBpp * mH.mWidth + 7) / 8;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
uint32_t surplus = mPixelRowSize % 4;
if (surplus != 0) {
mPixelRowSize += 4 - surplus;
}
size_t bitFieldsLengthStillToRead = 0;
if (mH.mCompression == Compression::BITFIELDS) {
// Need to read bitfields.
if (mH.mBIHSize >= InfoHeaderLength::WIN_V4) {
// Bitfields are present in the info header, so we can read them
// immediately.
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
mBitFields.ReadFromHeader(aData + 36, /* aReadAlpha = */ true);
} else {
// Bitfields are present after the info header, so we will read them in
// ReadBitfields().
bitFieldsLengthStillToRead = BitFields::LENGTH;
}
} else if (mH.mBpp == 16) {
// No bitfields specified; use the default 5-5-5 values.
mBitFields.SetR5G5B5();
} else if (mH.mBpp == 32) {
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
// No bitfields specified; use the default 8-8-8 values.
mBitFields.SetR8G8B8();
}
return Transition::To(State::BITFIELDS, bitFieldsLengthStillToRead);
}
void
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
BitFields::ReadFromHeader(const char* aData, bool aReadAlpha)
{
mRed.Set (LittleEndian::readUint32(aData + 0));
mGreen.Set(LittleEndian::readUint32(aData + 4));
mBlue.Set (LittleEndian::readUint32(aData + 8));
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
if (aReadAlpha) {
mAlpha.Set(LittleEndian::readUint32(aData + 12));
}
}
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadBitfields(const char* aData, size_t aLength)
{
mPreGapLength += aLength;
// If aLength is zero there are no bitfields to read, or we already read them
// in ReadInfoHeader().
if (aLength != 0) {
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
mBitFields.ReadFromHeader(aData, /* aReadAlpha = */ false);
}
// Note that RLE-encoded BMPs might be transparent because the 'delta' mode
// can skip pixels and cause implicit transparency.
mMayHaveTransparency =
(mH.mCompression == Compression::RGB && mIsWithinICO && mH.mBpp == 32) ||
mH.mCompression == Compression::RLE8 ||
mH.mCompression == Compression::RLE4 ||
(mH.mCompression == Compression::BITFIELDS &&
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
mBitFields.mAlpha.IsPresent());
if (mMayHaveTransparency) {
PostHasTransparency();
}
// We've now read all the headers. If we're doing a metadata decode, we're
// done.
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (IsMetadataDecode()) {
return Transition::Terminate(State::SUCCESS);
}
// Set up the color table, if present; it'll be filled in by ReadColorTable().
if (mH.mBpp <= 8) {
mNumColors = 1 << mH.mBpp;
if (0 < mH.mNumColors && mH.mNumColors < mNumColors) {
mNumColors = mH.mNumColors;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Always allocate and zero 256 entries, even though mNumColors might be
// smaller, because the file might erroneously index past mNumColors.
mColors = MakeUnique<ColorTableEntry[]>(256);
memset(mColors.get(), 0, 256 * sizeof(ColorTableEntry));
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// OS/2 Bitmaps have no padding byte.
mBytesPerColor = (mH.mBIHSize == InfoHeaderLength::WIN_V2) ? 3 : 4;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
MOZ_ASSERT(!mImageData, "Already have a buffer allocated?");
IntSize targetSize = mDownscaler ? mDownscaler->TargetSize() : GetSize();
nsresult rv = AllocateFrame(/* aFrameNum = */ 0, targetSize,
IntRect(IntPoint(), targetSize),
SurfaceFormat::B8G8R8A8);
if (NS_FAILED(rv)) {
return Transition::Terminate(State::FAILURE);
}
MOZ_ASSERT(mImageData, "Should have a buffer now");
if (mDownscaler) {
// BMPs store their rows in reverse order, so the downscaler needs to
// reverse them again when writing its output.
rv = mDownscaler->BeginFrame(GetSize(), Nothing(),
mImageData, mMayHaveTransparency,
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
/* aFlipVertically = */ true);
if (NS_FAILED(rv)) {
return Transition::Terminate(State::FAILURE);
}
}
return Transition::To(State::COLOR_TABLE, mNumColors * mBytesPerColor);
}
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadColorTable(const char* aData, size_t aLength)
{
MOZ_ASSERT_IF(aLength != 0, mNumColors > 0 && mColors);
mPreGapLength += aLength;
for (uint32_t i = 0; i < mNumColors; i++) {
// The format is BGR or BGR0.
mColors[i].mBlue = uint8_t(aData[0]);
mColors[i].mGreen = uint8_t(aData[1]);
mColors[i].mRed = uint8_t(aData[2]);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
aData += mBytesPerColor;
}
// We know how many bytes we've read so far (mPreGapLength) and we know the
// offset of the pixel data (mH.mDataOffset), so we can determine the length
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// of the gap (possibly zero) between the color table and the pixel data.
//
// If the gap is negative the file must be malformed (e.g. mH.mDataOffset
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// points into the middle of the color palette instead of past the end) and
// we give up.
if (mPreGapLength > mH.mDataOffset) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
PostDataError();
return Transition::Terminate(State::FAILURE);
}
uint32_t gapLength = mH.mDataOffset - mPreGapLength;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
return Transition::To(State::GAP, gapLength);
}
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::SkipGap()
{
bool hasRLE = mH.mCompression == Compression::RLE8 ||
mH.mCompression == Compression::RLE4;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
return hasRLE
? Transition::To(State::RLE_SEGMENT, RLE::SEGMENT_LENGTH)
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
: Transition::To(State::PIXEL_ROW, mPixelRowSize);
}
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadPixelRow(const char* aData)
{
MOZ_ASSERT(mCurrentPos == 0);
const uint8_t* src = reinterpret_cast<const uint8_t*>(aData);
uint32_t* dst = RowBuffer();
uint32_t lpos = mH.mWidth;
switch (mH.mBpp) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
case 1:
while (lpos > 0) {
int8_t bit;
uint8_t idx;
for (bit = 7; bit >= 0 && lpos > 0; bit--) {
idx = (*src >> bit) & 1;
SetPixel(dst, idx, mColors);
--lpos;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
++src;
}
break;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
case 4:
while (lpos > 0) {
Set4BitPixel(dst, *src, lpos, mColors);
++src;
}
break;
case 8:
while (lpos > 0) {
SetPixel(dst, *src, mColors);
--lpos;
++src;
}
break;
case 16:
if (mBitFields.IsR5G5B5()) {
// Specialize this common case.
while (lpos > 0) {
uint16_t val = LittleEndian::readUint16(src);
SetPixel(dst, mBitFields.mRed.Get5(val),
mBitFields.mGreen.Get5(val),
mBitFields.mBlue.Get5(val));
--lpos;
src += 2;
}
} else {
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
bool anyHasAlpha = false;
while (lpos > 0) {
uint16_t val = LittleEndian::readUint16(src);
SetPixel(dst, mBitFields.mRed.Get(val),
mBitFields.mGreen.Get(val),
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
mBitFields.mBlue.Get(val),
mBitFields.mAlpha.GetAlpha(val, anyHasAlpha));
--lpos;
src += 2;
}
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
if (anyHasAlpha) {
MOZ_ASSERT(mMayHaveTransparency);
mDoesHaveTransparency = true;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
break;
case 24:
while (lpos > 0) {
SetPixel(dst, src[2], src[1], src[0]);
--lpos;
src += 3;
}
break;
case 32:
if (mH.mCompression == Compression::RGB && mIsWithinICO &&
mH.mBpp == 32) {
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
// This is a special case only used for 32bpp WinBMPv3-ICO files, which
// could be in either 0RGB or ARGB format.
while (lpos > 0) {
// If src[3] is zero, we can't tell at this point if the image is
// 0RGB or ARGB. So we just use 0 value as-is. If the image is 0RGB
// then mDoesHaveTransparency will be false at the end, we'll treat
// the image as opaque, and the 0 alpha values will be ignored. If
// the image is ARGB then mDoesHaveTransparency will be true at the
// end and we'll treat the image as non-opaque. (Note: a
// fully-transparent ARGB image is indistinguishable from a 0RGB
// image, and we will render such an image as a 0RGB image, i.e.
// opaquely. This is unlikely to be a problem in practice.)
if (src[3] != 0) {
MOZ_ASSERT(mMayHaveTransparency);
mDoesHaveTransparency = true;
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
SetPixel(dst, src[2], src[1], src[0], src[3]);
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
src += 4;
--lpos;
}
} else if (mBitFields.IsR8G8B8()) {
// Specialize this common case.
while (lpos > 0) {
uint32_t val = LittleEndian::readUint32(src);
SetPixel(dst, mBitFields.mRed.Get8(val),
mBitFields.mGreen.Get8(val),
mBitFields.mBlue.Get8(val));
--lpos;
src += 4;
}
} else {
bool anyHasAlpha = false;
while (lpos > 0) {
uint32_t val = LittleEndian::readUint32(src);
SetPixel(dst, mBitFields.mRed.Get(val),
mBitFields.mGreen.Get(val),
mBitFields.mBlue.Get(val),
mBitFields.mAlpha.GetAlpha(val, anyHasAlpha));
--lpos;
src += 4;
}
if (anyHasAlpha) {
MOZ_ASSERT(mMayHaveTransparency);
mDoesHaveTransparency = true;
}
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
break;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
default:
MOZ_CRASH("Unsupported color depth; earlier check didn't catch it?");
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
FinishRow();
return mCurrentRow == 0
? Transition::Terminate(State::SUCCESS)
: Transition::To(State::PIXEL_ROW, mPixelRowSize);
}
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadRLESegment(const char* aData)
{
if (mCurrentRow == 0) {
return Transition::Terminate(State::SUCCESS);
}
uint8_t byte1 = uint8_t(aData[0]);
uint8_t byte2 = uint8_t(aData[1]);
if (byte1 != RLE::ESCAPE) {
// Encoded mode consists of two bytes: byte1 specifies the number of
// consecutive pixels to be drawn using the color index contained in
// byte2.
//
// Work around bitmaps that specify too many pixels.
uint32_t pixelsNeeded =
std::min<uint32_t>(mH.mWidth - mCurrentPos, byte1);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (pixelsNeeded) {
uint32_t* dst = RowBuffer();
mCurrentPos += pixelsNeeded;
if (mH.mCompression == Compression::RLE8) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
do {
SetPixel(dst, byte2, mColors);
pixelsNeeded --;
} while (pixelsNeeded);
} else {
do {
Set4BitPixel(dst, byte2, pixelsNeeded, mColors);
} while (pixelsNeeded);
}
}
return Transition::To(State::RLE_SEGMENT, RLE::SEGMENT_LENGTH);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (byte2 == RLE::ESCAPE_EOL) {
mCurrentPos = 0;
FinishRow();
return mCurrentRow == 0
? Transition::Terminate(State::SUCCESS)
: Transition::To(State::RLE_SEGMENT, RLE::SEGMENT_LENGTH);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (byte2 == RLE::ESCAPE_EOF) {
return Transition::Terminate(State::SUCCESS);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (byte2 == RLE::ESCAPE_DELTA) {
return Transition::To(State::RLE_DELTA, RLE::DELTA_LENGTH);
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
// Absolute mode. |byte2| gives the number of pixels. The length depends on
// whether it's 4-bit or 8-bit RLE. Also, the length must be even (and zero
// padding is used to achieve this when necessary).
MOZ_ASSERT(mAbsoluteModeNumPixels == 0);
mAbsoluteModeNumPixels = byte2;
uint32_t length = byte2;
if (mH.mCompression == Compression::RLE4) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
length = (length + 1) / 2; // halve, rounding up
}
if (length & 1) {
length++;
}
return Transition::To(State::RLE_ABSOLUTE, length);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadRLEDelta(const char* aData)
{
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
// Delta encoding makes it possible to skip pixels making part of the image
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// transparent.
Bug 1214072 (part 2) - Implement transparency properly for BMP images. r=seth. 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
2015-10-14 07:20:10 +03:00
MOZ_ASSERT(mMayHaveTransparency);
mDoesHaveTransparency = true;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
if (mDownscaler) {
// Clear the skipped pixels. (This clears to the end of the row,
// which is perfect if there's a Y delta and harmless if not).
mDownscaler->ClearRow(/* aStartingAtCol = */ mCurrentPos);
}
// Handle the XDelta.
mCurrentPos += uint8_t(aData[0]);
if (mCurrentPos > mH.mWidth) {
mCurrentPos = mH.mWidth;
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
}
// Handle the Y Delta.
int32_t yDelta = std::min<int32_t>(uint8_t(aData[1]), mCurrentRow);
mCurrentRow -= yDelta;
if (mDownscaler && yDelta > 0) {
// Commit the current row (the first of the skipped rows).
mDownscaler->CommitRow();
// Clear and commit the remaining skipped rows.
for (int32_t line = 1; line < yDelta; line++) {
mDownscaler->ClearRow();
mDownscaler->CommitRow();
}
}
return mCurrentRow == 0
? Transition::Terminate(State::SUCCESS)
: Transition::To(State::RLE_SEGMENT, RLE::SEGMENT_LENGTH);
}
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
LexerTransition<nsBMPDecoder::State>
nsBMPDecoder::ReadRLEAbsolute(const char* aData, size_t aLength)
{
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
uint32_t n = mAbsoluteModeNumPixels;
mAbsoluteModeNumPixels = 0;
if (mCurrentPos + n > uint32_t(mH.mWidth)) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
// Bad data. Stop decoding; at least part of the image may have been
// decoded.
return Transition::Terminate(State::SUCCESS);
}
// In absolute mode, n represents the number of pixels that follow, each of
// which contains the color index of a single pixel.
uint32_t* dst = RowBuffer();
uint32_t iSrc = 0;
uint32_t* oldPos = dst;
if (mH.mCompression == Compression::RLE8) {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
while (n > 0) {
SetPixel(dst, aData[iSrc], mColors);
n--;
iSrc++;
}
} else {
Bug 1204394 (part 1) - Using StreamingLexer in the BMP decoder. r=seth. 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
2015-10-09 08:47:56 +03:00
while (n > 0) {
Set4BitPixel(dst, aData[iSrc], n, mColors);
iSrc++;
}
}
mCurrentPos += dst - oldPos;
// We should read all the data (unless the last byte is zero padding).
MOZ_ASSERT(iSrc == aLength - 1 || iSrc == aLength);
return Transition::To(State::RLE_SEGMENT, RLE::SEGMENT_LENGTH);
}
} // namespace image
} // namespace mozilla