summaryrefslogtreecommitdiff
path: root/gdk-pixbuf
Commit message (Collapse)AuthorAgeFilesLines
* pixops: Avoid division during alpha scalingJan Ziak2020-06-261-9/+28
| | | | | | | | | | | This patch significantly improves performance of gtksourceview-2.10.5 full-screen redraw on a 4K display with an alpha channel. Divisions by the common value 0xff0000 are converted into multiplications by an optimizing C compiler. For other values, 3 divisions are reduced to 1 division, 3 multiplications and some float-to-int conversions.
* docs: Move the core data section to the source fileEmmanuele Bassi2020-06-262-69/+68
| | | | | | | The relative links in the functions documentation stanza refer to the current section; this means that, in order to refer to an anchor specified in a section the symbols must be in the same section within the same file.
* XPM: Fix undefined behaviourTobias Stoeckmann2020-06-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Pixel data in XPM files consists of color characters. XPM allows up to 31 characters per pixel (cpp). If the file defines a width larger than G_MAXINT / cpp, the calculated memory required to parse a single line (wbytes) leads to a signed integer overflow. On common systems, a signed integer overflow works as expected on a bit level. Properly crafted files can overflow the variable wbytes in a way that it is positive again, which leads to a "successful" parsing of the XPM file. The pixel values itself are not assigned by gdk-pixbuf code, therefore leaking raw memory returned by malloc. This might leak sensitive information through pixel values, depending on the actual application. Proof of Concept: /* XPM */ static char * poc_xpm[] = { "138547333 1 1 31", "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx c None", "---------------------------"};
* XBM: Fix signed integer overflow.Tobias Stoeckmann2020-06-261-2/+2
| | | | | | | | | | | | | | | | Parsing an XBM file with pixel bits larger than int leads to undefined behavior (signed integer overflow). Since only the lowest 8 bits are used, this patched code produces the same images as before. Also do not increment gotone but set it to a value. If more than INT_MAX values are parsed, this int would overflow as well. Proof of Concept (compile with -fsanitize=undefined or -ftrapv): static unsigned char poc_bits[] = { 0xFFFFFFFF };
* io-bmp.c: Fix building on older compilersChun-wei Fan2020-06-241-1/+3
| | | | | Avoid declaring variables in a for loop initialization so that the code continues to build on older compilers.
* GIF: Plug animation data and iterator leakSebastian Keller2020-04-021-1/+5
| | | | | | The get_static_image() method for gifs is leaking an iterator and since the iterator has a reference to the animation, this results in all animation frames being leaked.
* Check the memset length argumentEmmanuele Bassi2020-04-021-1/+5
| | | | | | Avoid overflows by using the checked multiplication macro for gsize. Fixes: #132
* pixdata: Bail out if the error is setEmmanuele Bassi2020-04-021-1/+6
| | | | | We might still get a GdkPixbuf even if the GError is set, which leads to us reusing the GError instance later on.
* JPEG: skip bytes during incremental loadNathan Lee2020-04-021-17/+16
| | | | | | | Previously only skipped bytes at the start of incremental loads. During a incremental load, there may be bytes to skip between reloads. Previous behavior misread metadata sometimes. Fixes #70
* loaders: Make the names of prepared_func and updated_func consistentFederico Mena Quintero2020-01-077-101/+101
| | | | | | | | | They were prepare_func/prepared_func, and update_func/updated_func in various places. Since their corresponding type names are GdkPixbufModulePreparedFunc and GdkPixbufModuleUpdatedFunc, make all the fields be called prepared_func and updated_func to make them easier to grep.
* JPEG: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-21/+21
|
* GIF: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-31/+66
|
* QTIF: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-36/+22
|
* ICO: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-8/+10
|
* gdip-utils: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-8/+10
|
* XPM: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-10/+12
|
* Jasper: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-13/+14
|
* PNG: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-5/+7
|
* PNM: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-6/+9
|
* XBM: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-3/+6
|
* TIFF: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-3/+7
|
* ANI: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-8/+10
|
* BMP: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-25/+23
|
* ICNS: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-17/+18
|
* TGA: assert and assume that the module callbacks are non-NULLFederico Mena Quintero2020-01-071-9/+9
|
* TGA: don't use single-letter field names for the module callbacksFederico Mena Quintero2020-01-071-21/+22
|
* Never pass NULL for the size_func and updated_func of module->begin_load()Federico Mena Quintero2020-01-072-2/+36
| | | | This will let us avoid NULL checks in the individual modules.
* pixops: Fix memory leaks in error pathsAlex Henrie2020-01-071-8/+9
| | | | | Also remove redundant null checks before g_free, and use g_free instead of g_clear_pointer because we never read the pointer value again.
* gdk-pixbuf/meson.build: use darwin_versions in libraryTom Schoonjans2019-11-271-0/+1
|
* gdk-pixbuf: Deprecate GdkPixbufAlphaModeBastien Nocera2019-11-261-0/+2
|
* Fix cppcheck 'shifting signed 32-bit value warning'Emmanuel Fleury2019-11-251-4/+3
| | | | | | | Changed variable to unsigned and slightly improved algorithm performance (stop when n == 0, no need to keep going until the end). See issue: #96
* gif: Fix build on Solaris by including <string.h>Alan Coopersmith2019-11-251-0/+1
| | | | | | | | | | | | | | | | | | | | | Fixes build failure of: ../gdk-pixbuf/io-gif-animation.c: In function ‘gdk_pixbuf_gif_anim_iter_get_pixbuf’: ../gdk-pixbuf/io-gif-animation.c:418:17: error: implicit declaration of function ‘memset’ [-Werror=implicit-function-declaration] 418 | memset (gdk_pixbuf_get_pixels (anim->last_frame_data), 0, gdk_pixbuf_get_rowstride (anim->last_frame_data) * anim->height); | ^~~~~~ ../gdk-pixbuf/io-gif-animation.c:418:17: warning: incompatible implicit declaration of built-in function ‘memset’ ../gdk-pixbuf/io-gif-animation.c:28:1: note: include ‘<string.h>’ or provide a declaration of ‘memset’ 27 | #include "lzw.h" +++ |+#include <string.h> 28 | ../gdk-pixbuf/io-gif-animation.c:443:33: warning: incompatible implicit declaration of built-in function ‘memset’ 443 | memset (line, 0, (x_end - anim->last_frame->x_offset) * 4); | ^~~~~~ ../gdk-pixbuf/io-gif-animation.c:443:33: note: include ‘<string.h>’ or provide a declaration of ‘memset’ cc1: some warnings being treated as errors Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
* (#91): Have a STORAGE_UNINITIALIZED for construction with all-default propertiesFederico Mena Quintero2019-09-112-97/+183
| | | | | | | | | | | | | | | | | | | If one does a plain GdkPixbuf *pixbuf = g_object_new (GDK_TYPE_PIXBUF, NULL); Then all the construct properties use their default values. This means that both "pixels" and "pixel-bytes" get passed as NULL to gdk_pixbuf_set_property(). Later, trying to get the property for "pixel-bytes" would assert, incorrectly, because it was trying to create a GBytes from a NULL pixels storage. This commit adds a test for that construction case, and tests for constructing with g_object_new() in general. Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/91
* docs: Add missing argumentEmmanuele Bassi2019-08-141-0/+1
|
* gif: Suppress last deprecation warningEmmanuele Bassi2019-07-291-0/+2
|
* gif: Render GIF frames on demandRobert Ancell2019-07-293-716/+239
| | | | | | | | | | | | | | | | | | | | | | | | | The previous code loaded all the frames into memory, which causes a memory and CPU explosion when a large GIF was loaded. From the existing code: /* The below reflects the "use hell of a lot of RAM" philosophy of coding */ The updated code now generates each image on demand by storing the compressed data and decompressing and combining with the last image. This uses more CPU than the old method, but allows arbitraritly large GIFs to play. The stop_after_first_frame hack that worked around this is no longer required and removed. This hack didn't work for progressive loading. If a GIF was played with frames out of order (e.g. in reverse) this would be quite slow, as repeated rendering would occur. This seems unlikely in the GIF use case but if it was a problem storing some key frames that would normally be discarded would reduce this while not using too much memory. A render cache could also be helpful in making a CPU / RAM trade-off for small repeating GIFs that have few frames. Fixes #101
* gif: Replace old LZW decoder with a stand-alone decoderRobert Ancell2019-07-294-281/+299
|
* gif: Remove unused variableRobert Ancell2019-07-292-5/+0
|
* gif: Remove unused variableRobert Ancell2019-07-292-15/+10
|
* gif: Escape GIF version in error messageRobert Ancell2019-07-291-1/+5
| | | | | A corrupt file might have non valid UTF-8 data in the version, so we need to escape it.
* gif: Disable deprecation warnings for GTimeValEmmanuele Bassi2019-07-292-1/+10
|
* gdip: Disable deprecation warnings for GTimeValEmmanuele Bassi2019-07-291-0/+9
|
* ani: Disable deprecation warnings for GTimeValEmmanuele Bassi2019-07-292-1/+10
|
* Disable deprecation warnings for GTimeValEmmanuele Bassi2019-07-292-0/+5
| | | | | Common GdkPixbufAnimation implementations need to avoid warnings caused by the recent deprecation of GTimeVal in GLib 2.62.
* Use the monotonic clock instead of wall oneEmmanuele Bassi2019-07-291-12/+6
| | | | | | We're measuring time deltas; the monotonic clock provides a better resolution, and we don't have to care about things like microsecond wrap-around or the clock going backwards mid-measurement.
* Disable deprecation warnings for GTimeValEmmanuele Bassi2019-07-292-0/+10
| | | | | | | | | | | GLib 2.62 deprecated GTimeVal and GTime because they are not Y2038-safe. Since we expose these types in our public API, we need to disable warnings to avoid projects breaking horribly just by importing gdk-pixbuf.h. Sadly, GdkPixbufAnimation public types not only require GTimeVal in virtual function signatures for loaders, but they also do not have any room left in the class vtable for adding int64 variants.
* Remove uses of g_memmove()Emmanuele Bassi2019-06-291-1/+1
| | | | | | | | | There's no reason to use g_memmove() instead of memmove(). The `g_memmove()` wrapper was a symbol internal to GLib between 2004 and 2013, when it was exposed as a plain C pre-processor symbol around C90's memmove(). Starting from GLib 2.61, using g_memmove() is going to raise a deprecation warning from the compiler.
* build: Do not use `install` arg with configure_file()Emmanuele Bassi2019-06-291-1/+0
| | | | | | The `install` argument is implicitly set to true when specifying the `install_dir` argument. The argument is only used by Meson ≥ 0.50, and ever there, it's only ever useful if paired to a configuration option.
* core: Always initialise default pixbuf loadersBastien Nocera2019-03-051-7/+21
| | | | | | | | | | | | | | The "run once" initialisation of pixbuf modules shipped with gdk-pixbuf itself would be skipped if an application was successfully calling gdk_pixbuf_init_modules() first, as this would set the internal list of file_formats to be non-NULL, and skip any initialisation of those modules. This fix makes sure that pixbuf modules shipped with gdk-pixbuf are always initialised, regardless of whether gdk_pixbuf_init_modules() successfully initialised an application provided one. Fixes: fd1376b799e411f983ab6faa00b066a8007ad9a1
* xpm: Fail when XPM file doesn't contain enough dataBastien Nocera2019-03-011-2/+8
| | | | | Fail hard when the XPM file's advertised width or height does not match the data contained within the file.
View Lorry Controller Status