GNOME Bugzilla – Bug 90621
patch for integer pixops
Last modified: 2014-10-22 12:50:51 UTC
The floating point code used for pixel scaling is painful to use on a machine with no hardware FP. This patch adds the option to use fixed point maths instead, with 16 bits of fraction.
Created attachment 10455 [details] [review] patch to add integer pixops implementation
Created attachment 13664 [details] [review] updated version of patch
Upgrading the priority level to High due to the attached patches.
This is pretty interesting. Could you please cook a little benchmark program to show how much this helps on certain architectures? We could have some configure.in magic that enables this unconditionally on ARM and other fp-less architectures if the benchmark shows that it really helps there.
It would also be good to have code that compares the results of scaling with FP versus fixed-point.
I'd be happy to test it on my ARM hardware, but an updated version for gtk 2.6 or newer would be required.
Created attachment 78823 [details] [review] reworked version of patch This reworked version applies against 2.10.6, but the function arguments of *make_weights() have changed in the last 3 years, so someone familiar with the pixops.c code should have a look at that.
Raised some awareness for this at http://mail.gnome.org/archives/performance-list/2007-February/msg00006.html and http://lists.openmoko.org/pipermail/openmoko-devel/2007-February/000286.html Let's hope it doesn't take another 4 and a half year to get this patch noticed again.
Created attachment 82371 [details] [review] New attempt at creating a patch I tried creating a patch to convert FP operations to integer ones. This can be applied to latest 2.10 version (as of this date). Instead of rewriting code blocks, I decided to take the approach of using macro preprocessors to change types and implement normalization. In this attempt, two normalizers for doubles are used: one for most double types (based on FRAC) and one for overall_alpha (which has been implemented to use 255). The patched source compiles, but have some problems. The ones I'm aware of are 1) images get shifted to the upper right-hand corner when scale is > 1.0 and the amount of shifting is proportional to scale's closeness to 1.0; 2) when scale < 1.0, pixels in close proximity to different colored ones aren't computed properly. This is likely to do with the loss of precision when normalizing, but may be something else. This attempt was done to support the OpenMoko project.
(In reply to comment #9) In case you did one, could you please attach any test case that shows this functions are a bottleneck for pixbuf operations in FPU-less platforms?
(In reply to comment #10) > (In reply to comment #9) > In case you did one, could you please attach any test case that shows this > functions are a bottleneck for pixbuf operations in FPU-less platforms? Does gtk+ have something like cairo-perf? Timetext.c only tests textspeed and theme-torturer-git is broken.
Times in seconds: Stock 2.10.9 2.10.9+plana-pixops mean 12,202095 16,114419 stdev 0,044377 1,091860 so it actually got slower when testing with openembedded.org/repo/org.openembedded.dev/packages/gtk+/pixops-test/pixops-test.c
given that 10+ years passed since this bug was filed, and 7 passed from the last comment — which actually provided a point against applying the functionality in question — and that architectures without an FPU are increasingly rare, these days, I think it's safe to close this as WONTFIX.