OpenCPN Beta test 4.1.602 Release

[NahanniV]

Another image zoomed in on the google image, in the problem state, cursor hovering over the skewed chart.

The area around the google image is pink as if it were part of the skewed chart, but it is not.

Also one last weird thing: If I leave the cursor hovering over the skewed chart like this, approximately every 2 seconds the pink area becomes more opaque until no chart detail is visible, only pink.

[fogmachine]

Pardon me if this is dumb, I'm not familiar with the thread model or how locking/concurrency works in OCPN (yet).

WRT the null pointer SEGV reported in #11 (which is 100% reproducible using the flow in FS#1764):

The code that deletes routes (RouteManagerDialog::OnRteDeleteClick) is pretty straight-forward, but the code that detects selectable objects (ChartCanvas::OnRolloverPopupTimerEvent) sees visible objects even after they're deleted. Is it possible there's a race condition here? I don't see any object locking/unlocking. The crash happens only when there are many points in the route which take longer to delete than a direct path.

Changing m_rollover_popup_timer_msec from 20 to 1000 made the crash go away, but that's not a good solution.

[NahanniV]

Originally Posted by NahanniV

Yes, I am running with OpenGl.

In trying to figure out exactly what causes this, I noticed that when this happens there is always a skewed chart in the area. If I hover over the skewed chart selector the the problem area around the google map is highlighted even though the skewed chart is not in that area.
When I disable the skewed chart I do not get this problem.

The skewed chart is:

208601
Datum: NAD83
Projection: Mercator

Tried the same scenario on a Linux Laptop and had the same Problem.

Cheers,
JM.

[bdbcat]

NahanniV...

Regarding the trouble with google-earth charts and the image smearing:

I do not have the skewed Canadian charts for Lake Ontario. Where did you get them?

Thanks
Dave

[NahanniV]

Originally Posted by bdbcat

NahanniV...

Regarding the trouble with google-earth charts and the image smearing:

I do not have the skewed Canadian charts for Lake Ontario. Where did you get them?

Thanks
Dave

I bought them from the CHS on a CD many years ago. That particular chart is 680KB zipped, how can I get it to you?

JM.

[NahanniV]

Here is an example not involving Copyrighted Ancient Canadian charts or homemade Google Images, just current free US RNCs.

To duplicate the problem, zoom in on the non skewed chart 2198 until the skewed chart 2199 is off the screen then pan or zoom.

Cheers,
JM.

[bdbcat]

NahanniV....

Thanks for the catch on "skewed chart smearing", and finding a lat/lon in NOAA charts that causes the glitch. Easily reproduced, fix is in the works.

Root cause: Highly zoomed skewed charts can cause excessively complex region calculations, due to the nature of the rectangle-based algorithm. The code tried to see and avoid this situation, but made a wrong turn at one spot. The result was that the screen region associated with the skewed chart was miscalculated. This effect propagated through to the screen rendering loop, with erratic results.

jm, are you building from source? If so, the fix will be in github by close of play tonight.

Thanks again
Dave

[NahanniV]

Originally Posted by bdbcat

NahanniV....

Thanks for the catch on "skewed chart smearing", and finding a lat/lon in NOAA charts that causes the glitch. Easily reproduced, fix is in the works.

Root cause: Highly zoomed skewed charts can cause excessively complex region calculations, due to the nature of the rectangle-based algorithm. The code tried to see and avoid this situation, but made a wrong turn at one spot. The result was that the screen region associated with the skewed chart was miscalculated. This effect propagated through to the screen rendering loop, with erratic results.

jm, are you building from source? If so, the fix will be in github by close of play tonight.

Thanks again
Dave

I can build it on Linux and try it tomorrow.

Thanks,
JM.

[NahanniV]

Originally Posted by bdbcat

NahanniV....

Thanks for the catch on "skewed chart smearing", and finding a lat/lon in NOAA charts that causes the glitch. Easily reproduced, fix is in the works.

Root cause: Highly zoomed skewed charts can cause excessively complex region calculations, due to the nature of the rectangle-based algorithm. The code tried to see and avoid this situation, but made a wrong turn at one spot. The result was that the screen region associated with the skewed chart was miscalculated. This effect propagated through to the screen rendering loop, with erratic results.

jm, are you building from source? If so, the fix will be in github by close of play tonight.

Thanks again
Dave

The fix for "Skewed chart smearing" seems to work ok on Linux.

However, I forgot to mention another problem I had with the chart selector bar on Linux: It is always under OpenCPN. It's at the correct spot on the screen, it moves when the OpenCPN window is resized, but it can't be seen if the OpenCPN window is displayed.

[bdbcat]

NahanniV...

What flavor of linux are you running with?

Thanks for testing and reporting on the smearing problem. Glad its fixed.

Dave

[nohal]

Dave...
As far as I remember, Navigatrix is a remastered LUbuntu (using LXDE)
FWIW I haven't seen it with wrong z-order on Linux, ever. But what I see on Gnome Shell is it is treated like another independent window while switching tasks, it just never got annoying enough to get it fixed...

Pavel

[NahanniV]

Originally Posted by bdbcat

NahanniV...

What flavor of linux are you running with?

Thanks for testing and reporting on the smearing problem. Glad its fixed.

Dave

It's a nautical distribution called Navagatrix.
I think it's based on Ubuntu. That laptop is at my boat, I can get more specifics tomorrow.

I take it that others are not seeing this problem ?

JM.

[transmitterdan]

It seems that the latest git updates have broken the build process at least for me. I build in Windows 8.1 and get the following error:

LINK : fatal error LNK1181: cannot open input file 'Release\LIB_BZIP.lib' [C:\storage\obeta\OpenCPN\build\plugins\grib_pi\gri b_pi.v
cxproj]
Done Building Project "C:\storage\obeta\OpenCPN\build\plugins\grib_pi\gr ib_pi.vcxproj" (default targets) -- FAILED.

The file LIB_BZIP.dll is created but not the file LIB_BZIP.lib.

[bdbcat]

TransmitterDan...

No trouble building with VS2013 on Win7.

Is the "missing" file 'Release\LIB_BZIP.lib' actually present? It is for me. It gets built as a dependency by the grib_pi target.

Maybe try to start over with a fresh build directory?

Dave

[ChuckSK]

Originally Posted by bdbcat

TransmitterDan...

No trouble building with VS2013 on Win7.

Is the "missing" file 'Release\LIB_BZIP.lib' actually present? It is for me. It gets built as a dependency by the grib_pi target.

Maybe try to start over with a fresh build directory?

Dave

This fixed it for me.

diff --git a/plugins/grib_pi/CMakeLists.txt b/plugins/grib_pi/CMakeLists.txt
index 1257330..67623f8 100644
--- a/plugins/grib_pi/CMakeLists.txt
+++ b/plugins/grib_pi/CMakeLists.txt
@@ -120,6 +120,8 @@ IF(WIN32)
 ENDIF(WIN32)
 ADD_LIBRARY(${PACKAGE_NAME} SHARED ${SRC_GRIB})
 
+SET(BUILD_SHARED_LIBS "OFF")
+
 IF(NOT UNIX)
     SET(SRC_BZIP
             src/bzip2/bzlib.c

chuck