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
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.