* speeds up incremental builds as changes to a header will not always
need the full mocs_compilation.cpp for all the target's headers rebuild,
while having a moc file sourced into a source file only adds minor
extra costs, due to small own code and the used headers usually
already covered by the source file, being for the same class/struct
* seems to not slow down clean builds, due to empty mocs_compilation.cpp
resulting in those quickly processed, while the minor extra cost of the
sourced moc files does not outweigh that in summary.
Measured times actually improved by some percent points.
(ideally CMake would just skip empty mocs_compilation.cpp & its object
file one day)
* enables compiler to see all methods of a class in same compilation unit
to do some sanity checks
* potentially more inlining in general, due to more in the compilation unit
* allows to keep using more forward declarations in the header, as with the
moc code being sourced into the cpp file there definitions can be ensured
and often are already for the needs of the normal class methods
(cherry picked from commit 34ed3bad27)
- 1-bit writer: checks where is black and use NOT operator only if needed
- Fix images with witdh == 65536(*)
- Checks result of disk writes and reads on all formats
(*) PCX formats support images with with of 65536 but only if the header field bytesPerLine is valid (no overflow). This means that the width 65536 is supported on 1bpp images only.
The previous version of the plugins wrote an image with width of 65536px in the wrong way and it was unable to read it (wrong image returned). I verified that Photoshop and Gimp weren't able to read the image either.
(cherry picked from commit d57ff91f8b)
- Fix wrong RGB channel order if image format is other than (A)RGB32
- Write right resolution
- Set right resolution on image load
- Return false on write error
- Save images with depth greater than 24-bits
(cherry picked from commit e60dfd4968)
The VGA palette starts 769 bytes before the end of the file. There may be PADs between the end of the image and the start of the palette.
BUG: 463951
(cherry picked from commit 14742cb502)
To make the plugins fail to allocate if the image size is greater than QImageReader::allocationLimit() it is necessary to allocate the image with QImageIOHandler::allocateImage().
Note that not all plugins have been changed and some others are not tested in the CI (maybe due to missing libraries).
PS: the following message is printed by QImageIOHandler::allocateImage() if the size is exceeded: "qt.gui.imageio: QImageIOHandler: Rejecting image as it exceeds the current allocation limit of XXX megabytes"
According to relicensecheck Brad is OK with changing LGPLv2 to LGPLv2+,
which is required to be compatible with the LGPL-2.1-or-later licensed
source files.
Since QImage does sanity checking for overflows and stuff wrt.
dimensions and depth, check for QImage::isNull() as early as possible to
see if there's some funky business going on.
Also tried to add some checks wherever we wrote to "raw" memory.
Unit tests pass, and tested converting some files from
https://samples.ffmpeg.org/image-samples/ to pngs, and that seemed to
work.
Reviewed By: aacid
Differential Revision: https://phabricator.kde.org/D24367
Frameworks have a convention of naming uninstalled headers in src/ with
a _p at the end of the name, to make it clear they are not part of the
API. None of the headers in KImageFormats are installed, so it is not
really necessary to follow this convention, but we follow it anyway for
the benefit of both humans and tools (like kapidox).
