| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This will let us avoid NULL checks in the individual modules.
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Changed variable to unsigned and slightly improved algorithm performance
(stop when n == 0, no need to keep going until the end).
See issue: #96
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
|
|
|
|
| |
A corrupt file might have non valid UTF-8 data in the version, so we need to
escape it.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Common GdkPixbufAnimation implementations need to avoid warnings caused
by the recent deprecation of GTimeVal in GLib 2.62.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Fail hard when the XPM file's advertised width or height does not match
the data contained within the file.
|
| |
|
|
|
|
| |
In the same way that libXpm sanity checks it.
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
Separate the builtin loaders setup from the external loaders
initialisation from the loaders.cache file.
https://bugzilla.gnome.org/show_bug.cgi?id=786035
|
|
|
|
| |
For the new API to be added.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
jas_matrix_create can return NULL when memory allocation
fails.
Closes: #107
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|