AIS Rollover display corrupted when RADAR window is displayed about br24radar_pi HOT 54 CLOSED

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

from br24radar_pi.

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.

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

from br24radar_pi.

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

from br24radar_pi.

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 ?

from br24radar_pi.

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).

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

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 ?

from br24radar_pi.

The lockup only happens ...

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

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

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

from br24radar_pi.

from br24radar_pi.

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 :-)

from br24radar_pi.

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

from br24radar_pi.

from br24radar_pi.

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

Still see corruption of the windows.

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

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 ?

from br24radar_pi.

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?

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

@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.

from br24radar_pi.

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.

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

from br24radar_pi.

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.

from br24radar_pi.

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.

from br24radar_pi.

@canboat OK that version seems to fix the problem.

from br24radar_pi.

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

I will try it later letting the scanner time out.

from br24radar_pi.

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.

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

I created two pull requests for OpenCPN:

OpenCPN/OpenCPN#884
OpenCPN/OpenCPN#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.

from br24radar_pi.

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.

from br24radar_pi.

Sorry, did not remember that.

from br24radar_pi.

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

from br24radar_pi.

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.

from br24radar_pi.

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)

from br24radar_pi.

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).

from br24radar_pi.

OK - Thanks for the reminder and excuse my indolence. :-)
And when I build including Kees branch "pass-context-to-plugin" the AIS rollover works fine also when RadarWindow is shown. Very good. So we all await Dave's merging into O. Thanks

from br24radar_pi.

Just to reiterate: With Latest Plugin and and patched version of OpenCPN from @canboat
This issue (Corrupted display in OpenCPN) is resolved for me.

from br24radar_pi.

from br24radar_pi.

Fixed with OpenCPN 4.8.2.

from br24radar_pi.