headers
Jasem Mutlaq | 1 Sep 21:40

KDE/kdeedu/kstars/kstars

SVN commit 707408 by mutlaqja:

Numerous fixes and cleanups in INDI/FITS code base. All icons are
properly loaded using the new set for KDE4. Fixes to histogram
construction. Updating standard properties. All devices have to be
individually tested if possible. Video code is slow and needs a lot of
work, but maybe for KDE 4.1 if I can't get it done soon.

CCMAIL:kstars-devel <at> kde.org

 M  +5 -19     devicemanager.cpp  
 M  +1 -1      devicemanager.h  
 M  +38 -19    fitshistogram.cpp  
 M  +6 -2      fitshistogram.h  
 M  +78 -40    fitshistogramui.ui  
 M  +1 -1      fitsimage.cpp  
 M  +10 -2     fitsviewer.cpp  
 M  +3 -0      imagesequence.cpp  
 M  +4 -4      indi/drivers/video/v4ldriver.cpp  
 M  +15 -0     indidevice.cpp  
 M  +5 -0      indidevice.h  
 M  +27 -0     indielement.cpp  
 M  +1 -0      indielement.h  
 M  +35 -55    indiproperty.cpp  
 M  +2 -2      indiproperty.h  
 M  +42 -37    indistd.cpp  
 M  +3 -3      indistd.h  
 M  +19 -29    kspopupmenu.cpp  
 M  +14 -13    streamwg.cpp  
 M  +3 -1      streamwg.h
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jason Harris | 2 Sep 18:15

Problem with coordinate grid at high zoom

Hello,

KStars locks up at very high zoom levels.  I have traced the problem to the 
coordinate grid.  If you disable the grid in the toolbar, then zoom in 
everything's fine.  But if you re-enable the grid, the CPU immediately goes 
nuts and the program becomes totally unresponsive.

I'm looking into it now...James, is there anything unique about the way the 
grid is handled compared to other linelist items like constellation 
boundaries?

Jason
Permalink | Reply | 7 comments |
headers
Jason Harris | 2 Sep 18:25

Re: Problem with coordinate grid at high zoom

More information on this: it does not lock up if antialiased drawing is off.  

On Sunday 02 September 2007 09:15:13 am Jason Harris wrote:
> Hello,
>
> KStars locks up at very high zoom levels.  I have traced the problem to the
> coordinate grid.  If you disable the grid in the toolbar, then zoom in
> everything's fine.  But if you re-enable the grid, the CPU immediately goes
> nuts and the program becomes totally unresponsive.
>
> I'm looking into it now...James, is there anything unique about the way the
> grid is handled compared to other linelist items like constellation
> boundaries?
>
> Jason
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel <at> kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
Permalink | Reply | 4 comments |
headers
James Bowlin | 2 Sep 18:51
Picon

Re: Problem with coordinate grid at high zoom

On Sun September 2 2007, Jason Harris wrote:
> James, is there anything unique about the way the grid is handled
> compared to other linelist items like constellation boundaries?

I checked the code and the grid is not handled any differently.

> More information on this: it does not lock up if antialiased drawing
> is off.   

H'mm.  This is even more strange.  If you want a work-around, the
place to do it would be NoPrecessIndex::draw().  For example, I was
going to suggest the following temporary patch which would turn off
indexed drawing for things that don't precess:

--- noprecessindex.cpp  (revision 707673)
+++ noprecessindex.cpp  (working copy)
@@ -52,7 +52,7 @@
     }
        **/

