summaryrefslogtreecommitdiff
path: root/gdk/loaders
Commit message (Collapse)AuthorAgeFilesLines
* texture: Export gdk_texture_get_format()Benjamin Otte2023-02-152-2/+0
| | | | | | | | | | The API docs outline why quite well. This should make it possible to do saving of textures to image files without any private API with the same featureset that GTK uses. Also remove the gsktextureprivate.h include where gdk_texture_get_format() was the only reason for it.
* tiff: Use GdkTexureDownloader when savingBenjamin Otte2023-02-151-10/+13
|
* png: Use GdkTexureDownloader when savingBenjamin Otte2023-02-151-10/+13
|
* jpeg: Use GdkTexureDownloader when savingBenjamin Otte2023-02-151-8/+10
|
* gdk: Fix possible memory errorsMatthias Clasen2022-11-181-2/+3
| | | | | | | clang complained that we may end up jumping to the cleanup code without initializing data in the jpeg code. Always initialize data to NULL to prevent that eventuality.
* gdk: Bump the jpeg malloc limitMatthias Clasen2022-10-311-1/+2
| | | | | Bump the limit for memory use during jpeg loading to 1GB, matching what gdk-pixbuf has for this.
* Drop gdkintl.hMatthias Clasen2022-09-233-3/+3
| | | | | This header was merely including gi18n-lib.h. Just do that directly.
* Bump the jpeg memory limitMatthias Clasen2022-08-221-2/+2
| | | | | | | Commit 59f6c50df8d4d9 set the memory limit to 100M, which turns out to exclude some large, valid jpegs. So, bump things to 300M, matching what was done in gdk-pixbuf.
* jpeg loader: Limit memory consumptionMatthias Clasen2022-08-101-0/+5
| | | | | | This will prevent stupid oom situations with pathological jpeg files, without affecting our ability to load reasonable images.
* png loader: gray can have alphaMatthias Clasen2022-07-161-1/+2
|
* gdkjpeg: include `stdlib.h` necessary for `free`Mosè Giordano2022-02-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | `free` is defined in `stdlib.h`, see for example <https://pubs.opengroup.org/onlinepubs/009604499/functions/free.html>. Without this include compilation can fail with the following error: ``` ../gdk/loaders/gdkjpeg.c: In function ‘gdk_save_jpeg’: ../gdk/loaders/gdkjpeg.c:264:7: warning: implicit declaration of function ‘free’ [-Wimplicit-function-declaration] free (data); ^ ../gdk/loaders/gdkjpeg.c:264:7: warning: incompatible implicit declaration of built-in function ‘free’ ../gdk/loaders/gdkjpeg.c:264:7: note: include ‘<stdlib.h>’ or provide a declaration of ‘free’ ../gdk/loaders/gdkjpeg.c:302:67: error: ‘free’ undeclared (first use in this function) return g_bytes_new_with_free_func (data, size, (GDestroyNotify) free, NULL); ^ ../gdk/loaders/gdkjpeg.c:302:67: note: each undeclared identifier is reported only once for each function it appears in ../gdk/loaders/gdkjpeg.c:303:1: warning: control reaches end of non-void function [-Wreturn-type] } ^ ```
* png: Correct endianness for big-endian machinesSimon McVittie2022-01-081-16/+0
| | | | | | | | | | | | | | | | libpng wants to receive samples in either RGB or RGBA order, whether each sample is big-endian or not. This resolves test failures in testsuite/gdk/memorytexture.c (and a lot of reftests) on s390x, and probably the PowerPC family too. Modifying the test to show the color in use and write out the PNG bytes to a file, and running the memorytexture test on s390x, produces a PNG that loads with the correct color values in GIMP (on an x86_64 machine), which seems like evidence that this is the correct change and not just compensating errors. Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/4616 Signed-off-by: Simon McVittie <smcv@debian.org>
* tiff loader: Catch more errorsMatthias Clasen2021-12-131-1/+8
| | | | | tiff_open_read may fail, and we should not crash in that case but return an error.
* Fix minor typo: Unsupportd -> UnsupportedYuri Chornoivan2021-11-051-1/+1
|
* png: allocate data before sigsetjmp()Benjamin Otte2021-10-231-2/+2
| | | | | Makes the static analyzer not trip up when trying to analyze memory leaks.
* tiff: Fix variable assignmentBenjamin Otte2021-10-221-2/+3
|
* jpeg: Use gdk_memory_texture_from_texture()Benjamin Otte2021-10-181-39/+12
|
* tiff: RefactorBenjamin Otte2021-10-181-94/+59
| | | | Now we support all the formats.
* png: Refactor png savingBenjamin Otte2021-10-131-103/+36
| | | | | Do all the memory format shenanigans in GTK now and support all the PNG formats.
* Add memory formats used by libpngBenjamin Otte2021-10-131-28/+4
| | | | | Add unpremultiplied high-depth formats. They are used in the real world, so let's support them.
* png: Do loader conversions in GDKBenjamin Otte2021-10-121-81/+22
| | | | | | | Not inside libpng. We really want to do them in GL, but we don't have a premultiply step yet.
* texture: Refactor downloadingBenjamin Otte2021-10-122-4/+4
| | | | | | | | | | | Pass a format do GdkTextureClass::download(). That way we can download data in any format. Also replace gdk_texture_download_texture() with gdk_memory_texture_from_texture() which again takes a format. The old functionality is still there for code that wants it: Just pass gdk_texture_get_format (texture) as the format argument.
* Rename ngl to glMatthias Clasen2021-10-071-1/+1
| | | | | We have only one gl renderer now, and it is a bit odd for it not be called gl.
* texture: Make format a property of GdkTextureBenjamin Otte2021-10-072-2/+2
| | | | | | | | | | | For MemoryTexture, this is a simple change. For GLTexture, we need to query the format at texture creation. This sounds like a bad idea and extra work until one realizes that we'd need to do that anyway when using the texure the first time - either when downloading, or when trying to use it in a rendernode, where we will soon need that information to determine if the texture prefers high depth.
* memorytexture: Split out GdkMemoryFormat handlingBenjamin Otte2021-10-062-0/+2
| | | | | | | Also, now make gdk_memory_convert() the only conversion functions and allow conversions between any 2 formats by going via a float[4]. This could be optimized via fast-paths, but so far it isn't.
* gdk loaders: Add noreturn attribtues where appropriateTimm Bäder2021-10-022-2/+2
|
* Merge branch 'delayed-loading' into 'master'Matthias Clasen2021-09-183-1/+24
|\ | | | | | | | | gtk-demo: Cosmetics See merge request GNOME/gtk!3975
| * loaders: Add profiler marksMatthias Clasen2021-09-183-1/+24
| | | | | | | | | | These are potentially expensive calls, we should make sure they show up in profiles.
* | gdktiff: Use guint32 instead of int32Timm Bäder2021-09-181-1/+1
|/ | | | The latter seems to be deprecated.
* texture: Rework error enumBenjamin Otte2021-09-173-34/+26
| | | | | | | | | | | 1. Change INSUFFICIENT_MEMORY to TOO_LARGE GTK crashes on insufficient memory, we don't emit GErrors. 2. Split UNSUPPORTED into UNSUPPORTED_CONTENT and UNSUPPORTED_FORMAT So we know if you need to find an RPM with a loader or curse and the weird file. 3. Translate error messages, they are meant for end users.
* Support 16bit formats in the png loaderMatthias Clasen2021-09-171-25/+161
| | | | | | | | When loading, convert all >8-bit data to GDK_MEMORY_R16G16B16A16_PREMULTIPLIED. When saving, save all 8-bit formats as 8-bit RGBA, and save all >8-bt formats as 16-bit RGBA.
* Add code to save jpegsMatthias Clasen2021-09-172-11/+196
|
* texture: Split out type detectionBenjamin Otte2021-09-173-0/+38
| | | | | | This way, the code using it becomes clearer and we can use it in multiple places without accidentally doing it wrong (hint: see next commit).
* Add code to load jpegsMatthias Clasen2021-09-172-0/+175
| | | | | | | This lets us avoid gdk-pixbuf for loading textures from the common image formats. As a consequence, we are now linking against libjpeg.
* Add code to load and save tiff filesMatthias Clasen2021-09-172-0/+543
| | | | | | | | Add support for the tiff format, which is flexible enough to handle all our memory texture formats without loss. As a consequence, we are now linking against libtiff.
* Add code to load and save pngsMatthias Clasen2021-09-172-0/+473
Using libpng instead of the lowest-common-denominator gdk-pixbuf loader. This will allow us to load >8bit data, and apply gamma and color correction in the future. For now, this still just provides RGBA8 data. As a consequence, we are now linking against libpng.
View Lorry Controller Status