Hi James, On Sunday 02 September 2007 09:51:44 am James Bowlin wrote: > > More information on this: it does not lock up if antialiased drawing > > is off.   > > H'mm. This is even more strange. I diffed the contents of drawLinesFloat() and drawLinesInt(), thee are the only substantial differences: < psky.drawLine( oLast, oThis ); > psky.drawLine( oLast.x(), oLast.y(), oThis.x(), oThis.y() ); < psky.drawLine( oLast, oMid ); > psky.drawLine( oLast.x(), oLast.y(), oMid.x(), oMid.y() ); < psky.drawLine( oMid, oThis ); > psky.drawLine( oMid.x(), oMid.y(), oThis.x(), oThis.y() ); (drawLinesFloat() actually uses toScreenI() and doClipI(), so the float versions of those functions can't be the bottleneck). I really don't think the difference between antialiased and aliased drawing can explain the lock-up I'm seeing. So, on a whim, I modified NoPrecessIndex::draw() so that it always calls drawLinesInt(): if ( skyMesh()->isZoomedIn() ) { if ( Options::useAntialias() ) //DEBUG //drawLinesFloat( kstars, psky, scale ); drawLinesInt( kstars, psky, scale ); else drawLinesInt( kstars, psky, scale ); } *Even with this change*, KStars will lock up if all of the following are true + high zoom level + Coordinate grid is active in toolbar + antialiased checkbox checked So the bottleneck seems to have nothing to do with the actual draw routine, since it is now calling drawLinesInt() no matter what useAntialias() is set to. It's possible that I am missing some logic that would cause drawLinesFloat() to be called despite the above change, but I can actually confirm that the coordinate grid does not call drawLinesFloat(), because I have a debug line in drawLinesFloat() that is only triggered if the "this" pointer is the coordinate grid. My current guess is that the problem is in the update routines, not the drawing. Perhaps antialiasing triggers different code for the updates? Jason _______________________________________________ Kstars-devel mailing list Kstars-devel@kde.org https://mail.kde.org/mailman/listinfo/kstars-devel