summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* build: Fix generating .pc file when using builtin loader(s)fix-generating-pc-filesChun-wei Fan2019-08-012-6/+22
| | | | | | | | | | | | | The current Meson build files define built-in loader(s) as a dependency to libgdkpixbuf, which has an undesired side effect of making them required by GDK-Pixbuf's pkg-config file, which renders build systems that consume this pkg-config file output bad build files. This fixes this by: -Make libgdkpixbuf depend on the objects that are built for those loader(s), when the loader(s) are built into libgdkpixbuf. -Include the external dependencies of these built-in loaders, if applicable, such as libpng etc., as dependencies of libgdkpixbuf.
* 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
|
* meson.build: Don't use fallback dep for libpng unnecessarilyChun-wei Fan2019-07-291-4/+6
| | | | | | We could have well found the headers and .lib's needed for libpng, so only use the fallback wrapper for libpng when we couldn't find the headers and .lib's.
* 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.
* tests: Disable deprecation warnings for GTimeValEmmanuele Bassi2019-07-292-0/+2
|
* 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.
* Update Basque translationAsier Sarasua Garmendia2019-07-211-189/+87
|
* Remove uses of g_memmove()Emmanuele Bassi2019-06-292-2/+2
| | | | | | | | | 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.
* Use the appropriate gdk-pixbuf-query-loaders on post-installEmmanuele Bassi2019-06-293-7/+11
| | | | | | | We should not rely on the installation prefix being part of PATH, but is the location of the binary used by the build system. Fixes: #126
* Update Croatian translationGoran Vidović2019-03-261-51/+55
|
* Update Catalan translationJordi Mas2019-03-101-383/+234
|
* Update French translationGuillaume Bernard2019-03-061-57/+63
|
* Update Brazilian Portuguese translationRafael Fontenelle2019-03-061-56/+61
|
* Update German translationTim Sabsch2019-03-051-61/+72
|
* 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
* Updated Danish translationAlan Mortensen2019-03-051-49/+53
|
* Update Hungarian translationBalázs Meskó2019-03-041-53/+56
|
* Update Korean translationGwan-gyeong Mun2019-03-041-50/+54
|
* Update Friulian translationFabio Tomat2019-03-041-51/+55
|
* Updated Spanish translationDaniel Mustieles2019-03-041-53/+57
|
* Update Italian translationMilo Casagrande2019-03-041-60/+57
|
* Update Galician translationFran Dieguez2019-03-031-55/+58
|
* Updated Czech translationMarek Cernocky2019-03-031-55/+59
|
* Updated Lithuanian translationAurimas Černius2019-03-031-54/+58
|
* Update Latvian translationRūdolfs Mazurs2019-03-031-53/+57
|
* Update Dutch translationNathan Follens2019-03-031-50/+54
|
* Updated Slovenian translationMatej Urbančič2019-03-021-52/+56
|
* Update Romanian translationDaniel Șerbănescu2019-03-021-51/+55
|
* Update Turkish translationEmin Tufan Çetin2019-03-021-54/+58
|
* Update Polish translationPiotr Drąg2019-03-011-53/+57
|
* Update Serbian translationМарко Костић2019-03-011-51/+55
|
* Update Swedish translationAnders Jonsson2019-03-011-53/+57
|
* Update Indonesian translationKukuh Syafaat2019-03-011-52/+60
|
* tests: Add test image for invalid XPM dataBastien Nocera2019-03-012-0/+68
|
* 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.
* tests: Add test for issue 95Bastien Nocera2019-03-011-0/+34
| | | | A laaaarge XPM file.
* meson: Also add wrap files for fallback dependenciesNirbheek Chauhan2019-02-283-0/+16
|
* meson: Add subproject fallbacks for all dependenciesNirbheek Chauhan2019-02-282-9/+30
| | | | | This is needed to build gtk+ and all dependencies from scratch on Windows with meson subprojects.
* core: Fix split docs line in features.h fileBastien Nocera2019-02-281-2/+1
|
View Lorry Controller Status