-    if ( skyMesh()->isZoomedIn() ) {
+    if ( 0 ) {
         if ( Options::useAntialias() )
             drawLinesFloat( kstars, psky, scale );
         else

But with this latest news, you might want to try just turning off
the anti-aliased drawing in that branch instead.

I'm updating my tree now.  Then I will try to reproduce the problem.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jason Harris | 2 Sep 19:07

Re: Problem with coordinate grid at high zoom

Hello,

I wanted to see which components were calling drawAllLines[Int|Float](), so I 
added the following debug statement to each function:

	//DEBUG
	kDebug() << this << skyMesh()->isZoomedIn() << endl;

I also added debugs to dump the addresses of all line components on startup, 
which gave this just now:

kstars(18788) SkyMapComposite::SkyMapComposite: Milky Way:  0x88aa50
kstars(18788) SkyMapComposite::SkyMapComposite: Coordinate Grid:  0x8bf990
kstars(18788) SkyMapComposite::SkyMapComposite: Constell Bounds:  0x8bfbc0
kstars(18788) SkyMapComposite::SkyMapComposite: Constell Lines:  0x8c24c0
kstars(18788) SkyMapComposite::SkyMapComposite: Equator:  0x8c2c80
kstars(18788) SkyMapComposite::SkyMapComposite: Ecliptic:  0x8c2dc0
kstars(18788) SkyMapComposite::SkyMapComposite: Horizon:  0x8c2b80

Then while zooming in and out, I got these debugs printed:
kstars(18788) SkyMapComposite::draw: ***===--->>> Coordinate grid:  0x8bf990
kstars(18788) LineListIndex::drawAllLinesFloat: 0x8c2c80 false
kstars(18788) SkyMapComposite::draw: ***===--->>> Coordinate grid:  0x8bf990
kstars(18788) LineListIndex::drawAllLinesFloat: 0x8c2dc0 true

As you can see, if the skyMesh is "zoomed in" ("true" in above debugs), then 
the Equator is calling drawAllLinesFloat(), but if the mesh is zoomed out, 
then the Ecliptic calls drawAllLinesFloat().

This is because of line 52 in ecliptic.cpp:
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jason Harris | 2 Sep 19:18

Re: Problem with coordinate grid at high zoom

On Sunday 02 September 2007 10:07:34 am Jason Harris wrote:
> So the Ecliptic and Equator call drawAllLines*() at all times, I guess that
> was deemed necessary.  

Oops, disregard this...
Permalink | Reply | 0 comments |
headers
James Bowlin | 2 Sep 19:47
Picon

KDE/kdeedu/kstars/kstars/skycomponents

SVN commit 707686 by jbowlin:

I have tracked the high-zoom coordinate grid lockup to line 386 in
linelistindex.cpp inside of the drawLinesFloat routine:

    psky.drawLine( oLast, oThis );

This commit re-inserts the onScreen check which reduces the problem
(by reducing the number of times the above line executes) this does
not eliminate the problem.

CCMAIL: kstars-devel <at> kde.org

 M  +1 -1      linelistindex.cpp  

--- trunk/KDE/kdeedu/kstars/kstars/skycomponents/linelistindex.cpp #707685:707686
@@ -380,7 +380,7 @@
                 pThis = points->at( i );
                 oThis = map->toScreenI( pThis, scale, false, &isVisible );

-                if ( ! skipAt( lineList, i ) ) {
+                if ( map->onScreen( oThis, oLast) && ! skipAt( lineList, i ) ) {

                     if ( isVisible && isVisibleLast ) {
                         psky.drawLine( oLast, oThis );
Permalink | Reply | 0 comments |
headers
Jason Harris | 2 Sep 19:46

Re: Problem with coordinate grid at high zoom

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
James Bowlin | 2 Sep 20:05
Picon

Re: Problem with coordinate grid at high zoom

On Sun September 2 2007, Jason Harris wrote:
> (drawLinesFloat() actually uses toScreenI() and doClipI(), so the float 
> versions of those functions can't be the bottleneck).

Opps.  This is a bug.  I will fix it.  But it didn't solve the
gridlock problem.

--

-- 
Peace, James

People living deeply have no fear of death. 
-- Anais Nin
Permalink | Reply | 0 comments |
headers
James Bowlin | 2 Sep 21:33
Picon

Re: Problem with coordinate grid at high zoom

The problem really is in the QT QPainter::drawLine() code.

Contrary to my earlier assumptions, it is incredibly slow when it has
to clip lines to the borders of the window.  By simply increasing the
point density of the coordinate grid by a factor of 4 I was able to
reduce/eliminate the problem at the zoom level I was working at but
(of course) it came back when I increased the zoom level.

I suspect we will have similar problems with all the other children
of LineListIndex.

If this bug in the QT code is going to persist then we can work around
it by clipping all the lines to the screen rectangle ourselves.  This
would be a bit of a mess if we needed to interleave the screen clipping
with the horizon clipping.  But we only need to do the screen clipping
when we are zoomed in and we only need to do the horizon clipping when
we are zoomed out so I can make four more LineListIndex::draw*() routines
that will clip the lines to the screen rectangle but not to the horizon.

I would prefer not to do this if the underlying QT bug is going to get
fixed.

--

-- 
Peace, James
Permalink | Reply | 0 comments |

Gmane