| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This test data was added for the pixbuf-gif-circular-table test (added October
2018 in 0b9d004) but because the file was never actually installed the installed
test suite never passes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
A laaaarge XPM file.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=793470
|
|
|
|
| |
An example image that generates the "Circular table entry in GIF file" error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Add tests that exert many different types of GIF files. Some of the tests are
disabled as the current gdk-pixbuf GIF implementation doesn't handle them
correctly. Future commits will fix these issues and enable the tests.
The test suite is generated in the PyGIF project
(https://github.com/robert-ancell/pygif)
|
|
|
|
|
|
|
| |
When building without GDK_PIXBUF_USE_GIO_MIME detect the format based on the
fill extension and not the mime type.
This makes these tests pass on Windows.
|
|
|
|
|
|
|
|
| |
When cloning the repo with git on Windows the symlinks end up being
normal files which contain the target path as text.
Make this kinda work by detecting if the files contain ascii only
and then treating the content as a filename in the parent directory.
|
|
|
|
|
|
|
| |
So we use the right path encoding on Windows and don't interpret the content
as text.
This makes the pixbuf-threads run on Windows.
|
|
|
|
|
|
| |
It already takes about 20 seconds on my Core i7, and it can get worse
when running multiple tests in parallel, so it's a prime candidate for
timeouts on our CI infrastructure.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=775229
|
|\
| |
| |
| |
| | |
Run the test suite on the CI pipeline
See merge request GNOME/gdk-pixbuf!7
|
| |
| |
| |
| |
| |
| |
| |
| | |
Meson allows us to classify each test in the test suite using one or
more tags; this allows us to specify what kind of tests we want to run
inside our CI infrastructure, for instance by tagging the "slow" tests
that should have a special time out value, or that should only be run on
demand to avoid hammering the build server.
|
|/ |
|
|
|
|
|
|
| |
We use Meson, now. The Meson build has been tested for almost a year in
our continuous integration pipeline, and it's functionally equivalent to
the Autotools one.
|
|
|
|
|
|
| |
Like the Autotools build allows us to decide whether the tests should be
installed in a known location, we should have this option for the Meson
build.
|
|
|
|
|
| |
Same as commit fc2d02ed908c524cc2831e5404d5f06b02e3f9fd, but for the
Meson build.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=795210
|
|
|
|
|
|
|
|
| |
We're currently installing the test launchers and parts of the test
data, but we're not installing the binaries and the whole suite of
image data we have.
https://bugzilla.gnome.org/show_bug.cgi?id=795527
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=779016
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=753605
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=778584
|
|
|
|
|
|
| |
Provided by Ariel Zelivansky <ariel.zelivans@gmail.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779012
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=786306
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785973
|
|
|
|
|
|
|
|
|
|
|
| |
The pixbuf-area-updated and pixbuf-randomly-modified tests are
particularly taxing on the CPU, and though modern desktop machines
shouldn't have a problem dealing with those under 30 seconds, tests
are run in parallel, and busy build machines might fail those tests
because of timeouts.
Bump the timeouts to 300 seconds for those long tests to avoid test
failures.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=787050
|
|
|
|
| |
This is an interactive test program, not an automated one.
|
|
|
|
|
|
|
| |
When the test fails, let's first give it the chance to print the error
message in order to help debugging failures.
https://bugzilla.gnome.org/show_bug.cgi?id=786259
|
|
|
|
|
|
| |
Ensure variables are declared at the top of the block.
https://bugzilla.gnome.org/show_bug.cgi?id=785767
|
|
|
|
|
|
|
|
|
| |
sys/time.h is not a header that is provided by all compilers that we
support, so we need to check for it and include it conditionally so that
things will build normally, especially as Meson builds will build all
the test programs as well.
https://bugzilla.gnome.org/show_bug.cgi?id=785767
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785964
|
|
|
|
| |
This makes it easier to find them and reference them.
|
|
|
|
|
|
|
|
|
|
|
| |
This could happen if something in the test fails, so this allows early
diagnosis of problems. It also hints to Coverity that the loops which
follow can’t run (almost) infinitely due to the loop bounds being
inverted.
Coverity IDs: 1391987, 1399712
https://bugzilla.gnome.org/show_bug.cgi?id=778943
|
|
|
|
|
| |
We want to be able to run the gdk-pixbuf tests after installing them in
a known system location, especially when running CI.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Meson is a better build system than Autotools that has gotten traction
in the GNOME community.
The build is pretty much equivalent between Autotools and Meson, but at
this point it needs further testing to verify complete matching
behaviour.
The GDI-plus loaders are not currently built, as that will require
access to a platform I don't have in order to test them.
Additionally, the API reference is not being generated yet in Meson.
|
|
|
|
| |
Don't leave files behind.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=780667
|
|
|
|
|
|
| |
File created using afl.
https://bugzilla.gnome.org/show_bug.cgi?id=777315
|
|
|
|
|
|
| |
The loader should return an error in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=778204
|
| |
|
|
|
|
|
|
|
| |
Originally from the JPEG conformance tests:
http://people.sc.fsu.edu/~jburkardt/data/jpg/jpg.html
https://bugzilla.gnome.org/show_bug.cgi?id=785171
|
|
|
|
|
|
| |
The sanity checks for image dimensions have since been tightened in
commit 4154d4f and we should not be able to open this huge image anymore
as the dimensions exceed what's possible.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=785447
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=776040
|