Leo Breebaart
asked on
Alternatives for LineTo() ?
I am the author of an After Dark freeeware screensaver
module called 'The Swarm' which is a straightforward port of
the classic Unix 'xswarm' program. (You can go to
http://www.cp.tn.tudelft.nl/leo/kronto.html for some
screenshots of the module, or for downloading it).
The bees in the swarm are simply coloured line segments.
Every frame of the animation, I draw the bees into a GWorld,
I calculate the enclosing rectangle of the entire swarm, and
I blit that onto the real screen using CopyBits (after
blacking out the previous frame's rectangle first).
This approach yields acceptable performance for
not-too-large swarms, even on 68k machines. However, what
has always been bugging me about my implementation from the
very beginning, is that if I profile the code it turns out
that in a frame of the animation the most time is *not*
spend on the two CopyBits calls (as I had been expecting),
but rather on the LineTo calls used to draw the individual
bee line segments.
I find it hard to believe that drawing twenty or thirty line
segments into a GWorld would be that performance-intensive
(and it is not the function call overhead either, I've
checked that).
So, can anybody out there explain to me *why* LineTo is so
computation-intensive, or better yet: suggest an alternative
approach for drawing lines that might yield better results?
module called 'The Swarm' which is a straightforward port of
the classic Unix 'xswarm' program. (You can go to
http://www.cp.tn.tudelft.nl/leo/kronto.html for some
screenshots of the module, or for downloading it).
The bees in the swarm are simply coloured line segments.
Every frame of the animation, I draw the bees into a GWorld,
I calculate the enclosing rectangle of the entire swarm, and
I blit that onto the real screen using CopyBits (after
blacking out the previous frame's rectangle first).
This approach yields acceptable performance for
not-too-large swarms, even on 68k machines. However, what
has always been bugging me about my implementation from the
very beginning, is that if I profile the code it turns out
that in a frame of the animation the most time is *not*
spend on the two CopyBits calls (as I had been expecting),
but rather on the LineTo calls used to draw the individual
bee line segments.
I find it hard to believe that drawing twenty or thirty line
segments into a GWorld would be that performance-intensive
(and it is not the function call overhead either, I've
checked that).
So, can anybody out there explain to me *why* LineTo is so
computation-intensive, or better yet: suggest an alternative
approach for drawing lines that might yield better results?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
own LineTo function which draws directly to the bitmap".
Fair enough, but I do think I would have appreciated a slightly more helpful answer than "for color its a bit more complicated but you can figure it out"...
Also, he didn't really answer the part of my question that
asked *why* LineTo is so slow. "It does other things", he says. Like WHAT??? Why doesn't Apple provide an optimized line-drawing
routine of their own? What's the bottleneck in LineTo? Won't I run into the same bottleneck if I naively start to implement
my own version?
With this in mind I have to say that although Adam's answer is useful as confirmation of what I already suspected, it's not *quite* as helpful an answer as I had been hoping for.