OpenCPN Beta Version 3.3.2330 Released

[Hakan]

Sean..
I may have noticed but nothing clearly reproducibly. But what's more annoying is that the lights, lighthouses etc., are sometimes invisible and can't be controlled by "L". For the moment I can't get the lights to work at all. (Yes, all light checkboxes are checked.)
Any connection to your issue?
WinXP, OpenGL - on, but set off makes no difference.)
Håkan

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

Gilletarom...
re:
"1 I zoomed in, zoomed out, and used F11, more that once ...
I assume you mean the Toolbar?
Have you seen this bug more than once?
....
Dave

This occur more than once but I can not reproduce it myself. I put my post because it happened 4 or 5 times including twice yesterday.

I suspect an interaction with the use of "alt". But without certainty.

Gilletarom.

[Opie91]

Originally Posted by boat_alexandra

I have been waiting to mention this as I hoped I could fix it, but I noticed that since the soundings code was rewritten in opengl mode, sometimes the soundings just don't display at all for an area until I zoom in and out a lot of times.

Anyone else notice this? I think it should be fixed before a major release.

I had this happen to me regularly in one area (repeatable). Bumping up the chart detail 1 notch above the default level seems to have fixed it.

[CarCode]

There is a continous memory leak of 48 bytes here in OCPNRegion.
Gerhard

[Hakan]

Originally Posted by Hakan

I've using GDIView collected 3 hours run for 3.3.2330 beside a portable 3.3.1419. The two instances are UDP connected and consequently used the same NMEA data. .......
Håkan

More crash info:
Strange! Now I've been running the same setup for 24 hours without crash. But the GDIs are constantly increasing as is the memory usage, the latter from ~50MB to now ~130MB.
There's still a significant difference in GDI use between 2330 and 1419 running beside.
Håkan
Some GDIView data:

OCPN 3.3.2330 WinXP /hakan
Detect counter: Several objects(~300? most Bitmap) = 17300 const. incr.
Detect counter: Some 30 objects from ~4000 - 1
GDIs:
==================================================
Process ID        : 2392
Process Name      : opencpn.exe
Pen               : 22  [+22]
ExtPen            : 4  [+4]
Brush             : 31  [+29]
Bitmap            : 303  [+253]
Font              : 51  [+29]
Palette           : 2  [+2]
Region            : 53  [+48]
DC                : 34  [+28]
Metafile DC       : 0  [0]
Enhanced metafile DC: 0  [0]
Other GDI         : 1  [+1]
GDI Total         : 501  [+416]
All GDI           : 528  [+440]
==================================================
On the same duty:
OCPN 3.3.1419
Detect counter: Several objects(~300? most Bitmap) = 21 nearly constant.
Detect counter: Some 30 objects = 1
GDIs:
==================================================
Process ID        : 608
Process Name      : opencpn.exe
Pen               : 12  [0]
ExtPen            : 6  [0]
Brush             : 15  [+2]
Bitmap            : 193  [+5]
Font              : 29  [0]
Palette           : 0  [0]
Region            : 22  [+1]
DC                : 12  [0]
Metafile DC       : 0  [0]
Enhanced metafile DC: 0  [0]
Other GDI         : 1  [0]
GDI Total         : 290  [+8]
All GDI           : 317  [+8]
==================================================

[PjotrC]

Originally Posted by Wanderlust

So, why not make it an easy option to choose blurring or not. How about ........

Indeed, how about something better than blurring?

While I understand and appreciate the warning, I don't think blurring is the best way to tell something to the user.

Is the big "Overzoom" and then perhaps "Dangerous Overzoom" (as next step) not enough?

Positional accuracy is not the only feature of the chart. How about a cardinal buoy ahead? I am only concerned about whether to take it to starboard or to port... and I want to see it clearly identifiable on the screen at all times, perhaps with the local danger it is related to.

I will definitely turn blurring off, and then I will lose the "dangerous overzoom" information. At the end of the day it sounds counter-productive.

PS. I tried some simple zooming in and out on CM93 and S-57 a bit. Crash report sent.

[RhythmDoctor]

Originally Posted by PjotrC

...Positional accuracy is not the only feature of the chart. How about a cardinal buoy ahead? I am only concerned about whether to take it to starboard or to port...

But that's the heart of the issue. When overzoomed, the buoy's location is imprecise on the chart. Based on the chartplotter, you may think you're taking it to starboard, but you're actually taking it to port - or worse, heading right for it. The blurring gives you an ever-present reminder of this (unless you decide to turn it off).

If you're so close to the buoy that you need to overzoom to see it, then you had better look up and make visual identification. And be sure to scan all around you, because it may be in a different direction from what the chart says.

