summaryrefslogtreecommitdiff
path: root/gdk-pixbuf
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* xpm: Simplify error pathBastien Nocera2019-03-011-9/+11
|
* xpm: Sanity check XPM file dimensionsBastien Nocera2019-03-011-0/+9
| | | | In the same way that libXpm sanity checks it.
* core: Fix split docs line in features.h fileBastien Nocera2019-02-281-2/+1
|
* core: Add gdk_pixbuf_init_modules() for applicationsBastien Nocera2019-02-282-0/+38
| | | | | | | | gdk_pixbuf_init_modules() should be used by applications which want to have gdk-pixbuf loader modules install in a separate path, usually in the application's library directory. https://bugzilla.gnome.org/show_bug.cgi?id=786035
* core: Pass module_file path as an argumentBastien Nocera2019-02-281-17/+22
| | | | | | | This should allow applications to install gdk-pixbuf modules in a separate directory from the system location. https://bugzilla.gnome.org/show_bug.cgi?id=786035
* core: Split off the initialisation sectionsBastien Nocera2019-02-281-71/+81
| | | | | | | Separate the builtin loaders setup from the external loaders initialisation from the loaders.cache file. https://bugzilla.gnome.org/show_bug.cgi?id=786035
* Add missing 2.40 versioning macrosBastien Nocera2019-02-281-0/+28
| | | | For the new API to be added.
* build: Use idiomatic pkg-config generationEmmanuele Bassi2019-02-281-3/+1
| | | | | | We're still using the deprecated form of passing gdk-pixbuf as a library named argument, instead of the idiomatic positional argument, which lets Meson figure out all the needed dependencies.
* io-jasper.c: Validate jas_matrix_create resultIvan A. Melnikov2019-02-271-0/+8
| | | | | | | jas_matrix_create can return NULL when memory allocation fails. Closes: #107
* gif: Simplify LZW clear code handlingRobert Ancell2019-01-161-18/+3
| | | | | | The existing code had a special state for handling codes after a clear code was received. This is more simply handled by using the 'lzw_oldcode' variable. This makes code that is less likely to introduce errors.
* gif: Fix clear code handling when at end of a blockRobert Ancell2019-01-161-1/+1
| | | | | | | | | | | | | | | | The following was occurring: 1. A clear code is detected in the LZW stream. 2. The decoder enters a clear code handling state. 3. The decoder looks for the next code after the clear. 4. The decoder has run out of blocks, so enters a state to get new blocks The issue is in step 4 the decoder has assumed the clear state is complete, when it is not. The solution is to only complete the clear state once a non clear code is read. This caused the "Circular table entry in GIF file" error for some GIFs. Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/27 Fixes https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/69
* gif: Fix multiple LZW clear codes breaking decodingRobert Ancell2019-01-161-39/+1
| | | | | | | | | | | | | | | | The following was occurring: 1. A clear code is detected in the LZW stream 2. The first code is detected as a clear. 3. The following code is returned as a color index, this breaks if it is a clear. There were two codepaths in use, one for handling the first clear in the LZW sequence and another for handling clears within the sequence. The former handled sequential clears correctly, the latter did not. The solution is to the correct codepath and remove the other one. This simplification should not affect other decoding (as confirmed by the test suite).
* gif: Fix off by one error in LZW decoderRobert Ancell2019-01-161-1/+1
| | | | | | | | | | | | | | | | | The following was occurring: 1. Code words would be read from the LZW data blocks. 2. If there was exactly enough space for one more codeword in the block, more blocks were read. This is the off by one error. It should have read the last code before doing this. 3. If the next block was the terminating block the code would be marked as complete. 4. Another block would be attempted to be read, because the decoder was still in the same state as step 2. 5. An error was generated because the decoder was trying to read blocks after it had determined the stream had ended. This fixes the GIF decoder failing to decode images without an end-of-information code.
View Lorry Controller Status