| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Update gi-docgen's wrap
See merge request GNOME/gdk-pixbuf!151
|
| |
| |
| |
| | |
Meson will check the dependency based on the subproject's overrides.
|
| |
| |
| |
| |
| | |
Use the `provide` override to ensure that Meson knows what the gi-docgen
wrap provides.
|
|\ \
| |/
|/|
| |
| | |
Fix some GIR annotations
See merge request GNOME/gdk-pixbuf!146
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
meson: Override dependencies to improve usage as a subproject
See merge request GNOME/gdk-pixbuf!148
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With this change, gdk-pixbuf can be consumed as a subproject without
making any changes to the build files of a project. All you need to do
is provide a wrap file with a `[provide]` section:
https://mesonbuild.com/Wrap-dependency-system-manual.html#provide-section
This is also necessary because otherwise projects need to hard-code
the subproject name, which might be `gdk-pixbuf` when using `wrap-git`
or `gdk-pixbuf-2.42.10` when using `wrap-file` (to build from
a release tarball). This can cause conflicts between different
subprojects that consume gdk-pixbuf differently.
Other projects like glib, cairo, pango, etc already do this.
|
| | |
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
jpeg: Bump up the memory limit to 1GB
Closes #218
See merge request GNOME/gdk-pixbuf!147
|
|/
|
|
|
|
| |
Let's play some more whack-a-mole.
Fixes: #218
|
|\
| |
| |
| |
| | |
docs: Also search for rst2man.py
See merge request GNOME/gdk-pixbuf!145
|
|/ |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
ci: Bump up Meson on macOS
See merge request GNOME/gdk-pixbuf!140
|
| |
| |
| |
| |
| | |
We use GLib as a subproject, which means we need to use the same version
of Meson that GLib requires.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
jpeg: Increase memory limit for loading image data
Closes #216
See merge request GNOME/gdk-pixbuf!143
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
As fix for security issue #205 when loading image data the memory size
was limited to 100 MB. That seemed like a good threshold. For larger
images, from around 18 megapixels (MP) and up though not for all such
images, this threshold was too low. Increasing the threshold too 300 MB
seems to work better and lets larger images load.
Fixes #216.
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
build: Clean up search for deps on Visual Studio
See merge request GNOME/gdk-pixbuf!131
|
| | |
| | |
| | |
| | |
| | | |
Like the previous commits, use CMake's builtin support to look for
libtiff, which will clean things up a bit in the build files
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Like wat we did for libpng, do likewise to look for libjpeg (or
libjpeg-turbo) via CMake's builtin support, so that we can clean up the
build files and have CMake do a more comprehensive manual search for
libjpeg or libjpeg-turbo.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We can use CMake's built-in search for the libpng headers and libraries
for Visual Studio-like compilers; however, we must use 'png' instead of
'libpng' for the package name for this to work.
This will cover the manual headers and .lib search in a more
comprehensive way, which CMake will handle for us and it is an
optionally-installed item for Visual Studio 2017 and later, and is very
commonly used on Windows dev environments.
Also use a common variable to indicate whether we are using an MSVC-like
compiler, to save future typing.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Disable relocation when built as a static libary on Windows
See merge request GNOME/gdk-pixbuf!136
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
meson: update man option to mention it now requires rst2man
See merge request GNOME/gdk-pixbuf!135
|
| |/ / / |
|
|\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | | |
jpeg: Limit the memory size when loading image data
Closes #205
See merge request GNOME/gdk-pixbuf!139
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Specially crafted JPEG images may lead to a crash when their size is too
large; in the most benign of cases, the OS might terminate the process
after it tries to allocate all the memory in the world.
We can tell libjpeg to limit the size of the memory pool when loading,
to avoid this kind of result. For the time being, 100 MB seems like a
good threshold.
Original patch by: Sam Ezeh <sam.z.ezeh@gmail.com>
Fixes: #205
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix overflow when reading GIF images with invalid LZW initial code size.
See merge request GNOME/gdk-pixbuf!130
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This value is the number of bits for each symbol (i.e. colour index) decoded via LZW.
The maximum LZW code is specified as 12 bits, so the value here can only be 11 as two additional code words are required (clear and end of information) that immediately uses an additional bit.
This implementation has always been wrong, and the Firefox implementation has the same issue so it seems a common misinterpretation of the spec.
This has been changed here to avoid an assertion later in the LZW decoder.
Note that there is never any reason for a GIF to be encoded with more than 8 bits of colour information, as the colour tables only support up to 8 bits.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
build: Update libjpeg-turbo wrap
See merge request GNOME/gdk-pixbuf!138
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The current wrap version has a bug when building on Windows with
MSVC. Update to 2.1.2-2 as per wrapdb [1].
[1]
https://wrapdb.mesonbuild.com/v2/libjpeg-turbo_2.1.2-2/libjpeg-turbo.wrap
|
| | | | |
|
| |/ /
|/| | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Replace DocBook with reStructuredText for man pages
See merge request GNOME/gdk-pixbuf!134
|
| | | | |
|
| | | | |
|
| | | | |
|