Did you update your video driver around the same time you updated KStars?  We 
have seen this issue before (I've even seen it on muy machine); it is not a 
KStars bug, it is a video driver issue.  Try disabling (or enabling) DRM.

regards,
Jason

nope, its a KSTars bug, i didn't update the videos drivers for several months now (as tehre are no newer version). other applications also runs fast (e.g. 3D games!) and the former 0.9 version of KSTars also run fast enough. I just updated the kdeedu package (for also having a updated KStars version) and thats the point where KStars (new version) got extremely slow.

BTW: what is "DRM"?

On Tuesday 22 June 2004 07:59 am, M.Hilpert wrote:
> ------- BTW: what is "DRM"?
Direct rendering.  Comment out the 'Load "dri" ' line in XF86Config.  I 
bet this will make KStars run fast again.  However, your 3D games will 
not work in this mode.

I say it isn't a KStars bug because it's X that is hogging the CPU, not 
KStars.  And this only happens in a very small percentage of cases; if 
it was a KStars bug, then KStars would likely run slowly for everyone.  
We aren't doing anything fancy with X, just standard use of Qt draw 
routines.

When I saw this problem on my machine, on starting KStars, I would see X 
use a steadily increasing fraction of the CPU, even when KStars was 
just idling, doing nothing.  Within a few seconds, X was using 99% of 
the CPU and it never went down.  Are you seeing something like this?  
This behavior is why I think it's a bug in X or in the video driver.  
There's simply no way that KStars while idling at low zoom requires so 
much from X.  The expected behavior is that X will use only a few 
percent of the CPU when KStars is idling, because we only refresh the 
screen every few seconds (depending on the zoom level).

You could also try using the "nv" driver instead of "nvidia", just as a 
test.  If you try either of these changes to your XF86Config, please 
report back the results.

BTW, I currently have a GeForce4 Ti4200 using the nvidia driver.  I 
don't have any problem running KStars with this card.

One more thing I remember from when I had a similar problem:  If I covered the 
KStars window with another application window, then the X usage would go down 
to normal levels.  Bringing KStars back to the foreground would cause X to 
again build steadily to 99% CPU usage.  Are you seeing this behavior?

This was yet another indication that the problem was some bug in my video 
driver that was being exposed by KStars.  If it was a bug in KStars, it 
shouldn't matter if the window was covered or not.

well, i won't sacrifice my other 3d applications for this. i already have the latest driver installed. "nv" is not working - i use "nvidia". the problem with the covering window or the forground 99% effect does not occur on my computer. KStars runs quite well, just when i click and drag the sky in the KStars Window, the CPU usage (X11) goes up.

Of course, i don't know what exactly the problem is (if it's KStars, X11, video driver), but for a fact: KStars 0.9 and prior was much faster on my computer (same environment/video driver) ... :-(

I think I have the same problem here. I'm using AMD Athlon 64 3000+ and ATI Radeon 9600 XT (XOrg 6.7.0, radeon driver) and version 1.0 (from KDE 3.3.0 beta 2) is also runing extremely slow for me while version 0.9 is runing just fine without changing anything else.

On Friday 23 July 2004 01:01 pm, Jure Repinc wrote:
> I think I have the same problem here. I'm using AMD Athlon 64 3000+
> and ATI Radeon 9600 XT (XOrg 6.7.0, radeon driver) and version 1.0 (from
> KDE 3.3.0 beta 2) is also runing extremely slow for me while version 0.9 is
> runing just fine without changing anything else.

I'm very interested in the fact that you have both kstars-0.9 and the version 
in 3.3beta2 installed, and that only the new version is running slowly.  I 
believe that this problem is not a bug in kstars per se, but rather that 
there is something in the kstars code which is exposing a bug in your video 
driver.  The fact that the bug is exposed in 3.3beta2 but not in 0.9 is 
exciting, because it presents us with a real opportunity to find exactly 
where in the code the bug is being exposed.  However, if I am to find it, I 
am going to need help from you to diagnose the behavior using both versions 
of KStars.  Are you willing to help?

First, can you verify that the process that is using up the CPU while kstars 
is running is X, and not kstars?  I believe this has always been the case 
when people see this problem (you can use the 'top' command for this).

Next, can you try temporarily disabling direct rendering (DRI) in your X 
configuration, and then restart X and try kstars again?  Does this mitigate 
the problem?

If you minimize the kstars window, or even put another window on top of the 
kstars window, does the CPU usage go down?

Can you manipulate some of the view options to see if it has any effect on CPU 
usage?  In particular, try eliminating the use of images (both Messier images 
and planet images).  Try eliminating name labels, try different color 
schemes, try switching between equatorial and horizontal coordinates, etc.
Does any of this make the CPU usage behave normally?

Thanks in advance for your help,
Jason

Sure, no problem to help as much as I can.

As far as I can see in KDE System Guard it is X that is using the cycles. I always had DRI disabled as I don't even play games that much and hardware 3D isn't even supported for Radeon 9600 XT in the current radeon driver anyways. So only normal 2D. So I guess enabling DRI wouldn't help in my case.

Turning on and off various display options didn't help here (well maybe only a little bit). I tried to turn off every thing possible but still the drawing was very slow.

What I did notice is that sometimes the drawing is actually just fine and fast as in 0.9 if not even faster. And I tried even with "hide objects when moving" option disabled so all objects are in the map while it works OK and moving fast.

But unfortunately for the most of the time it is just very very slow even with all objects disabled.

Is there anything else that we could try to get closer to the solution?

Maybe I found something interesting. I restarted the computer a couple of times and then got to run KStars fine again. And I found a way to make it slow. I just clicked the Fullscreen button and that made it run extremely slow right after entering full screen mode. I tried to go back to non-fullscreen mode but it appears that the button doesn't work in this direction (another bug maybe?). Could this be related? Is it of any help?

On Friday 23 July 2004 03:03 pm, Jure Repinc wrote:
> couple of times and then got to run KStars fine again. And I found a way to
> make it slow. I just clicked the Fullscreen button and that made it run
> extremely slow right after entering full screen mode. I tried to go back to
> non-fullscreen mode but it appears that the button doesn't work in this
> direction (another bug maybe?). Could this be related? Is it of any help?

Hmm, the fullscreen button should work as a toggle switch.  Does the keystroke 
shortcut (Ctrl+Shift+F) work?

Nope Ctrl+Shift+F also only toggles into fullscreen. It look like it tries to get out of fullscreen but it just remains in fullscreen no matter how many times you press that key combination or click the toolbar button. I also tried other KDE apps that have this option and they can also only get into fullscreen and not back to normal then. Maybe some (known?) bug in other part of KDE?

Well no matter what I now at least have some reproducable way to turn perfectly responsive KStars into slow one. I just hope it helps any. I will try to do other things to change this. Maybe even from slow to normal drawing speed. But I realy don't know what else to try.

On Friday 23 July 2004 03:14 pm, Jure Repinc wrote:
> I also tried other KDE apps that have this option and they can also
> only get into fullscreen and not back to normal then. Maybe some (known?)
> bug in other part of KDE?
>
Yes, sounds like a KDE-wide bug of some kind.  Not one that I've heard of 
though.  It might be a recent regression.

> Well no matter what I now at least have some reproducable way to turn
> perfectly responsive KStars into slow one. I just hope it helps any. I will
> try to do other things to change this. Maybe even from slow to normal
> drawing speed. But I realy don't know what else to try.

What if you maximize the window instead of making it fullscreen?  Does it 
reliably become slow then?  When you "un-maximize" does it return to normal?

I am going to examine a diff between the sky drawing code from 0.9 and the 
current version tonight.  Hopefully, I'll have some more ideas after that...

Jason

I've always been runing KStars maximized. Even if it is slow or fast. Good luck with the code. I hope you find something in there.
I've been thinking. Is there any way to see what X is doing when it is using so much CPU? Like what function it is executing or something like that.

Hello,

Well, it turns out that version 0.9 is very old, more than 2 years old.  Our 
current CVS repository doesn't go back this far, and the code base has 
changed so much that it is going to be difficult to determine where the 
difference is that is causing the X slowdown.

Would you be willing to compile and install an intermediate version of the 
program to see if it behaved well as of last year?  If so, you can get the 
tarball here:
http://prdownloads.sourceforge.net/kstars/kstars-cvs20030407.tar.gz?download

On Friday 23 July 2004 03:59 pm, Jure Repinc wrote:
> I've always been runing KStars maximized. Even if it is slow or
> fast. Good luck with the code. I hope you find something in there. I've
> been thinking. Is there any way to see what X is doing when it is using so
> much CPU? Like what function it is executing or something like that.
I can't think of an easy way to do this...

thanks,
Jason

I also reported a bug report on XOrg Bugzilla just in case:
http://freedesktop.org/bugzilla/show_bug.cgi?id=949

Perhaps this problem should not be dismissed just as a problem with X. For many graphics cards, the DRI will never be developed and even the normal accelerated driver is and will always be bad. The question is, why does KStars make so heavy use of graphics resources that X can't handle it without good acceleration. DRI isn't really needed. Perhaps this also might not be so much an X problem as a Qt problem, and how it optimises screen updates. Well, that's just a guess.

I don't know how many people are experiencing this sort of problems. If only a few, then this isn't so important issue.

I noticed that, in my case, KStars works quite fast when the window is small, but strangely becomes suddenly very slow when the width of the window goes over about 710 pixels. Height of the window is not a problem, unless the window is very wide. Well, I don't know if others have similar behaviour.

Also, strangely, it doesn't depend on what is drawn on the screen. If I adjust the view to minimum magnification, and resize the window so that the sky just fits in the window, it is very fast. But when I resize the window bigger, while the sky in the window stays small, it still becomes very slow.

I also compared with XEphem. When KStars window is small, it's just as fast if not faster than XEphem. But when the size goes over the about 710 pixel width, XEphem is about 3-10 times faster than KStars. Well, it too gets sluggish with full screen.

To illustrate the problem, as you probably have hard time visualising it, I recorded a short video (video cameras are so much fun). It's currently at http://www.funet.fi/~magi/tmp/kstars-20050402.mpeg (it's 150MB!!!). I won't keep it there for long, but at least a week or two. Linux mplayer seems to play it fine.

Well, as said, this might not be so important issue, but if some solution comes to your mind and it's easy to fix, it would be welcome.

I face a similar problem, i.e. kstars is becoming extremely slowly (to be precise the xserver is eating up all CPU time, more than 90%)

It's running within Suse 9.3 (same holds true for 9.2), i.e KDE-3.4 and kstars-1.1. The size of kstar's window is important. If it exceeds some threshold the xserver starts to slow down.

I'm using a Matrox G450 AGP (4x) with DRI (but without DRI it's slow too). And I'm using a large screen 1600x1200@24bpp.

My processor is a PIII @ 750MHz with 512MB RAM.

Till now only kstars triggers that slow down.

The problem is reduced if I activate the HWcirsor of the mga driver (by default this is deactivated). I don't encounter the problem with my laptop (another desktop resolution, another graphics card).

Any hints what to check within X11 environment to locate the bug?