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 90621 - patch for integer pixops
patch for integer pixops
Status: RESOLVED WONTFIX
Product: gdk-pixbuf
Classification: Platform
Component: general
git master
Other All
: Normal enhancement
: ---
Assigned To: gdk-pixbuf-maint
gdk-pixbuf-maint
Depends on:
Blocks:
 
 
Reported: 2002-08-13 09:50 UTC by Phil Blundell
Modified: 2014-10-22 12:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to add integer pixops implementation (7.17 KB, patch)
2002-08-13 09:51 UTC, Phil Blundell
none Details | Review
updated version of patch (8.56 KB, patch)
2003-01-18 19:06 UTC, Phil Blundell
needs-work Details | Review
reworked version of patch (10.19 KB, patch)
2006-12-23 09:07 UTC, Koen Kooi
none Details | Review
New attempt at creating a patch (18.77 KB, patch)
2007-02-12 08:16 UTC, Richi Plana
none Details | Review

Description Phil Blundell 2002-08-13 09: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.
Comment 1 Phil Blundell 2002-08-13 09:51:20 UTC
Created attachment 10455 [details] [review]
patch to add integer pixops implementation
Comment 2 Phil Blundell 2003-01-18 19:06:34 UTC
Created attachment 13664 [details] [review]
updated version of patch
Comment 3 alexander.winston 2004-01-03 16:22:30 UTC
Upgrading the priority level to High due to the attached patches.
Comment 4 Federico Mena Quintero 2006-08-09 16:25:12 UTC
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.
Comment 5 Federico Mena Quintero 2006-08-09 16:26:27 UTC
It would also be good to have code that compares the results of scaling with FP versus fixed-point.
Comment 6 Koen Kooi 2006-08-27 08:25:58 UTC
I'd be happy to test it on my ARM hardware, but an updated version for gtk 2.6 or newer would be required.
Comment 7 Koen Kooi 2006-12-23 09:07:43 UTC
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.
Comment 8 Koen Kooi 2007-02-10 10:32:26 UTC
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.
Comment 9 Richi Plana 2007-02-12 08:16:35 UTC
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.
Comment 10 Xan Lopez 2007-02-13 05:57:17 UTC
(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?
Comment 11 Koen Kooi 2007-02-13 07:46:03 UTC
(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.
Comment 12 Koen Kooi 2007-02-14 11:22:54 UTC
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

Comment 13 Emmanuele Bassi (:ebassi) 2014-10-22 12:50:51 UTC
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.