SportTracks on Linux/MONO is unusable

Post a question about the software or find answers here.

SportTracks on Linux/MONO is unusable

Postby donrhummy » Tue Aug 18, 2009 9:12 pm

On linux/mono, SportTracks was so ridiculously slow that you can see every inch of the window paint itself and every button press takes 10 seconds to register. It's unusable. Other apps are fine but for some reason SportTracks is not.
donrhummy
 
Posts: 46
Joined: Fri Feb 22, 2008 12:40 am

Postby mechgt » Tue Aug 18, 2009 9:37 pm

Don't know a lot about *why* it's slow, but on my machine, I think it's the graphics driver that's slow. In looking at the processes, Xorg can start taking up to 100% cpu when rendering the charts.

I don't know nearly enough about graphics drivers and all that business (so don't blame me if it breaks), but I added a line in my xorg.conf file that seemed to help some - definitely better, but not 100% better yet.

Here's the article:
http://magazine.redhat.com/2007/11/20/t ... as-driver/
Last edited by mechgt on Fri Aug 21, 2009 1:43 pm, edited 1 time in total.
Enhance SportTracks with Training Load, Fit Plan and more plugins at mechgt.com. Garmin FR310XT & iBike iPro
User avatar
mechgt
Donated!
Donated!
 
Posts: 1366
Joined: Wed Sep 26, 2007 2:13 pm
Location: Atlanta, GA, USA

Postby Plug1n » Fri Aug 21, 2009 11:56 am

It is perfectly usable for me with an 2MHz Athlon and a Radeon 9550 with 1.5GB ram (i.e. a somewhat historic PC).

I suggest the problem is probably your installation or distribution.

I'm using Gentoo with XFCE, xorg 7.4 and the xorg radeon driver.

Either you or a mod should change the title of this thread because it is factually wrong.
Plug1n
 
Posts: 4
Joined: Sat Jul 18, 2009 3:42 pm

Postby mechgt » Fri Aug 21, 2009 12:17 pm

Plug1n wrote:It is perfectly usable for me with an 2MHz Athlon and a Radeon 9550 with 1.5GB ram (i.e. a somewhat historic PC).

I suggest the problem is probably your installation or distribution.

I'm using Gentoo with XFCE, xorg 7.4 and the xorg radeon driver.

Either you or a mod should change the title of this thread because it is factually wrong.


I completely agree that it's not ST that's necessarily slow. I've got a decent desktop (64bit 2.4GHz 4GB RAM) and am still convinced that (at least in my case) the video system (driver, Xorg, something) is to blame.

Take a look at your processes and see what's using all your resources when it gets slow. I use a program called 'conky' to monitor my system, but you could also type 'top' from the terminal to watch what's going on.

But, yes, a blanket statement that ST is unusable on the Linux platform is just not accurate.
Enhance SportTracks with Training Load, Fit Plan and more plugins at mechgt.com. Garmin FR310XT & iBike iPro
User avatar
mechgt
Donated!
Donated!
 
Posts: 1366
Joined: Wed Sep 26, 2007 2:13 pm
Location: Atlanta, GA, USA

Postby admin » Fri Aug 21, 2009 2:52 pm

There is a known issue in the charting component which forces repainting of the chart area when the mouse is moving. This allows the mouse point to track the x-axis and y-axis value (a very useful feature) as well as highlight the mouse point when it is above a chart line.

On windows the repainting does not seem to cause problems with performance, however on mono, and on certain systems or distros it seems to bog down the processor with redrawing. It appears what happens is these repaints stack up more and more as the mouse moves and the redrawing falls behind.

Eventually this will be optimized in the SportTracks code, but it is a lot of work and because it only effects certain less common scenarios, it is not a tremendously high priority right now.

If there are other areas causing problems, I don't know of them and would appreciate more information of particular scenarios.
User avatar
admin
Site Admin
Site Admin
 
Posts: 3094
Joined: Tue Apr 05, 2005 8:52 pm
Location: North Carolina, USA

Postby mechgt » Fri Aug 21, 2009 3:11 pm

