After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 516401 - gdk_pixdata_to_csource does not always add a macro for rle stream decoding to the code
gdk_pixdata_to_csource does not always add a macro for rle stream decoding to...
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other All
: Normal normal
: ---
Assigned To: gdk-pixbuf-maint
Depends on:
Reported: 2008-02-14 09:58 UTC by Andrey Tsyvarev
Modified: 2014-10-21 17:39 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Andrey Tsyvarev 2008-02-14 09:58:29 UTC
Please describe the problem:
When gdk_pixdata_to_csource is called with both GDK_PIXDATA_DUMP_RLE_DECODER and GDK_PIXDATA_DUMP_PIXDATA_STREAM flags set, the *_RUN_LENGTH_DECODE macro is missing from the generated C code ("*" is the value of "name" parameter, e.g. "MY_IMAGE") 

If GDK_PIXDATA_DUMP_RLE_DECODER flag is used with GDK_PIXDATA_DUMP_PIXDATA_STRUCT or GDK_PIXDATA_DUMP_MACROS flags (defining other forms of C source to be generated), *_RUN_LENGTH_DECODE macro is successfully generated.

But description of the GDK_PIXDATA_DUMP_RLE_DECODER flag states that *_RUN_LENGTH_DECODE macro have to be generated if the flag is set regardless of values of other flags. 

The detailed bug description can be found at:

Steps to reproduce:

Actual results:

Expected results:

Does this happen every time?

Other information:
Comment 1 Bastien Nocera 2014-10-21 17:39:18 UTC
GdkPixdata is deprecated, please port to GResource instead.

commit 48d76fb7f2d059013f5781b199245274998f05c9
Author: Bastien Nocera <>
Date:   Tue Oct 21 19:24:11 2014 +0200

    lib: Deprecate GdkPixdata
    GdkPixdata has a number of problems, including:
    - it doesn't use the original files, losing metadata
    - its RLE compression is ineffecient, even more so for lossy formats
    - the way it's implemented doesn't support data > 64 kB on Windows