OpenCPN Beta Version 3.3.1731 Released

[Ptizef]

In addition to what have said Gilletarom, on my system when smooth zooming in on, the zoom level is not constant. One click on in or out buttons = small zoom step, the next click = normal zoom step and so on ...
JP

[Gilletarom]

Hello Dave, hello Jean-Pierre,

I correct the contents of my post #11 on Grib plugin button in the toolbar icons.

I wrote that I had clicked the button 3 times before the plugin window appears. It's true .... But it is also because Gilletarom has no patience and requires that everything goes faster.

In fact, the first click, the plugin starts but does not see anything on the screen. The plugin opens the previous grib file. This takes some time. Too much time .... Impatient, I clicked a second time. And if I saw "a flash" is that the plugin window that opened was closed by the second click.
Obviously, it took me a third click to the window opens .....

Ah ..... I thought that with the 331731 version of all go faster than lightning .... Pfuuuuu

[rgleason]

In ENC the left mouse does not seem to grab chart and move it, as with BSB.
Is this normal? v3.3.1731 Some zooming problems with wheel, pretty fast and tend to overzoom, that back out and overzoom. Need to put it on a leash or something. Been using texture cache and accel all checked with smooth zoom checked.

PS: Arrows for panning and "-" and "=" for = are working nicely now.

[rgleason]

I just updated ENC and RNC charts and the default install has extra ENC-Root and RNC-Root directories. It seemed like Opencpn was having more difficulty than normal with this, so I reduced the pathname lengths by eliminating unnecessary subdir.

I wonder if Opencpn processes are sensitive to longer chart pathnames, causing time spent finding data?

[seandepagnier]

Originally Posted by Gilletarom

Hello Dave,

Maybe what I'll say he has already been reported.

With OpenGL ON and all options OpenGL On :

- If "smooth Panning / Zooming" is checked, you have to double click on the Zoom In and Zoom out they work for. This is not normal.

Are you sure you aren't just tapping the button? Try in touchscreen mode. Otherwise, it zooms while the mouse button is down for better control.


Otherwise.. we need to slow the mouse wheel down as suggested by pitzef, and it fixes problems or?

[Ptizef]

I tried "texture compression catching" on my small net book Asus W8.1
The expected elapse time went up to 15 hours !

I tried to click on "skip" to stop the process and got a crash

my raster DB is 2GO and 546 files. may be it's too large ?

Is there any chance to speed up the process ?

JP

[rgleason]

It is probably not my place to say this, but there has been a big effort to make Opencpn better in the current beta. There is likely to be some fallout from that, so we need to be patient and work through the problems. Everyone is essential to this process, both testing and programming. So lets just remember this is a beta version (a big test) and pretty soon with everyone working together as a team, it will be a faster better new version of Opencpn! Its a big effort, and as a User too, I'd like to thank everyone for their work.

[Icnoships]

Dave
only vaguely related to the beta testing but have been struggling to compile O for a while now … since midway through the merging of the optimised code..

OSX 10.9.3 against WX 3.0.0, the same problem with both cmake in terminal & Xcode (5.1.1).

All the targets compile OK up until at 60 % there is a linker problem with OpenCPN….

Terminal output is very longwinded but the meat of it is as follows -

[ 61%] Building C object CMakeFiles/OpenCPN.dir/src/macutils.c.o
Linking CXX executable OpenCPN.app/Contents/MacOS/OpenCPN
Undefined symbols for architecture x86_64:
"std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find_last_of(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned long) const", referenced from:
wxString::find_last_of(wxString const&, unsigned long) const in libwx_baseu-3.0.a(baselib_filename.o)

anon anon -

ending with -

"non-virtual thunk to wxGenericListCtrl::GetSizeAvailableForScrollTarget (wxSize const&)", referenced from:
vtable for OCPNListCtrl in OCPNListCtrl.cpp.o
vtable for OCPNTrackListCtrl in TrackPropDlg.cpp.o
vtable for OCPNOffsetListCtrl in libS57ENC.a(cm93.cpp.o)
"operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, wxScopedCharTypeBuffer<char> const&)", referenced from:
operator<<(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, Table&) in printtable.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [OpenCPN.app/Contents/MacOS/OpenCPN] Error 1
make[1]: *** [CMakeFiles/OpenCPN.dir/all] Error 2
make: *** [all] Error 2
x:build mo$

from gooogling i gather that - “It means you have declared virtual functions but you haven't defined any of them non-inline”

more esoteric info here - Undefined symbol vtable: what the F*** does that mean? - Educated Guesswork

The define in “CMakeLists” helped by saving editing 3 src files as Gerhard pointed out but had no effect on this one….

Any pointers much appreciated.