I'm not sure if this is the same thing I experience or not. I open a chart, it takes a moment. I can now browse around the screen, and things run fine. Let's say I click an axis to slide or zoom in a chart. It hangs for a significant amount of time (appearing not to do anything), then 'releases' and I can slide the chart around freely (sometimes it's a trick to get the mouse to let go of the chart axis though).
Enhance SportTracks with Training Load, Fit Plan and more plugins at mechgt.com. Garmin FR310XT & iBike iPro
User avatar
mechgt
Donated!
Donated!
 
Posts: 1366
Joined: Wed Sep 26, 2007 2:13 pm
Location: Atlanta, GA, USA

Postby admin » Fri Aug 21, 2009 4:12 pm

Yes, the same issue.

Basically the chart requests to be redrawn frequently. In Windows, it appears this is handled intelligently (I suspect multiple redraws are thrown away) - in mono, each redraw is respected, queued up and thus slows down the system.

A fast graphics card will alleviate the problem, for obvious reasons.
User avatar
admin
Site Admin
Site Admin
 
Posts: 3094
Joined: Tue Apr 05, 2005 8:52 pm
Location: North Carolina, USA

Postby Plug1n » Fri Aug 21, 2009 4:33 pm

Well I must be lucky because in my routes with either street or satellite view I can move the mouse around, drag and zoom with the mouse wheel with no significant slow down or problem.

All this on an 8 year old mother board.

I probably get faster responses than similar functions in Google Earth.

Using Mono 2.4.2
Plug1n
 
Posts: 4
Joined: Sat Jul 18, 2009 3:42 pm

Postby donrhummy » Mon Jun 14, 2010 10:41 am

[quote="admin"]Yes, the same issue.

Basically the chart requests to be redrawn frequently. In Windows, it appears this is handled intelligently (I suspect multiple redraws are thrown away) - in mono, each redraw is respected, queued up and thus slows down the system.

A fast graphics card will alleviate the problem, for obvious reasons.[/quote]

Can't you override the redraw/draw method and if it's running on linux, ignore multiple calls? (You could set some state field to know if it's the same thing)
donrhummy
 
Posts: 46
Joined: Fri Feb 22, 2008 12:40 am

Postby JuLLaSS » Mon Aug 02, 2010 3:11 am

donrhummy wrote:SportTracks was so ridiculously slow that you can see every inch of the window paint itself and every button press takes 10 seconds to register. It's unusable.


I have been using Sporttracks on my laptop on linux for over a year and it's been working fine (only freezing for a moment when I clicked to much on charts, as described in this thread), but yesterday I switched to a new laptop (thinkpad t41 -> thinkpad t60) which should be much faster of course... and everything works fine for me except for Sporttracks:
- it takes about 3 minutes to start up, and the whole computer is unresponsive in this time (both CPU cores taken by X)
- afterwards, it takes it about 10-15 seconds to respond to any click anywhere, and you can see how it redraws everything button after button, field after field...

I spent a few hours yesterday trying to figure out what's the cause... Cause the system is the same. Kubuntu 10.04, the same version of mono from the same repo, the same configuration (i copied my /home/ into the new drive)...
A few times I thought I have solved it, because it has started working normally (and I wasn't sure why, what have I done that worked), but then after alt+tabing to a different window and going back it again started to be slow... :(

Has anyone have such strange issues and was able to solve them?
JuLLaSS
 
Posts: 12
Joined: Thu Apr 09, 2009 7:33 am

Postby dhr » Wed Oct 27, 2010 2:44 am

Hi,

JuLLaSS: yep, I have pretty much the same user experience on my machines:
- Intel Core2 Duo E8400 3GHz, 4GB RAM
- Intel Core2 Duo T7500 (Samsung R70 Laptop), 4GB RAM
- Intel Atom 270 (Samsung NC10), 1GB RAM

All machines are running a current Debian Squeeze/testing (64bit for the Core2s, 32bit for the Atom). Currently I don't know what other info would be useful to be provided...

Cheers,
Daniel
dhr
 
Posts: 1
Joined: Thu Oct 23, 2008 9:30 am


Return to Questions

Who is online

Users browsing this forum: No registered users and 0 guests