GNOME Bugzilla – Bug 513812
Optimize gdk_cairo_set_source_pixbuf() alpha multiplication loop
Last modified: 2013-09-09 16:08:46 UTC
Attaching python code showing how the alpha multiplication loop in gdk_cairo_set_source_pixbuf() can be optimized. It also "fixes" the formula, which is a bit wrong for some cases. I'm not sure how the branch mipacts performance, but it may be a good idea to special case alpha=0 and alpha=255. The optimization shown in the code is real regardless.
Created attachment 104232 [details] sample code
Created attachment 104234 [details] Updated code
Also see this thread: http://lists.cairographics.org/archives/cairo/2008-February/012958.html
So, setting the issue of optimization aside, could the formula for conversion be fixed ? Sure, it's wrong in a very low number of cases and it doesn't seem to get worse with iterated cairo_surface -> GdkPixbuf conversions, but this code tends to get cargo culted. *Please* ?
You know what's both amusing and annoying about this little problem ? About every other part of gtk already uses the correct formula. in gtk+-2.24: i.e. in gdk/gdkdraw.c - static void composite (guchar *src_buf, gint src_rowstride, guchar *dest_buf, gint dest_rowstride, gint width, gint height) in gdk-pixbuf 2.26: i.e. in gdk-pixbuf/pixops/pixops.c - pixops_composite_nearest
(In reply to comment #5) > You know what's both amusing and annoying about this little problem ? Maybe you can change your tone, and instead of sounding like a troll (and getting ignored), raise the same points in a constructive conversation kind of way. Maybe someone would then take a few minutes to use your messages to convince themselves that the fix is correct, and commit it. > About every other part of gtk already uses the correct formula. > > in gtk+-2.24: i.e. in gdk/gdkdraw.c - static void composite (guchar *src_buf, > gint src_rowstride, guchar *dest_buf, gint dest_rowstride, gint width, gint > height) > in gdk-pixbuf 2.26: i.e. in gdk-pixbuf/pixops/pixops.c - > pixops_composite_nearest
Perhaps if anyone was wiling to listen instead of being sure they were right those five or so years ago... I already said that both the originally referenced article *and* pixman code confirm this. Now, it's even gtk+ code that does. See also https://bugs.freedesktop.org/show_bug.cgi?id=4096 and its result: http://cgit.freedesktop.org/cairo/commit/src/cairo-png.c?id=b9da101879afc6ab960e43f94d1e0a2fc10b3aac I *can* be rational, if the other party also is.
(In reply to comment #7) > I *can* be rational, if the other party also is. Right now there is no other party. If you are talking to me, I clearly said multiple times that I don't have time for this. And I have not seen any behavior from any other gtk+ developer on this bug that you can call irrational.
We're basically talking about a typo/thinko fix and the resistance is as if it was a core change.
Created attachment 249031 [details] [review] the oneline fix ...technically, it's a patch, but seriously...
Ok, I convinced myself that the oneline fix is correct. Pushed to master.
(In reply to comment #11) > Ok, I convinced myself that the oneline fix is correct. Pushed to master. As I said on irc: thank you, but for completeness, this should be picked into 2.24 too.
I don't know where the 2.24 branch is these days.
gtk-2-24, in the gtk+ repository.
Thanks. Pushed.