AIS Rollover display corrupted when RADAR window is displayed

[NAHANNIV]

[NAHANNIV]

Sometimes the AIS rollover is not doing anything if the RADAR window is displayed. Sometimes other rollover displays are corrupted (track info, route info).

[keesverruijt]

Nasty. OpenCPN does not realise other code (plugins) want to do direct OpenGL drawing, and gets its textures mixed up. We have to do some extra hoopla to compensate for it, if possible.

[keesverruijt]

It's even weirder. If I set the "Refresh rate" to 1, we don't schedule any additional redraws of the OpenCPN chart window, and the (AIS) rollover timer starts working, even with an overlay and PPI working.

Can you reproduce this? See Menu > View > Refresh rate

[keesverruijt]

The same bug is present in v2.1 and v1.32, at least the timer bug is. I just did a quick test so didn't see any 'incorrect' textures, but the timer no longer fires with refreshrate > 1, or at least incorrectly, and the rollover stays around on the screen.

[NAHANNIV]

When I reduce the refresh rate to 1, I do not see corruption, but still strange results, like the rollover widows staying on the screen long after the cursor is moved.

[keesverruijt]

What sort of spec computer do you use, in particular what processor?

Sent from my iPhone

On 8 Sep 2017, at 18:16, NAHANNIV notifications@github.com wrote:

When I reduce the refresh rate to 1, I do not see corruption, but still strange results, like the rollover widows staying on the screen long after the cursor is moved.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[NAHANNIV]

Intel Atom x5-Z8300 1.44GHz 4G RAM with 64bit Win10 Home

[NAHANNIV]

There is still an issue with the PPI window causing problems in the Beta4 release.

I do not see corruption of the rollover menu anymore,

But, the AIS roll over displays do not time out when the PPI window is active.

Also, when PPI window is active and RADAR overlay on the chart window I can not zoom or pan the chart window ? Not sure if this should be a separate issue, seems like they may all be related ?

[NAHANNIV]

Actually I just noticed that the AIS rollover displays ARE corrupted. On my system I see the first one displayed correctly, but then if I rollover another target I get a slightly corrupted display from the last target (I did not look carefully enough last time).

[keesverruijt]

The corruption issue has been found to be present since day 1 of the plugin, so it is not fully caused by the PPI windows. I'd say it is actually a bug in O, but we will still have to fix it as no other plugin does what we do. I will try to fix this but it will be after 3.0 because it is also present in 2.1, and we want 3.0 out there.

I cannot reproduce your zoom/pan issue at all. Both mouse and keys zooming + panning work fine for me. Are you sure you're on the production 4.8.0 opencpn release? Can you compare it to when you dock the PPI windows? Drag them to the border of the OpenCPN window until you see a blue area, then lift the mouse button.

[keesverruijt]

On my system I see the first one displayed correctly, but then if I rollover another target I get a slightly corrupted display from the last target (I did not look carefully enough last time).

I've seen those as well, it does update the bitmap but not the size of the rollover, so there is a width (and sometimes a height) distortion.

[NAHANNIV]

I have the released version of OpenCPN. 4.8.0

The lockup only happens with RADAR A PPI window displayed and RADAR A overlaying the chart. Other combinations do not seem to be a problem ?

[keesverruijt]

The lockup only happens ...

Uh how do you mean, lockup? Is the radar overlay still being updated and do AIS vessels move?

[NAHANNIV]

RADAR and AIS being updated, but can not pan or zoom chart with mouse or buttons.

[NAHANNIV]

I can Zoom the PPI window, and after zooming the PPI window it seems like one click on the chart window is recognized, re-centering the chart.

[NAHANNIV]

I deleted my OpenCPN.ini file and started from scratch to try to figure out what was causing this "lock up". It seems to be related to the "Refresh rate" parameter. I have always set it to 5. I also usually select the Shader drawing method, but had switched to Vertex Array while trying to de-bug other problems.

It seems that this was completely locking up the chart window. Lowering Refresh rate to 3 works fine.

Problem solved, but I don't think it should lock up.

[NAHANNIV]

Further to the above, My CPU utilization is less that half in this locked up situation.

[keesverruijt]

So your hunch was right — it is related to the AIS rollover. Keeping RefreshRate low improves both.

[keesverruijt]

