Slowness in SkyMap

[Hy Murveit]

It's coming back to me...A while back I was having issues like this, and I
traced it to something odd in the way kstars dealt with star catalogs.
Akarsh and I looked at it but never resolved it, but as I recall, the
symptom was that even though the code that was supposed to only look at
data from a small part of the sky (a particular trixel) when looking for
stuff to display from the catalogs, it wound up instead looking through the
whole star catalog, which can be very very slow for large catalogs.

Though I could reproduce that for a while back then, I stopped being able
to reproduce it, and we couldn't debug it--the problem went away and we
went on to other things.

So, here's my theory. That problem, whatever it was, is (occasionally)
back.  [Of course, now my system is working well again with terrain
enabled, so I can't look into it.]

So, if any of you run against that issue, I suggest you try the following,
based on my vague memory of that old debugging session:  If it is happening
to you, go to ~/.local/share/kstars and move the file USNO-NOMAD-1e8.dat to
your home directory (if you have that file) and restart kstars and see if
the problem goes away. Then, of course, put it back and see if the problem
returns. Then debug ;)  I think a possibility is that you'll find that the
code that renders stars, starcomponent.cpp::draw(),  is taking a long time
searching through that large catalog because the trixel filtering it uses
is somehow no longer effective (that is, line 304 of that file,
"MeshIterator region" is just returning ALL regions of the sky, not just
the ones visible in the skymap).

Hy


On Wed, Mar 19, 2025 at 3:16 PM <hans at lambermont.dyndns.org> wrote:

> Hy Murveit wrote on 20250319:
>
> > For me it's not limited to heavy FOV, but rather always.
>
> For me slow/not responding as well. I'm imaging now (rare clear
> skies here) and a mouse wheel action in the star view does not
> respond at all (it should zoom) while the mouse wheel in ekos
> over the tabs happily immediately switches tab views.
>
> -- Hans
>
> > On Wed, Mar 19, 2025 at 1:41 PM Wolfgang Reissenberger <
> > sterne-jaeger at openfuture.de> wrote:
> >
> > > I’ve observed a similar problem. When I’ve zoomed in very heavy (FOV
> 1-2
> > > deg), KStars becomes very slow and EKOS hangs.
> > >
> > > Am 19.03.2025 um 21:37 schrieb Hy Murveit <murveit at gmail.com>:
> > >
> > > Responding to (and moving) Akarsh's note below.
> > >
> > > I don't know what's going on, but I can second that.
> > > Every now and then I get this incredible slowness drawing the terrain
> > > overlay.
> > > Right now, kstars is unusable with terrain enabled on my dev Linux VM.
> > > When I turn terrain off (which takes a while because of the extreme
> > > slowness) all is ok.
> > > It seems to working ok natively on my Mac.
> > > I haven't changed anything in the terrain code in years.
> > > Seems likely to be related to the issue you're reporting.
> > >
> > > Anyone else see this?
> > > Hy
> > >
> > > ---------- Forwarded message ---------
> > > From: Akarsh Simha <akarshsimha at gmail.com>
> > > Date: Sun, Mar 16, 2025 at 11:30 PM
> > > Subject: Re: Akshay--a New Volunteer
> > > To: Jasem Mutlaq <mutlaqja at ikarustech.com>
> > > Cc: KStars Development Mailing List <kstars-devel at kde.org>, Akshay
> > > Subramaniam <akshaysubr at gmail.com>
> > >
> > >
> > > Hi Akshay
> > >
> > > Nice to see you join team KStars! Akshay and I went to college together
> > > way back in 2008 or so, and we used to be in the astronomy club
> together.
> > >
> > > On a side note HiPS overlay is crawling on my friend’s 2019 MacBook Air
> > > and after some time KStars hangs. Makes it unusable. Any idea what’s
> going
> > > on?
> > >
> > > Regards
> > > Akarsh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20250319/1954eb9b/attachment.htm>