RE: render.c:GetPixelOpacity() optimization ideas?
Bill Radcliffe <[email protected]>
| Newsgroups | gmane.comp.video.graphicsmagick.core |
|---|---|
| Message-ID | <306F012D0A00D611BC9D0008C79192740D12F21D@seamail1.continuum.corbis.corp> |
I believe that the code you talking about is dealing with anti-aliasing. I can say for sure, the there is an assumption in that code that floating point is no more expensive then integer math, which is largely true on any the usual CPU's we run on. Other can weigh in on this, but you could probably generalize this assumption out to the entire package. Most of the code does not hesitate to use floating point were integer might do just as well. I am certain there are some exceptions, so don't jump all over me with those. I am just talking broad brush. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Wolfgang Spraul Sent: Thursday, January 15, 2004 3:51 PM To: [email protected] Subject: [GM-core] render.c:GetPixelOpacity() optimization ideas? 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 _______________________________________________ Graphicsmagick-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core ------------------------------------------------------- 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