Bingo. I was able to fix this in OpenCPN, but alas I see no way to work around these issues in the plugin. (I can for MacOS, but that doesn't help Windows...)

It is quite obvious in the code:

• To draw on an OpenGL canvas you need to provide a 'wxGLContext'.
• The plugin creates one and uses it, but since the plugin is not told what the OpenCPN wxGLContext is it cannot restore it once it is done.
• Not all OpenGL calls in OpenCPN set the context.

So the end result is that some OpenGL calls made by O end up nowhere, and the screen gets weird updates / corrupted as a result.

As to the timer, every time a Refresh() call is made for the canvas and a rollover display is visible its timer to update the display is reset to 500ms from now. So if something calls Refresh() more often than every 500ms (== plugin RefreshRate > 1) then the timer will never finish and the code to remove the rollover is never called.

Can you test with a new opencpn.exe binary from

https://www.dropbox.com/s/x7lpfp79phcofdz/opencpn-4.8.0-br24.zip?dl=0

Go to your \Program Files (x86)\OpenCPN directory, rename opencpn.exe and unzip the new version from the zip file here.

On starting you may get an error warning about crashrpt or some such; ignore this for now. If this works I will provide a better patch :-)

[NAHANNIV]

How do I ignore the missing CrashRpt1403.dll ? The only option presented is OK, and the program is not started

[keesverruijt]

Sorry, I fixed the zip file to include it

On 12 Sep 2017, at 17:38, NAHANNIV notifications@github.com wrote:

How do I ignore the missing CrashRpt1403.dll ? The only option presented is OK, and the program is not started

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/canboat/BR24radar_pi/issues/284#issuecomment-328885792, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiJetrlAOSrPBVUfgZJwz-YkzN57hRNks5shqQsgaJpZM4PQlz8.

[NAHANNIV]

OK, the AIS rollover windows seem to time out OK now.

Still see corruption of the windows.

[NAHANNIV]

More info on Zoom and Pan lockup:

Something strange is happening when Radar A PPI and PADAR A overlay are active. I set both RADARs to the same settings and tried switching the overlay between A and B. Overlay B works fine, Overlay A causes the chart window to Lock Up

[douwefokkema]

I tested on board today. Opening window A while overlay A is running locks stuff up. Did not try A overlay with only B window. Interesting that there was no locking there.

[NAHANNIV]

One more thing I noticed is that the Refresh rate setting seems to have no effect on RADAR B Overlay. It always stays choppy as if it were at Refresh rate= 1 regardless of the setting.

[keesverruijt]

One more thing I noticed is that the Refresh rate setting seems to have no effect on RADAR B Overlay. It always stays choppy as if it were at Refresh rate= 1 regardless of the setting.

Confirmed. See issue #289.

The lockups have their own issue now, #288.

[NAHANNIV]

OK, back to the original problem: RADAR window causes display corruption in OpenCPN

If this can not be fixed in the RADAR plugin, then what needs to be done ?

[keesverruijt]

I made another fix to OpenCPN, can you download

https://www.dropbox.com/s/x7lpfp79phcofdz/opencpn-4.8.0-br24.zip?dl=0

again and test whether that fixes the corruption?

[NAHANNIV]

Much worse... Never see the correct rollover window image. Eventually the chart became corrupted as well.

[keesverruijt]

Weird, it definitely solves it for me. Maybe there is something wrong with the build itself (I only compile for windows and do slight testing with it, main testing is on MacOS).

Workaround is to change the size of chart display, either change size of docked other window or change size of the OpenCPN window.

[Hakansv]

Just for info I've built and run every new update and have so far no issues. I'm on Win10, VS2013, the BR24 scanner and consequently no radar B.

[NAHANNIV]

@Hakansv Are you using @canboat latest build of OpenCPN ? I don't see that code on Github ?

My understanding is that changes relevant to display corruption are in OpenCPN.

[NAHANNIV]

I double checked my test: re-downloaded OpenCPN.exe and Crashreport.dll from @canboat dropbox. Overwrote existing versions.

Same results: With this version, if the RADAR window is open (Just RADAR A and no RADAR image needed) the AIS information rollover window in the chart window displays a corrupted piece of the chart. I never see the correct data.

Then when I close the RADAR (toolbar) and rollover an AIS target one of two things happen: 1/it works again. 2/the chart window seems to be corrupted, overzoomed ? but AIS targets are still in the same place. Changing the size of the chart window temporarily restores the correct image, but as soon as I do another rollover or pan or zoom the corrupt display returns.

[NAHANNIV]

If this problem is due to OpenCPN handling of OpenGL Should we consult @seandepagnier ? I think he added OpenGL support to OpenCPN.

