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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.