GNOME Bugzilla – Bug 589334
Area-prepared signal in pixbuf loader
Last modified: 2014-10-22 13:24:49 UTC
Please describe the problem: Pixbuf loader documentation says that the "area-prepared" signal can be used to fill the buffer with background color. This does not work for xpm loader, because the signal is emitted too late, when the buffer already contains image data. The original report is here: https://sourceforge.net/tracker/index.php?func=detail&aid=2824016&group_id=222125&atid=1054680 svg loader has the same problem: http://bugzilla.gnome.org/show_bug.cgi?id=547669 It should be either fixed or maybe some flag should be added to loaders which don't support this feature. Steps to reproduce: 1. view xpm file with geeqie 1.0 beta2 Actual results: I see black image (pixbuf filled with zeros) Expected results: see the image content Does this happen every time? Other information:
A few of the loaders have that problem indeed. We have 2 options, either extend the "area-prepared" (and thus the "prepare_func" vfunc) to tell the application that the data was already filled in, or change the documentation to not say it is safe. Given that filling the background of the pixbuf in the "area-prepared" signal handler will not work except for full or no alpha (if you have semi-transparent red as the background, it won't be composited with the loaded image), I'd rather do the second one. It should be easy enough to modify the image after it's been loaded to composite the background color. It might even be better to have the widget draw its background and let the toolkit take care of compositing it properly. commit 87e1bedb668c66377681b2e3ba8e04c158723619 Author: Bastien Nocera <hadess@hadess.net> Date: Wed Oct 22 15:20:46 2014 +0200 lib: Remove incorrect info about area-prepared signal It is not safe to fill the pixbuf returned from area-prepared with a background colour as a number of loaders (notably XPM and SVG) will only have information about the size and characteristics of the image after it's been fully loaded. Filling the background colour would then overwrite the image we just loaded. Given that this won't work properly with anything but 100% transparent or 100% solid pixels, remove that advice from the docs. Instead, applications should rely on their toolkits to composite over a background colour. https://bugzilla.gnome.org/show_bug.cgi?id=589334