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

[Jason Harris]

On Sunday 11 June 2006 12:26, James Bowlin wrote:
> 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.
>
The problem is that there's no way to "natively" work with integer math when 
computing the screen coordinates.  I mean, I could implement a version of 
toScreen() that returns a QPoint instead of a QPointF, but that function 
would necessarily contain int() casts for the construction of the QPoint, 
because the X and Y values are the product of spherical trig...they simply 
have to be floating-point.  I don't think it matters when we cast to int(), 
it's still going to have the same impact.  Anyway, it was my impression that 
it was the QPainter drawing code itself that might be faster if it could use 
integer math, but apparently that's not the case, because I'm using the 
integer versions of drawEllipse(), drawLine(), drawText(), etc, and they 
aren't significantly faster.

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

It solves it for now, as you say.  We're still slower than 3.5 branch.

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

I agree.  In fact, for me it's a requirement that the release version for 
KDE-4.0 be at least as fast as the 3.5 version.  I don't know why it's 
slower; maybe it's the SkyComponents infrastructure, maybe it's some 
undiscovered bug, maybe it's a non-optimization in the relatively young Qt4 
code.  It would be nice if I could run callgrind to do some profiling, but I 
still have not gotten that to work.  It's a good idea to add the same timing 
code to 3.5 branch; maybe that will shed some light on the issue.

Look for my commit of Options::useAntialias() soon (i.e., hopefully today).

regards,
Jason
-- 
-------------------------------
KStars: http://edu.kde.org/kstars
Forums: http://kstars.30doradus.org