[PjotrC]

Originally Posted by RhythmDoctor

If you're so close to the buoy that you need to overzoom to see it, then you had better look up and make visual identification.

Exactly, I meant the situation where I navigate mainly by looking around and following the buoys... I do not care where GPS puts me on the chart... I rather take the buoys on the correct side, and the chart, even inaccurate, may help me in understanding the situation.

I know, the chart also may be out of date. Why not blur charts older than x years?

I appreciate the warning, but not the blurring.

[CarCode]

Originally Posted by Hakan

More crash info:
Strange! Now I've been running the same setup for 24 hours without crash. But the GDIs are constantly increasing as is the memory usage, the latter from ~50MB to now ~130MB.
There's still a significant difference in GDI use between 2330 and 1419 running beside.
Håkan
Some GDIView data:

See above. OCPNRegion is the most one, but there are other leaks as well.
Gerhard

[HappySeagull]

Originally Posted by Hakan

Sean..
I may have noticed but nothing clearly reproducibly. But what's more annoying is that the lights, lighthouses etc., are sometimes invisible and can't be controlled by "L". For the moment I can't get the lights to work at all. (Yes, all light checkboxes are checked.)
Any connection to your issue?
WinXP, OpenGL - on, but set off makes no difference.)
Håkan

using [ L ] and [T] key repeatedly seems to be a bit sticky sometimes they work sometimes not.... But does it relate to the overall cm93 bug Dave has already digested? (It is hard to test much cm93 wise with this bug...)
(per boat_alexandra post) I have cm93 soundings missing once this morning and but not since.
-W7 x64 on HP G60

[mattkab]

I'm getting black screens when zooming and panning using this most recent version on low-powered ARM platforms. Zooming in/out or panning again will sometimes redraw and resolve the issue. Not sure yet if its OpenCPN, OpenGLES, or the OS yet, and I will investigate more.

More detailed info below:

I did a CubieTruck rebuild the past couple days, like I mentioned in another thread.

I rebuilt the machine using the most recent Cubieez image and installed it on the NAND. I installed the glShim code from Sean, and got high framerates (~100fps) on glxgears.

I downloaded, built, and installed the most recent version of OpenCPN from github (yesterday at 4pm Pacific time). Downloaded region 15 (Pacific Northwest) ENC charts from NOAA. Ran openCPN with the -unit_test_1 flag to ingest all the charts. Manually (right click menu) placed my boat in the water near Tacoma.

Restarted OpenCPN and black screens occasionally show up when zooming and panning. CPU constant at ~60% usage, RAM memory stable for the most part.

Interestingly, once the black screen shows up, glxgears will no longer work until OpenCPN is exited. The glxgears terminal window repeatedly shows : Error: couldn't open display (null)

There is nothing useful in the log file.

I'll continue to investigate later tonight. This issue seems to be somewhat similar to this thread and this report.

As a software developer by trade, I'm fully aware that this is a beta version, and I'm adding multiple levels of complexity with the platform I've chosen. This is in no way intended to be a complaint.

[colemj]

Below is a screenshot of a CM93 chart showing the entrance to the Caribe side of the Panama Canal. The program running the chart is SEAiq on an iPad, which I consider my tablet version of OCPN .

Note how it treats overzoom (it also allows me to go to x66 overzoom if I want to back into a slip). I don't mind this warning mode if OCPN really needs to hold my hand. This method is both unavoidable and relatively nonintrusive. It certainly doesn't render the program unusable.

Also note that this is the freaking entrance to the Panama Canal, and OCPN would have it blurred out at this level! This shows what a mistake blurring is as a mode of user notification.

Mark

[nohal]

Mark...
Are you SURE? Yes, the blur kicks in, at about 1:1000...

Pavel

[colemj]

OK, I have blurring turned off now, so don't know when OCPN resorts to blurring (I did assume it was upon overzooming). But if it chooses a random zoom level far removed from the actual scale to start blurring, that is even a better reason to get rid of it - it has failed at its designed purpose.

However, my point was to try to be helpful by showing an example of another way to get in a user's face about overzooming that is more humane to the user.

I get that you like the blurring. However, many of us do not. I am not against persistent warning upon overzoom, but think blurring is an abominable way to do it. Perhaps you will realize that the real purpose here is to provide a usable form of information on the chart scaling, not doggedly stick to a single method.

Mark

[nohal]

Mark...
When the chart is blurred is not "random" as you keep thinking. It is used when the overzoom gets to an extreme level and you can't reasonably rely on what you see anymore as explained by Dave very thoroughly earlier in this thread. That's the whole point of it...
But you already turned it off, so I suppose you can keep using your charts the way you like. Glad that you are at the end happy.

Pavel