This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Openplotter Charts slow on Raspberry Pi 4
#1
I am new to using Raspberry pi 4 and OpenPlotter. I have looked at Open CPN on my laptop and the speed of the graphics are good, - scrolling, zoom etc But now I want to use a Raspberry Pi 4 and Open Plotter on my boat and am experimenting with it but find the Charts to be VERY slow. 
Am I doing something wrong?
I am using the NOAA ENC charts to test with and have loaded their Lake Ontario charts.

Any suggestions please.
Thanks.
Reply
#2
Try using raspi-config and increasing video memory to 384mb (assuming you are using an RPI4 with more than 2GB). Also, have a look at Chart Groups in OpenCPN. It allows you to quickly switch in and out chart sets, so you aren't loading the entire set of US ENCs.
Reply
#3
Thanks abarrow.
I did try your suggestions, and am using them but what I found made the most improvement with graphic speed was in Advanced Options, I enabled the Accelerated Graphics (OpenGL)

Thanks.
Reply
#4
I'm running into the same questions/problems. Been running OpenPlotter/OpenCPN on a PI 3 for 3 years, ending up at OpenCPN 4.8.4. It all worked great. Decided to use the enforced downtime to finally upgrade to a PI 4, OpenPlotter 2, and OpenCPN 5. It is essentially unusable.

The PI has 2GB memory, I've allocated 512 to graphics. Turned on OpenGL (and turned it off, and played with texture caching). All abysmally slow. I have 380 NOAA S-57 ENC charts of Alaska loaded, nothing else.

What's more frustrating, it is just OpenCPN. While I wait for a zoom to occur I can come over here, load Chromium, type this whole post, all on the same PI, while waiting for the zoom to complete in OpenCPN. Doesn't seem to matter whether or not I have quilting on.

One thing I do notice, when it gets this way OpenCPN CPU usage gets to 24-25%, with overall at ~30%. Almost thinking OpenCPN is maxing out one core? Not using the others?

Given all I've read, and my own experience with older versions I feel I have to be missing some very simple setting.

Suggestions?
Reply
#5
HTOP is a good command line prog to see what's using CPU & memory. Open a terminal and type htop.
This is vnc into a Pi4 2Gb accessed over the internet with opencpn running but no charts
[Image: 1IOioPg.png]
Reply
#6
(2020-04-29, 04:22 AM)dsanduril. Wrote: One thing I do notice, when it gets this way OpenCPN CPU usage gets to 24-25%, with overall at ~30%. Almost thinking OpenCPN is maxing out one core? Not using the others?
PaddyB's suggestion about using HTOP is a good one. Question: are you using the version of OpenCPN that's in the repository, or did you compile your own? I compiled one and it maxed my CPUs. When I cleaned everything off and restarted with a clean Buster image and installed OpenCPN from the repository, everything was fine.
Reply
#7
Thanks guys.

Have been using top, htop, and task manager to show me what's going on. They all show that OpenCPN is the only thing using CPU, everything else is basically in the <2% CPU and total of everything else is well under 10%.

For the install I grabbed the OpenPlotter image and used that. I can un-install and install from scratch, see if that helps. Maybe even put on the betaSmile
Reply
#8
So I removed OpenCPN, rebooted, ran an update on the system, installed OpenCPN from repo.

First run was with the old config files still in place. Same result. htop shows OpenCPN running one core to 100%. That was just from clicking on the "Tools" menu item in the menu bar. Took 13 seconds to load the menu that drops down. Very repeatable, 12-13s to load the menu after clicking on the item in the menu (although once it took 37s).

   

I removed the old configs and forced the install to build new. Then I downloaded the NOAA raster charts of the same region and started with those. Quick as lightning with only raster charts installed. Added back in the S-57 ENCs. Molasses. Created a couple of chart groups, one for RNCs, one for ENCs. With the raster group selected works great. With the ENC group selected same issues -  very long delays and driving one core to 100%. Switching back to RNC group can be a challenge (wait for menu [haven't tried hotkey], select) but once there it is generally much better (although not as good as removing the ENCs from the database).

So, from this observation, anything that causes significant screen draw (such as a menu taking up a fair amount of real-estate) with the S-57 charts loaded causes a great deal of computation. With raster charts showing a right-click loads the context menu before I finish clicking. With ENC showing that same right-click takes ~10s to get the context menu.
Reply
#9
Thought I'd at least report back here my experiences in case anyone else runs into this thread.

Still do not have a completely satisfactory solution. After re-building the Pi about half-a-dozen times, sometimes with OpenPlotter, sometimes with Raspian directly and installing OpenCPN I could replicate the problem with every installation.

Then I realized I was running on a 1920x1200 display (on the boat I run 1920x1080, about the same). And I generally run fullscreen. Reducing to a window makes a huge difference. A half-screen window is a pretty big improvement, a quarter-screen window shows almost no lag. So a window that is ~1024x768 is quite workable, larger and things start to get slower.

I'm playing around with two-canvas mode to see if that works, otherwise as a workaround I've found it pretty easy to use a 1/4 window for panning, zooming, moving around, then maximize the window for use. It's a small pain, but not a large one.
Reply
#10
I have the same problem. Using UK oesnc vector charts I cant get get any sort of reasonable performance. When no charts are loaded I am able to pan and zoom the base map at high speed, but when loaded it can take 10 seconds to move the chats. Very frustrating. This is with a 3b+ pi and open plotter 2. I tried a raspberry pi 4 which also has poor performance.

I've had better luck using qtvlm with visit my harbour vector charts in terms of performance, however i did find it would crash fairly regularly. In the end i'm using a windows laptop hidden away in the chart table connected to the monitor orignally installed for the Pi. What is fairly surprising it draws around the same amount of current (600mA) as the the Pi 3b+.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)