summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Update Polish translationPiotr Drąg2017-02-071-80/+84
|
* gdk-pixbuf-loader: Fix up previous commit 2634506cPhilip Withnall2017-02-071-1/+1
| | | | | | | The assertion needs to be the target of an implication (count > 0), as it could legitimately be false if (count == 0). https://bugzilla.gnome.org/show_bug.cgi?id=776990
* gdk-pixbuf-loader: Add a missing NULL checkPhilip Withnall2017-02-071-1/+4
| | | | | | | | | | | | | | The code just above checks whether image_module is NULL, and it doesn’t look like it can change in the meantime, so we should also check before dereferencing it for load_increment. Make this an assertion; although we’re not entirely sure how this code was originally supposed to work, we’re still in development, so we can investigate any assertion failures with impunity. Coverity CID: 1388529 https://bugzilla.gnome.org/show_bug.cgi?id=776990
* thumbnailer: Update from gnome-thumbnailer-skeleton masterPhilip Withnall2017-02-071-1/+6
| | | | | | | | | | | | | | | | | | | | https://github.com/hadess/gnome-thumbnailer-skeleton/commits/master Add some assertions to help Coverity From looking at the code, these assertions should always hold already, but it clarifies the code and helps static analysis if we add them explicitly. (n_pixels == 0) is only true if (s_x1 == s_x2 || s_y1 == s_y2), which is only true if (dx == 0 || dy == 0). This cannot be true, because dx and dy are the result of dividing source_[width|height] by dest_[width|height], and there’s already an assertion that the former are greater or equal to the latter. Coverity CID: 1388528 https://bugzilla.gnome.org/show_bug.cgi?id=776990
* io-xpm: Handle fseek() failurePhilip Withnall2017-02-071-1/+2
| | | | | | | | | If fseek() fails, the image is corrupt, and so the call to this get_buf function should fail. Coverity CID: 1388523 https://bugzilla.gnome.org/show_bug.cgi?id=776990
* io-ico: Add an assertion to clarify potential NULL pointer dereferencePhilip Withnall2017-02-071-2/+7
| | | | | | | | | | | | | | | | At a first read through, it looks like the call to OneLine() could end up dereferencing context->pixbuf when it’s NULL. However, due to a combination of other checks in the caller, OneLine() will only be called after DecodeHeader() has set context->pixbuf to a valid object. Otherwise, if DecodeHeader() bails with an error, the pixbuf will never be dereferenced. Add a comment trying to explain this, and an assertion which backs it up more rigorously. Coverity ID: 1388531 https://bugzilla.gnome.org/show_bug.cgi?id=777374
* gdk-pixbuf-io: Add precondition checks for image dimensionsPhilip Withnall2017-02-074-1/+30
| | | | | | | | | | | | | Refuse to save an invalid GdkPixbuf: one which has negative width, height or number of channels. This allows us to put assertions for all those properties in the I/O code, which helps static analysis not go off on one because it thinks the image width could be negative. Coverity ID: 1388534 https://bugzilla.gnome.org/show_bug.cgi?id=777374
* io-xbm: Fix potential overflows in read_bitmap_file_data()Philip Withnall2017-02-071-6/+22
| | | | | | | | | | ww and hh are both potentially tainted data (as they come from a potentially attacker controlled file), so we need to ensure that all arithmetic is bounds checked. Coverity ID: 1388540 https://bugzilla.gnome.org/show_bug.cgi?id=777374
* tests: Fix signed/unsigned handling in pixdata_equal()Philip Withnall2017-02-071-1/+5
| | | | | | | | | | The return values from the GdkPixbuf getters are signed, so assign them to signed variables and then check that the returned values are non-negative. Coverity IDs: 1388535, 1388536, 1388537 https://bugzilla.gnome.org/show_bug.cgi?id=777374
* thumbnailer: Update from gnome-thumbnailer-skeleton masterPhilip Withnall2017-02-071-0/+2
| | | | | | | | | | | https://github.com/hadess/gnome-thumbnailer-skeleton/commits/master Add version checks around g_type_init() call g_type_init() was deprecated (made unnecessary) in GLib 2.36.0, so don’t call it if we are compiled against a new enough version of GLib. https://bugzilla.gnome.org/show_bug.cgi?id=777315
* io-bmp: Add overflow checks to BMP image saverPhilip Withnall2017-02-072-4/+24
| | | | | | | | | | | | | | Return an error if the image width or height are too big to fit in the BMP size fields. This bumps our GLib dependency to 2.48.0, as it uses g_uint_checked_mul(). If you want to backport this fix, it’s probably best to use __builtin_umul_overflow() directly (if compiling using GCC or another compiler which supports it). Coverity ID: 1388532 https://bugzilla.gnome.org/show_bug.cgi?id=777315
* gdk-pixbuf: Fix overflow check in gdk_pixbuf_new()Philip Withnall2017-02-071-5/+6
| | | | | | | | | | | | | | | The recommended way to do an overflow check is to check against the limit you have in mind, rather than doing the calculation and seeing if it failed. Fix this by rearranging the check: move the variables we control (or have previously checked) over to one side, leaving the unknown variable on its own on the left-hand side. This ensures the overflow check doesn’t overflow itself. Coverity ID: 1388538 https://bugzilla.gnome.org/show_bug.cgi?id=777315
* Update zh_CN translationMandy Wang2017-02-051-130/+132
|
* build: Bump version for new functionalityBastien Nocera2017-02-031-1/+1
| | | | | | Now that scaling down by huge factors is fixed, we can deprecate the work-arounds from other libraries. This means they require the newer version, so bump the version so it's identifiable.
* tests: Add two-step scaler testMartin Guy2017-02-032-0/+342
| | | | | | | | Test the output of scaling functions to see whether optimisation/simplification to avoid huge memory and CPU usage is effective and does not regress. https://bugzilla.gnome.org/show_bug.cgi?id=80925
* tests: Move pixbuf creation helpers to test-common.[ch]Bastien Nocera2017-02-033-58/+60
| | | | | | Those will be used in the 2-step scaler tests. https://bugzilla.gnome.org/show_bug.cgi?id=80925
* pixops: Add two-step scaler optimizationMartin Guy2017-02-031-0/+156
| | | | | | | As scaling becomes incredibly slow at high reduction factors, detect the pathological cases and do the scaling in two steps instead. https://bugzilla.gnome.org/show_bug.cgi?id=80925
* Update French translationAlexandre Franke2017-02-031-54/+65
|
* Visual Studio builds: Fix project file move to win32/Chun-wei Fan2017-01-202-2/+2
| | | | | Some auxillary scripts and NMake Makefiles must have their paths updated also to work properly.
* Visual Studio builds: Move projects to win32/Chun-wei Fan2017-01-2050-474/+454
| | | | | | | | This moves the Visual Studio project files and related items under win32/ so that people can go one less directory layer down to the Visual Studio projects. This also makes things in sync with what is now on GLib and GTK+, and cleans up the Visual Studio 201x projects as some items can actually be combined.
* 2.36.42.36.4Matthias Clasen2017-01-162-2/+10
|
* gdk-pixbuf-scale: Add a fast path for a no-op scalePhilip Withnall2017-01-101-0/+7
| | | | | | | | If calling gdk_pixbuf_scale_simple() with equal src and dest dimensions, there’s nothing to do, so just return a copy of the src pixbuf. Document the new fast path. https://bugzilla.gnome.org/show_bug.cgi?id=442452
* docs: Document existing scaling and transformation fast pathsPhilip Withnall2017-01-101-0/+5
| | | | | | There are not many, as far as I can see. https://bugzilla.gnome.org/show_bug.cgi?id=442452
* docs: Document the alpha blending function usedPhilip Withnall2017-01-101-0/+6
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=442452
* docs: Use ‘alpha blending’ rather than ‘compositing’Philip Withnall2017-01-101-10/+12
| | | | | | | It’s a slightly more accurate term, as compositing seems to mostly refer to bit-mask composition of two images, rather than blending. https://bugzilla.gnome.org/show_bug.cgi?id=442452
* docs: Fix reference to a non-existent functionPhilip Withnall2017-01-101-1/+1
| | | | | | That one moved to gdk-pixbuf-xlib a while ago. https://bugzilla.gnome.org/show_bug.cgi?id=442452
* thumbnailer: Cleanup the cleanupsBastien Nocera2017-01-091-23/+6
| | | | | | | | | | | Commit 6afda9c removed the separate height and width arguments, as we always want to keep the original image's aspect ratio. The cleanup wasn't quite finished though, and ended up with slightly non-sensical checks (like doing comparisons twice). Coverity CID 1388524 https://bugzilla.gnome.org/show_bug.cgi?id=768062
* tests: Fix possible infinite loopsBastien Nocera2017-01-091-10/+21
| | | | | | | | | | | In the unlikely case that the just created pixbuf is invalid, the returned sizes would be negative. Ensure that those are positive to avoid possible infinite loops. Coverity CID 1391987 Coverity CID 1391988 https://bugzilla.gnome.org/show_bug.cgi?id=776945
* Updated Lithuanian translationAurimas Černius2017-01-071-55/+63
|
* 2.36.32.36.3Matthias Clasen2017-01-042-2/+12
|
* tests: Add more animations to area-updated testBastien Nocera2016-12-291-0/+2
|
* gif: Fix area-updated heightBastien Nocera2016-12-291-2/+2
| | | | | | | | The upper and lower bounds when an area is updated are inclusive coordinates, so the height would be upper - lower + 1, not upper - lower, which would exclude the upper line. https://bugzilla.gnome.org/show_bug.cgi?id=581484
* tests: Add test case for bug 581484Bastien Nocera2016-12-293-0/+131
| | | | | | | | This time for the GIF animation. Adapted from Andrey Tsyvarev's original animation test program. https://bugzilla.gnome.org/show_bug.cgi?id=581484
* ico: Small coding style cleanupBastien Nocera2016-12-291-3/+1
|
* ico: Fix area-updated coordinatesBastien Nocera2016-12-291-1/+7
| | | | | | | When the icon is constructed bottom to top, the y coordinates were incorrectly computed. https://bugzilla.gnome.org/show_bug.cgi?id=581484
* tests: Add test for bug 581484Bastien Nocera2016-12-292-0/+210
| | | | | | Adapted from Andrey Tsyvarev's original test program. https://bugzilla.gnome.org/show_bug.cgi?id=581484
* ico: Fix uninitialised alpha valuesBastien Nocera2016-12-293-1/+6
| | | | | | | | | | As we always create a GdkPixbuf with alpha, even if the original file doesn't have an alpha channel, or a mask, make sure to set the alpha pixel value in all cases, if only to have it overridden if there is a mask present. This makes it possible to use the reference test without having differing alpha values.
* tests: Fix non-sensical error in reftestBastien Nocera2016-12-291-4/+4
| | | | | | | | | The debug output was always printing the very first pixel of the line as both the reference and test data, leading to "useful" output like: Image data at 1x1 is #B16C42FF, but should be #B16C42FF Read the reference and test pixel values from the correct offset in the line to fix this.
* tests: Add failing test for bug 575217Bastien Nocera2016-12-281-0/+0
| | | | | | It currently errors out with "TGA image was truncated or incomplete". https://bugzilla.gnome.org/show_bug.cgi?id=575217
* tests: Add unsupported JPEG2000 fileBastien Nocera2016-12-281-0/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=685543
* jasper: Add debug output for unhandled imagesBastien Nocera2016-12-281-1/+24
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=685543
* tests: Fix a couple of mistakes in pixbuf-save-refBastien Nocera2016-12-281-7/+12
| | | | | Fix incorrect _close()/_get_pixbuf() call order, a possible g_object_unref() on a NULL pixbuf, and handling of GIF animations.
* tests: Fill the default pixbuf with the placeholder colourBastien Nocera2016-12-281-0/+5
| | | | | | | | | Ideally, we should only be comparing data that the loader told us it updated, and this is kind of what we're doing, as long as we don't have a legitimate image that uses the exact same filler colour. Unlikely though. https://bugzilla.gnome.org/show_bug.cgi?id=696331
* png: Initialise the created pixbufsBastien Nocera2016-12-281-0/+4
| | | | | | | | As we cannot easily detect truncated images when feeding data piecemeal, initialise the empty image to avoid reading uninitialised memory where we could not fill the pixbuf. https://bugzilla.gnome.org/show_bug.cgi?id=696331
* gdk-pixbuf: Add constant for "default fill"Bastien Nocera2016-12-281-0/+3
| | | | | | | This colour should be used to complete truncated images, rather than using random garbage from uninitialised memory. https://bugzilla.gnome.org/show_bug.cgi?id=696331
* tests: Add test for bug 696331Bastien Nocera2016-12-282-0/+0
| | | | | | | | This compares a broken file, which might have random data inside the part of the image that was missing from the file, with our version which will have a flat colour instead. https://bugzilla.gnome.org/show_bug.cgi?id=696331
* tests: Add small tool to save a reference imageBastien Nocera2016-12-282-0/+103
| | | | | | | | This makes it easier to create a reference image after a bug has been fixed. Reverting the fix is enough to show that the reftest fails without it. https://bugzilla.gnome.org/show_bug.cgi?id=696331
* io: Fix typo in documentation ( "the the" -> "the" )vrishab2016-12-282-6/+6
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=776457
* io: Fix incorrect documentationvrishab2016-12-281-3/+3
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=776457
* thumbnailer: Add $(EXEEXT) to the the gdk-pixbuf-print-mime-typesSebastian Dröge2016-12-281-1/+1
| | | | | | | Fixes the build on Windows and elsewhere, where there's a filename extension for executables https://bugzilla.gnome.org/show_bug.cgi?id=776432
View Lorry Controller Status