GNOME Bugzilla – Bug 80927
Special-case compositing/copying with no scaling
Last modified: 2014-10-22 17:10:00 UTC
gdk_pixbuf_composite_* and gdk_pixbuf_scale always run through the scaling code path, even when the scale factor in both directions is 1... for this common case, presumbably big wins could be found by adding a non-scaling code path.
Would be nice to have for 2.2, though not essential. I have a bunch of code for this around that could possibly be used.
How about sticking your code in here, so that we can try to get it in for 2.2 ?
The code in question can be found at: http://people.redhat.com/otaylor/misc/composite-funcs-0.1.tar.gz
I don't think this ends up being a big bottleneck in most places, partly becuase there is special-cased composite-without-scale code in GDK for alpha-compositing pixbufs.
It may not be so much of a bottleneck, but it would prevent one particular case where the behaviour of gdk_pixbuf_scale seems a little off... I speak of calling the function with GDK_INTERP_HYPER and scale values of 1.0. The image returned becomes noticeably blurred, even though no scaling has actually taken place! Maybe this is the responsibility of the app developer to avoid, but no warnings are apparent in the docs that the "best" method of scaling sometimes isn't all that ;-)
I have a lame patch for this that I wrote against gdk-pixbuf 0.16.0 in 2002. It probably needs a little work (using epsilon in the scale factor check, for instance). Anyway, I'm attaching it in case it's of any use.
Created attachment 54605 [details] [review] Avoid scaling if possible, C code only.
I ran a test back then too, compositing a 128x128 pixbuf on top of another pixbuf of the same size without scaling, repeatedly. Before patch: 17 seconds on CPU After patch: 13 seconds on CPU Which indicates there's at least some gain.
Looks like a worthwhile addition to me. Did anyone ever look at this patch?
I've pushed this patch, along with the naive == 1.0 checks for the scaling factor. We can eventually take care of that in a subsequent patch, which would hopefully take less than 9 years to handle.
*** Bug 496306 has been marked as a duplicate of this bug. ***