[Kstars-devel] timing integer vs. floating-point drawing operations

[James Bowlin]

On Sunday 11 June 2006 11:26, Jason Harris wrote:
> One might argue that the hackish way I've implemented integer pixel values (by 
> using an int() cast at the last possible moment) is making that code pathway 
> slower than it needs to be, but I think this is the way it has to be done.

I do think the conversion to int at the last moment is not a fair test
because the floating point registers will need to be used for both sky
coordinates and screen coordinates while in a scenario where all screen
calculations are int there is a chance for a more efficient use of the
registers.

On the other hand: 
>the screen takes 1.2 sec for  a full draw (on my hardware).  With it
>off, it takes 0.2 sec. 

A factor of six speed improvement!  If anti-aliasing is now on and you're
giving us a switch to turn it off, this may well solve all of our current
speed problems for now.
 
> Any thoughts?  Otherwise, I'll probably discard my integer-pixel changes (but 
> I will commit the useAntialias option).

This sounds good.  I can't wait to be able to hit the "A" button (perhaps it
should be "T" for turbo).  If the speed of 4.0 with no anti-aliasing still
significantly lags behind the speed of 3.5.x then perhaps we would want to
put timing code in both versions (just add it to the 3.5.x branch) so we can
compare the speed of both versions numerically.  I think it would be really
good if the 4.0 version can at least as fast as if not faster than the 3.5.x
version. Otherwise, people with slower machines would have reason to complain.

If we lose 20% or so in speed using QPointF's, I am not concerned because I
think we can gain a least a factor of 2 (and often more) with a spatial index.


-- 
Peace, James