[NAHANNIV]

Also, with the latest test version of OpenCPN and BR24 I am getting a crash (again) when re-starting OpenCPN after shutting down with the RADAR on.

[keesverruijt]

Sorry, I rechecked the latest zip file and it contains incorrect data. New version coming up.

[douwefokkema]

Crash after restart: is the scanner still running when you restart or has it timed out? Just so that I can try to reproduce on board.

[keesverruijt]

Here is an improved zip file:

https://www.dropbox.com/s/alfa58tjws9jzdn/opencpn-4.8.0-br24v2.zip?dl=0

The problem was in the zip file and not in the binary I built, so that is why I did not reproduce.

[NAHANNIV]

@canboat OK that version seems to fix the problem.

[NAHANNIV]

@douwefokkema I am restarting OpenCPN before the scanner has stopped.

I will try it later letting the scanner time out.

[rgleason]

When I saw him in Provincetown, MA and later in Boston in August, he mentioned that he'd had access to a BR24 Radar and had done some optimization on the Radar plugin, and had mentioned when I saw him that were were additional optimizations that could be done. He was puzzled that nobody on the team seemed interested.... hope that helps.

If this problem is due to OpenCPN handling of OpenGL Should we consult @seandepagnier ? I think he added OpenGL support to OpenCPN.

[Hakansv]

"Are you using canboat latest build of OpenCPN ? I don't see that code on Github ?" No. I build resent master, nothing else tested.

[keesverruijt]

When I saw him in Provincetown, MA and later in Boston in August, he mentioned that he'd had access to a BR24 Radar and had done some optimization on the Radar plugin, and had mentioned when I saw him that were were additional optimizations that could be done. He was puzzled that nobody on the team seemed interested.... hope that helps.

Rick, I have mentioned to you before that we have on-boarded all suggestions that he made to us in 2015. The code from then is totally incomparable with what we have now. See for yourself when Sean did work on this plugin (Oct 10 and 11, 2015):

https://github.com/canboat/BR24radar_pi/commits?author=seandepagnier

Also, please keep github issues to the point instead of general discussion. Thank you.

[keesverruijt]

I created two pull requests for OpenCPN:

https://github.com/OpenCPN/OpenCPN/issues/884 https://github.com/OpenCPN/OpenCPN/issues/886

which I'm sure will be in the next OpenCPN release. We may want to create a better patch that does not depend on the CrashRpt.dll and possibly a macOS version which can be used until the next release of OpenCPN is released.

[keesverruijt]

Team, please keep each issue separate. Let's not create a CruiserForum 2000 item long thread here! Please use issue #281 for the crash issue; I've just re-opened it.

[rgleason]

Sorry, did not remember that.

[douwefokkema]

You also mentioned non dragging (blocking) windows. Found same on my slow Atom computer. Found a solution by taking out the smoothing of polygons (introduced in O 4.6) out of O. Dramatically speeds up O. Requires another opencpn.exe: https://www.dropbox.com/s/qq148ziei22yrhw/opencpn.exe?dl=0

[NAHANNIV]

You also mentioned non dragging (blocking) windows. Found same on my slow Atom computer. Found a solution by taking out the smoothing of polygons (introduced in O 4.6) out of O. Dramatically speeds up O. Requires another opencpn.exe: https://www.dropbox.com/s/qq148ziei22yrhw/opencpn.exe?dl=0

@douwefokkema The changes @canboat made to the Plugin completely solved the issue of the "blocked" chart for me. I have recently updated from 4.5->4.6->4.8 in order to use the latest BR24PI and have not noticed a slowdown on my system.

[Hakansv]

Back to topic for this issue... (I'm not sure I've followed all details here...) For info is the corrupt AIS rollover info when RadarWindow is shown still valid also on my Win10 and recent git canboat code. (I use O 4.8 extended with Kees' rollover time out fix)

[NAHANNIV]

Back to topic for this issue... (I'm not sure I've followed all details here...) For info is the corrupt AIS rollover info when RadarWindow is shown still valid also on my Win10 and recent git canboat code. (I use O 4.8 extended with Kees' rollover time out fix)

@Hakansv @canboat has 2 pull requests (884 886) for OpenCPN to fix rollover timeouts and corruption of rollover (and other) windows. The corruption issue requires a corresponding change in the plugin. I am still seeing crashes when restarting OpenCPN with the scanner still ON (see other issue).