Btw never did get to the bottom of the OpenGL issues in 10.7.5, data ribbon to the screen on macbook chafed through … it went blind..game over..knew i should have rigging taped it.

Mo

[CarCode]

Mo,

I'm not sure but Sean has used in his "Optimizations" instead of wxString the standard string functions. I wish these "Optimizations" has never found its way into the master code. There are too many problems now.
BTW it might be better for Mac OS X to use the latest wx3.1.0 instead of wx3.0. There are many bugs fixed since wx3.0 for OS X.

Gerhard

[AISEAG]

Hello,

First of all, congrats to the team for the good work.

2 screens shots of the same area

OpenCPN 1606 & 1731 with OpenGL On

Differences in the triangle area.

Serge

[nohal]

Mo...
It looks like stdlib is not linked properly - I have seen something similar when building imgkap on OS X - "-lstdc++" is needed there to make the linker happy
See linker - C++ linking error after upgrading to Mac OS X 10.9 / Xcode 5.0.1 - Stack Overflow

Pavel

[HappySeagull]

I am trying to follow along with XP and a single processor machine (1.73ghz and 512mb ram) so a lot of this is beyond me.
However, I do see that OpenGL on "scroll wheel zooming" on the cached charts is better-I made a special folder to limit time-of-caching. However, if I de-select smooth zooming, performance is not noticeably better than without GL . I notice that 16mb appears as my cache memory by default and am not sure whether to change it? Am I right to believe this is the video ram or the portion of shared memory on an integrated card?

I also note some peculiarities making routes OpenGL on, but only when zooming while I make, say, the third waypoint, scroll zoom (Zoom to cursor on) , then ESC. Sometimes the route will disappear. I have managed to freeze O without generating a report. This might relate to pdubs issue...
Otherwise, it all seems to work very well and very fast when I stay away from the difficult stuff and just accept normal incremental zooming and panning. Perhaps when it is settled, there could be a whole separate tab for machines with the "required specs" to save generating a lot of queries from those of us at the base of the equipment pyramid that will never get the full benefit of advanced features.

[sailorF54]

Bug #1379 (unk SBDARE Natsur 51 = Wd (weed)) has not been corrected.
See flyspray for fresh French example

BTW
In the discussion Dave asked for a reference on ECDIS seabed attributes
Here is one
http://www.nauticalcharts.noaa.gov/m...1/ChartNo1.pdf

[seandepagnier]

Originally Posted by Icnoships

[ 61%] Building C object CMakeFiles/OpenCPN.dir/src/macutils.c.o
Linking CXX executable OpenCPN.app/Contents/MacOS/OpenCPN
Undefined symbols for architecture x86_64:
"std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::find_last_of(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > const&, unsigned long) const", referenced from:
wxString::find_last_of(wxString const&, unsigned long) const in libwx_baseu-3.0.a(baselib_filename.o)

Why are you linking with a static library? You must build wxwidgets as dynamic libraries or the plugins won't work correctly as some of them use symbols in wxwidgets that the main program does not, and linking statically discards those ones.

It looks like you aren't linking with libstdc++ as pavel suggested.


Gerhard,
The reason to use std::string is that it doesn't perform (extremely inefficiently implementation of) unicode conversion of every single character received in an nmea stream. On slow computers this reduces cpu from 5% to less than 1% when opencpn is doing nothing but reading from a gps. Imagine having several sensors, it could drive up the idle cpu noticably even on a normal laptop. Since cpu consumption is directly related to power consumption, it is an advantage to reduce it in all cases to stop wasting power on everyone's computer.

If you want to complain, please list the individual commits you have reverted and what was fixed by doing so. We can then accept temporary reverts immediately if it fixes a major problem while a solution is worked on. I will ignore comments like "too many issues" because it fails to address any of them.

[tom_BigSpeedy]

Hi there,

I know this not the precise post you'd like to see, and maybe also not 100% related to 1731, but I can confirm some unclear hangups of the system, as stated earlier in the thread.
I did compile my own versions till the morning of June 01 when I left for a doublehanded 500 miles race. Already the week before, I noticed those hangups, w/o a real crashdump. It simply comes to a standstill and doesn't react anymore (instruments are frozen), after 1 ... 3 hours. You have to kill O via task manager ...
It's Win7, VC2010, wx 2.8.12, no matter if OpenGL on or off. I usually have it off, but it also happened with OpenGL on (standard settings).
I hope that helps at least a bit.
I'll use the official 3.3.1731 for further testing now.

PS : I tried testing the weather_routing plugin during the race, but due to missing currents for the Adriatic Sea and unprecise gribs I had to take my own decisions, although the plugin did work in principle.
PSS : I did race with 3.3.1606 and it worked fine for me w/o problems.

Thomas