Menu

#150 Viking causing high Xorg CPU load

v1.7
open
nobody
None
8
2018-05-15
2018-05-09
rooots
No

Hi all,

I've been using Viking 1.6.x and 1.7 under Ubuntu 16.04 without any issues. After switching to Ubuntu 18.04 (fresh install), Viking (both 1.6.2 and 1.7) is becoming extremely laggy when a layer contains several tracks. That is, zooming in and out and panning will make Viking freeze for up to 5s and send Xorg CPU load to nearly 100% (Intel Core i7 7700k@5.1GHz, 16GiB DDR4, Intel Optane SSD).

This also happens with maps etc. completely deactivated, so it appears to be a track thing. Also, viking -d -V does not give any relevant messages in those cases.

The effect occurs with all of my four available desktop sessions: Gnome xorg, gnome wayland, gnome-flashback xorg with metacity, gnome-flashback xorg with compiz. I checked if general opengl rendering is working properly and it is.

I suspect this is no pure viking issue, but I would be thankful for any pointers to help debugging.

Cheers,
r.

Discussion

  • rooots

    rooots - 2018-05-09

    Got to add that this occurs with only one track of roughly 1500 trackpoints as well, though not as pronounced.

     
  • Rob Norris

    Rob Norris - 2018-05-12

    Is it just tracks or are there (m)any waypoints?
    Typically drawing Text (as the waypoint name is displayed by default) generally is relatively slow - especially if the Layer 'Fake BG Color Translucency' is on.

    You could try changing the Layer properties Tracks->Draw Track Lines & Draw Trackpoints to see if either the points or lines are particularly slow.
    Perhaps try turning off the Highlight too (F7).

    Not sure what else you can try.

    Unfortunately the track drawing process has never been particularly efficient - it tries to draw every trackpoint possible - normally this doesn't seem too bad for a few tracks but for some systems it does turn out slow or worse.

    Unfortunately I think changing the way Viking draws stuff (e.g. some method of line simplification to draw less things) would take a reasonable amount of coding effort and/or knock on effects on other internal workings.

     
    • rooots

      rooots - 2018-05-12

      Hi,

      and thanks for the suggestions. It's only tracks, no waypoints, no labels, no images, no translucency etc., turning off highlighting makes no noticeable difference.

      It appears to be both track lines and direction symbols that cause the lag. When deactivating both, keeping just trackpoints, Viking is drawing fluently. Deactivating trackpoints and activating either lines or directions - or both, will induce laggy behaviour.

      Unfortunately, deactivating track lines is not a viable workaround for me. I'm just wondering what makes the difference, because I did not see any of this behaviour with Ubuntu 16.04. So it appears something between Viking and Xorg that is involved in the drawing process is not working properly. Any idea what that could be?

      Cheers,
      r.

       
  • Rob Norris

    Rob Norris - 2018-05-14

    Viking calls gdk_draw_line() alot, which has long been deprecated.
    Somewhere in the gdk/x.org stack this must be behaving differently.

    Ideally Viking should shift to using cairo_move_to (), cairo_line_to() etc... functions or even a higher level drawing canvas. Unfortunately the last time I tried it didn't work to well and I gave up. ATM I can't remember what the problems were.

    This is one of main sticking points that prevents shifting to GTK3.

     
  • rooots

    rooots - 2018-05-15

    Ok. Had a look at the code but unfortunately my coding abilities are way too limited to be of any help. Anyway - thanks a lot for keeping that great project going - been using Viking since 1.2! ;-)

    r.

     

Log in to post a comment.