OpenCPN Version 4.4 Released

[RhythmDoctor]

Originally Posted by bdbcat

...Any more info on your troubles with O44 OpenGL on Windows?...

No time to run a well controlled test. I want to run it with a fresh install and minimal charts to ensure it's not a faulty setting. It may be a few more days, but when it's done it will be done right.

[bcn]

On my Dell XPS13 (Win(.1) the log file gets littered with a screen size detection message every second.
Independent from OpenGL or ScreenSize detection mode

9:59:22 AM: Detected display size (horizontal): 294 mm
9:59:23 AM: Detected display size (horizontal): 294 mm
9:59:24 AM: Detected display size (horizontal): 294 mm
9:59:25 AM: Detected display size (horizontal): 294 mm
9:59:26 AM: Detected display size (horizontal): 294 mm
9:59:27 AM: Detected display size (horizontal): 294 mm
9:59:28 AM: Detected display size (horizontal): 294 mm
9:59:29 AM: Detected display size (horizontal): 294 mm
9:59:30 AM: Detected display size (horizontal): 294 mm
9:59:31 AM: Detected display size (horizontal): 294 mm
9:59:32 AM: Detected display size (horizontal): 294 mm
9:59:33 AM: Detected display size (horizontal): 294 mm
9:59:34 AM: Detected display size (horizontal): 294 mm
9:59:35 AM: Detected display size (horizontal): 294 mm
9:59:36 AM: Detected display size (horizontal): 294 mm

Anyone else noticing such issue?

Hubert

[Hakan]

Yes I've noticed but not on my Win10 but on a Rpi.
But talking log file on Win10, OpenGL=on.
I have more then 100 of this within one second:
9:31:19 AM: Loading catalog for opencpn core.
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile
9:31:19 AM: Warning: iCCP: known incorrect sRGB profile

[CarCode]

Hakan,

this is caused by old-style PNG files which includes old iCCP infos.
The old wxWidgets versions have used an outdated libpng which has been changed now for the newer wxWidgets versions. That is why you have not seen this message before.

There are 2 ways to fix this problem:
Either you fix the iCCP informations embedded into the affected PNG files with first downloading and installing an actual srgb-icc profile and then convert the PNG images with

for x in *png; do convert $x -profile sRGB_v4_ICC_preference.icc $x; done

or you delete all iCCP informations embedded in the affected PNG file with

convert -strip png-filename.png

The convert command is part of the ImageMagick program.

Gerhard

[rgleason]

Win10
8:10:05 PM: Warning: iCCP: known incorrect sRGB profile
8:10:05 PM: Warning: iCCP: known incorrect sRGB profile
8:10:05 PM: Warning: iCCP: known incorrect sRGB profile

[Hakan]

Gerhard..
Yes, I've heard about this before but I don't think I'm the only one getting these log messages. So even if I'd follow your advices it's not solved for all users. The best may be if there's a general solution although it's not a first priority problem that the log files occupies a couple of more bytes. It's more that the user confusion results in worries and forum/tracker activities.
Håkan

[CarCode]

Hakan,

it's up to the application developers to deliver bug free apps.
That is not the only example where they failed...

Gerhard

[Hakan]

Gerhard...
up to and up to........ Yes those having knowledge, ideas, joy and time are developing this wonderful program. But no one has duties nor have we demands on them. In this world everyone who wants and can contribute are free and welcome to so so.
I'm so happy to use OCPN, test and report and sometimes also have thoughts about different things. My knowledge in coding is though very limited so there I have not much to offer. I understand you have much more coding capabilities so if you have an idea about this particular issue and the joy of doing so you are welcome to suggest a solution.

(I'm trying to put this friendly, if not it's all about my poor English, so please read in a positive manner)
Håkan

[CarCode]

Hakan,

I have shown above how to fix this problem and I have done this some times ago when I first see it using the newer wxWidgets versions. But nobody cares about it. I guess the main goal of the developers is only to get the software not crashing.

Gerhard

[nohal]

Gerhard...
Do us a favor and before wasting more time beating this dead animal, check the master branch changelog.

Pavel

[rgleason]

What a wonderful, supportive, understanding and open community! It is also good entertainment. Gerhard if you could just make less definitive and insulting statements it would help. You have contributed a lot and are a great person at assisting users too. Don't expect us all to recognize instantly a new discovery of yours, there are a lot of things going on. Also please try not to denigrate the efforts of others, as it is not helpful and it just makes you sound unreasonable, and we all know how that can be.. so peace, lets all be friends working towards the same goals, which I know you have in mind and in your heart, and support this unusual community.
Your (sometimes) friend. Rick

[rgleason]

PS Gerhard a big thankyou for knowing the answer.

[jongough]

It looks like the UserIcons introduced as part of OCPN Draw 1.2 may have caused some of the iCC messages. Prior to 1.2 users could add icons, but there was a request to provide some in the package, so that is what happened. I did not notice the iCC issue, but Pavel did just after packaging 1.2 for release. The png files have been updated and there is a new version in the git repository with the icons corrected. If you want it you will need patch 1.2.1. This will 'probably' be issued when Pavel has finished doing some OS X checks/changes (I don't have an OS X environment to test with).

I work almost exclusively in a Linux environment where, at most, I got one iCC message and it was not apparent to me where it was coming from. I only use Windows (virtualised) to do some checks with languages and to do the builds for alpha/beta testing and I was not trawling through the logs looking for this type of thing (I also cannot follow all threads in the forum, it would take too much time). I was more focused on OD working, providing the functionality that was being asked for and that it would work on all platforms I can test on. I have to rely on others doing testing on their environments to inform me if there are issues.

One issue in the past turned out to be methods of drawing, i.e. creating boundaries anti clockwise, whilst I do it clockwise, for me it worked for the user, Rick, it did not. But it let me improve the plugin and gave a fresh set of eyes on the usability. Being intimately involved in the coding it is very difficult to think of every option, situation, requirement, and human interaction mode, I tend to get stuck and cannot see the woods for the trees. Hence the use of beta testing to defines the woods.

So, if users have a good knowledge of OpenCPN, then it is helpful if some problem determination can be done to aid the developers in finding the issues. The one above took a GPX file that allowed me to 'see' what the user had done. Then the issue and fix was obvious. The only way that could have been used in the iCC message case was to turn off all the plugins, restart OCPN, then look for the iCC message, turning each plugin back on until the issue occurred. Then the plugin developer could have been notified easily that they had an issue. I don't like my stuff not working or causing users problems, so directed problem reports help me fix them up quickly.

Jon

[Hakan]

Jon
Many thanks for the png fix. Now my log file is "quit". And, yes, I could have understood the OD connection earlier since it was long ago since these messages occurred last time.
And Hubert - Sorry to steel your issue about "display size" with this..............
Håkan

[RhythmDoctor]

Originally Posted by bdbcat

...Any more info on your troubles with O44 OpenGL on Windows?

Thanks
Dave

OK, Dave, I finally got some time to test. I deleted opencpn.ini, opencpn.log, and CHRTLIST.DAT for a clean install free of most remnants of a previous version.

After some experimenting, I think I found a repeatable symptom - I'll let you determine root cause.

After my first launch of the portable version, the new .ini file is created with a default chart directory pointing to a subdirectory of the portable folder (E:\Program Files\OpenCPN-Test\charts). That entry is in the directory list even if there is no such folder on my drive.

So first I created a folder in that location, put some charts there, and forced a rebuild of the chart directory. OpenGL worked fine under this situation.

However, since I have many charts with limited space on the SD card, and I like to run two instances of OpenCPN simultaneously, I have a separate unified chart directory that is shared by multiple instances (E:\Sailboat\Charts). So I deleted the default path and added a new one pointing to that unified chart directory. After launching OpenGL worked momentarily on ENC, but upon selecting a RNC chart the window froze, and continued to be frozen even if I switched back to ENC.

So I deleted this alternate chart directory and added back in the original default location (E:\Program Files\OpenCPN-Test\charts). However, when adding the folder within the settings dialog, the dialog displays a relative path to the directory, not a full path ("charts" instead of "E:\Program Files\OpenCPN-Test\charts"). This time, OpenGL froze. When I pointed OpenCPN to the different path, OpenCPN saved a relative reference for that as well (..\..\Sailboat\Charts instead of E:\Program Files\OpenCPN-Test\charts). Note that in this case, the relative path backs up a couple levels first.

So it appears that the reason OpenGL is crashing for me is related to the fact that when OpenCPN adds a new chart directory, it is stored as a relative reference, not an absolute reference. Under prior versions of OpenCPN, the program would store the chart directories as a full path.

Of course, it's always more complicated with me. For running portable mode on Windows, relative paths are a more universal way of saving chart directories because when you insert an SD card or flash drive, you sometimes get a different drive letter which breaks everything in the .ini file. Under v4.0 and prior, I would actually go into the .ini file and edit the chart paths, SENC path, etc. to convert them from absolute path to relative path so that it could run under any drive letter (obviously the .ini file requires double backslash \\ in the path instead of single backslash \). This worked fine for me under v4.0 and made portable mode far more bullet-proof.

So the irony here is that v4.4 saves the relative path natively (which I like), but doing so seems to crash OpenGL.

Obviously, this is a correlation with no proof of causation. I'll have to leave that to you.

I hope you can recreate this issue on your machine based on this description. I've attached .ini and .log files for your reference.