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

[Jason Harris]

Hi,

I implemented a user option to toggle Antialiasing in my local copy.  Toggling 
it off not only calls "setRenderHint( QPainter::Antialiasing, false )", it 
also uses the integer-pixel versions of all QPainter::draw*() functions, 
instead of their floating-point equivalents.  For example, for drawing a text 
label on screen, we now have code like this:

  //QPointF o is the screen position for the label
  if ( Options::useAntialias() )
    psky.drawText( o, labelString );
  else 
    psky.drawText( int(o.x()), int(o.y()), labelString );

I added similar if/else clauses to all draw functions in the code.

I then used the existing timing debugs to test the effect of toggling 
Antialiasing.  As before, with antialiasing on, the screen takes 1.2 sec for 
a full draw (on my hardware).  With it off, it takes 0.2 sec.

However, as an experiment, I removed the setRenderHint() call, so that it 
would draw without antialiasing, no matter what the option is set to.  In 
this case, presing "A" just swaps between using integer and floating-point 
pixel values in the draw functions.  Now I get:

kstars: Use Antialiasing: false   <-- [Really means: integer pixels]
kstars: Skymap draw took 189 ms
kstars: Skymap draw took 162 ms
kstars: Skymap draw took 164 ms
kstars: Skymap draw took 193 ms
kstars: Skymap draw took 164 ms
kstars: Skymap draw took 157 ms
kstars: Skymap draw took 176 ms
kstars: Use Antialiasing: true  <-- [Really means: float pixels]
kstars: Skymap draw took 238 ms
kstars: Skymap draw took 218 ms
kstars: Skymap draw took 186 ms
kstars: Skymap draw took 186 ms
kstars: Skymap draw took 193 ms
kstars: Skymap draw took 201 ms
kstars: Skymap draw took 225 ms

So, it seems that using floating-point pixels in the QPainter draw functions 
makes very little difference in rendering speed.  The slowdown is dominated 
by the actual antialiased drawing.

For this reason, I suggest that we simply use floating-point pixel values 
throughout the code.

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.

Any thoughts?  Otherwise, I'll probably discard my integer-pixel changes (but 
I will commit the useAntialias option).

regards, 
Jason

-- 
KStars: http://edu.kde.org/kstars
Community Forums: http://kstars.30doradus.org