RE: render.c:GetPixelOpacity() optimization ideas?

On Thu, 15 Jan 2004, Bill Radcliffe wrote:

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

This is a true statement.  ImageMagick was originally developed on
expensive RISC-powered workstations (and even Cray's) that were
optimized for floating point.  In recent years "PC" hardware has
improved its floating point considerably so use of floating point has
stopped being much of a penalty (if at all) on common hardware.

As long as the arithmetic is carefully coded to avoid overflow or
innaccurate results (can be a challenge), I have no problem with using
integer math in key inner loops.  That is why the magick_types.h
header was added to GM and why we have converted small amounts of code
(e.g.  PixelIntensity()) to use integer math.

GetPixelOpacity() has always been a bottleneck so any performance
enhancements to it would be valuable.

Bob

> -----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
> _______________________________________________
> Graphicsmagick-core mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/graphicsmagick-core
>

======================================
Bob Friesenhahn
[email protected]
http://www.simplesystems.org/users/bfriesen



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