summaryrefslogtreecommitdiffstats
path: root/third_party/aom
diff options
context:
space:
mode:
authorAndrew Osmond <aosmond@mozilla.com>2019-02-16 20:21:13 +0100
committerwolfbeast <mcwerewolf@wolfbeast.com>2019-02-16 20:35:50 +0100
commitcdc5daf5da425965619a53fd8a180d1975b51dbd (patch)
tree27a7c7392186584741000107faa3bf84a185bbc5 /third_party/aom
parentb1de755d0f9415a1a11e0531765470de6905dc3c (diff)
downloadUXP-cdc5daf5da425965619a53fd8a180d1975b51dbd.tar
UXP-cdc5daf5da425965619a53fd8a180d1975b51dbd.tar.gz
UXP-cdc5daf5da425965619a53fd8a180d1975b51dbd.tar.lz
UXP-cdc5daf5da425965619a53fd8a180d1975b51dbd.tar.xz
UXP-cdc5daf5da425965619a53fd8a180d1975b51dbd.zip
BMPs from the clipboard may include extra padding.
In the original Windows clipboard BMP decoder implementation in nsImageFromClipboard::ConvertColorBitMap, if the bitmap used bitfields compression, it always adjusted the offset to the RGB data by 12 bytes. It did this even for newer BMP header formats which explicitly include space for the bitfields in their header sizes. This patch updates our BMP decoder to do the same for clipboard BMPs, since we have observed pasted BMPs using bitfield compression appearing incorrectly. To the user this appears as if we read a color mask; completely red, blue, green pixels at the start of the last row, causing all of the other rows to start with the last three pixels of the previous row.
Diffstat (limited to 'third_party/aom')
0 files changed, 0 insertions, 0 deletions