render.c:GetPixelOpacity() optimization ideas?
Wolfgang Spraul <[email protected]>
| Newsgroups | gmane.comp.video.graphicsmagick.core |
|---|---|
| Organization | Q AG |
| Message-ID | <[email protected]> |
I am running GraphicsMagick on an ARM processor without a hardware floating point unit (i.e. calculations of type double are done in software). I noticed that when I run the drawtest sample code, I spend about 80% of the total time in just one function, magick/render.c:GetPixelOpacity(). GPO (GetPixelOpacity) is doing quite a number of calculations with variables of type double. That's where most of the time is spent. It seems to me that while GPO is a good general-purpose implementation, it certainly wastes an enormous amount of processing power for "simple" cases, for example if all I want to render is a solid-color horizontal or vertical line or rectangle. Does anybody have ideas/patches for GPO optimizations? Have there been more optimized GPO versions in the past (let's say 5 years ago)? (I'm asking because I doubt many machines would have been able to handle the enormous amount of double calculations for relatively simple drawing primitives back then) Would it be possible to identify some of the variables in GPO as constants when rendering certain primitives (let's say solid color, no aliasing, etc)? And then implement several GPO versions and choose the one that is just flexible enough but lets the compiler make use of the constants. Would it be possible (are there patches) to convert some of the calculations from type 'double' to type 'integer'? Would it be possible to modify the next higher function, DrawPolygonPrimitive() to call GPO less/much less in certain cases? Regards, Wolfgang ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn