Beta Test / Technical

[seandepagnier]

Originally Posted by CarCode

Dave,
I have had only a quick look at this code and guessed it is not needed for Mac OS X.

I visited another boat yesterday (sailing vessel zen again) and they were very eager to enable the texture cache under osx, because here in the indian ocean we have sometimes 50 or more google charts quilted all visible at the same time. The lag is considerable sometimes 3-4 seconds the program is locked on his quad core machine making it annoying but still usable. With the cache then there is no longer a noticed lag.

I think if you only use few charts say 4 or 5 at a time that are not very high resolution and have a fast computer or don't care to wait a few seconds when switching charts, then it's ok for you not to check this option which is why it is after all just an option.

He also informed me that opencpn was much better with version 4 only because it ran too slowly in version 3 and before on his mac.


As far as the mmx intrinsics... I have no idea why it would be a bad thing to get a 5-16x speedup with no tradoff for a cpu intensive operation. I intend to provide neon intrinsics for arm platform soon.

[seandepagnier]

Originally Posted by Hakan

Dave...
Thanks, now builds OK in VS2010 and VS2013 with reference to glTexCache.
But still the same mipmap errors in VS2010.
Håkan

I think vs2013 maybe enables support for such intrinsics, but vs2010 cannot, so we need to check the visual studio version with the preprocessor and probably disable intrinsics for visual studio 2010 if we care about supporting this compiler.

[freesails]

AHOY Boaties - now that the Tsunami wave of effort to get the payable version of OPCN for Android into the Google Play store has been successfully achieved.

Thinks - One could of course wonder why it was not announced at the beginning of its development that it was intended to be a money making exercise.

Openness and honesty is to be admired - secrecy should be condemned.

All is not lost however as attention has now belatedly [or could it be reluctantly] returned to all of the remaining operating system users who are the bedrock of this project. The tens of thousands of us who use Windows, Mac or Linux and who have watched and waited patiently since the last Beta which was issued on the 2015-06-02

An earlier post on this thread now confirms a new Beta release can now be expected next week - HOORAY

[bcn]

Freesails,

what you are stating about the announcement is wrong.

Please reread the first post about AOCPN here (April, 9th):
http://www.cruisersforum.com/forums/...ml#post1796676

The Plan:
I plan to run a standard Alpha/Beta test series on O for android, hosted on this Forum. It will take a while to get through all of the issues that will arise relative to cross platform support, and the UI design issues will require some extensive iteration.

Ultimately, when ready for Release, I will offer OCPN for android on the Google Play store in order to reach the broadest possible user base. There will be a nominal fee charged for the download.

[freesails]

Originally Posted by bcn

Freesails,

what you are stating about the announcement is wrong.

Please reread the first post about AOCPN here (April, 9th):
http://www.cruisersforum.com/forums/...ml#post1796676

My apologies for overlooking this

[CarCode]

Originally Posted by boat_alexandra

I visited another boat yesterday (sailing vessel zen again) and they were very eager to enable the texture cache under osx, because here in the indian ocean we have sometimes 50 or more google charts quilted all visible at the same time. The lag is considerable sometimes 3-4 seconds the program is locked on his quad core machine making it annoying but still usable. With the cache then there is no longer a noticed lag.

I think if you only use few charts say 4 or 5 at a time that are not very high resolution and have a fast computer or don't care to wait a few seconds when switching charts, then it's ok for you not to check this option which is why it is after all just an option.

He also informed me that opencpn was much better with version 4 only because it ran too slowly in version 3 and before on his mac.


As far as the mmx intrinsics... I have no idea why it would be a bad thing to get a 5-16x speedup with no tradoff for a cpu intensive operation. I intend to provide neon intrinsics for arm platform soon.

I think they have used perhaps the wrong build environment for OS X. Or maybe at the south half of the world things are turning the other way round as of the north half. I always use the latest wxWidgets 3.1 trunk and Xcode. I've had never seen the busy cursor when not programed so and CPU usage was never more than 7 %. Your optimization might be useful for a small computer like your Raspberry but not for a Mac power machine.

Gerhard

[seandepagnier]

Originally Posted by CarCode

I think they have used perhaps the wrong build environment for OS X. Or maybe at the south half of the world things are turning the other way round as of the north half. I always use the latest wxWidgets 3.1 trunk and Xcode. I've had never seen the busy cursor when not programed so and CPU usage was never more than 7 %. Your optimization might be useful for a small computer like your Raspberry but not for a Mac power machine.

Gerhard

I still don't believe you are testing this with 50 or more visible charts in a single quilt at the same time. As far as the build environment, I have no idea but they just downloaded it already built from opencpn.org. If you can provide a different binary for testing that would be useful.

I don't know if their mac is the most powerful one available, probably not, I only noticed it's a quad core.

Anyone can download the charts from their website if you have interest to test.
Yacht Zen Again

[CarCode]

Originally Posted by boat_alexandra

I still don't believe you are testing this with 50 or more visible charts in a single quilt at the same time. As far as the build environment, I have no idea but they just downloaded it already built from opencpn.org. If you can provide a different binary for testing that would be useful.

I don't know if their mac is the most powerful one available, probably not, I only noticed it's a quad core.

Anyone can download the charts from their website if you have interest to test.
Yacht Zen Again

Believe what you want. The bottleneck was never the amount of loaded charts here with OS X but rather the poor development of the wxWidgets port for OS X. Also the used compiler is more importand than any compressing, caching etc. It would be even better when the code was rewritten in Objective-C or even Swift. I know what I say using some Objective-C code pieces. wxWidgets is a wrapper for mostly outdated OS X functions. Using the OS X functions directly will speed up enormous.

Gerhard

[Hakan]

Originally Posted by boat_alexandra

I think vs2013 maybe enables support for such intrinsics, but vs2010 cannot, so we need to check the visual studio version with the preprocessor and probably disable intrinsics for visual studio 2010 if we care about supporting this compiler.

Sean... and Pavel & Dave & more....
It's a of course a good question if/when we shall stop support VS2010 and builds on WinXP. As long as a compilation method using VS2010 is described at OpenCPN.org the support is "official" and would be maintained.

If I'm the only one still like my old XP it's of course not worth extra work and time consuming efforts from you very valuable coders. I don't have your knowledge to change the code to fit my personal requirements and need your help with this.

Ones the decision is to end WinXP build support I can survive but than we have to say that and change Pavel's description in the wiki.

A reason to end VS2010 support would be that the OCPN code is now growing outside its limitations and no longer can support new efficiencies, like Sean indicates.
I can't judge, discussion and decision, please.

Thanks
Håkan

[Hakan]

In lack of a recent tread here for 4.1.915 I use this!?

Wow - Have you seen the new NMEA debug filter, dev by Sean and merged by Dave yesterday?
It's great! Just type the whole or parts of the ID string, like IIHD, and only those strings are listed. A great and simple tool.
Thanks
Håkan

[seandepagnier]

Originally Posted by Hakan

Sean... and Pavel & Dave & more....
It's a of course a good question if/when we shall stop support VS2010 and builds on WinXP. As long as a compilation method using VS2010 is described at OpenCPN.org the support is "official" and would be maintained.

I think to support VS2010 we simply need a #ifdef _MSC_VER > <number> to the right place in mipmap.c

Anyway.. as far as supporting winxp will probably not go away for a very long time, as I have just merged mingw support which can compile for xp even without service packs and also other even older versions of windows like win98. The resulting install package is 23M vs 27.5M for the visual studio compiled one with identical functionality.

I am in favor of dropping visual studio all together, but I would not vote on this decision because I am not a windows user.

[bdbcat]

Hakan/Sean...

Build for VS2010 on XP corrected in github now. Sean's _MSC_VER method adopted. This means that MMX intrinsic mipmap code will not be compiled at all on VS2010, and the default methods will be used.

Dave

[NahanniV]

I had a problem building the latest version from Github today on my boats ARM computer.

[ 37%] Building C object src/glu/CMakeFiles/GLU_static.dir/libutil/error.c.o
cd /home/aruntu/OpenCPN/build/src/glu && /usr/bin/cc -DARMHF -DUSE_GLU_TESS -DocpnUSE_GL -DocpnUSE_GLES -O3 -DNDEBUG -I/home/aruntu/OpenCPN/include -g -O2 -o CMakeFiles/GLU_static.dir/libutil/error.c.o -c /home/aruntu/OpenCPN/src/glu/libutil/error.c
/home/aruntu/OpenCPN/src/glu/libutil/error.c:31:19: fatal error: gluos.h: No such file or directory
#include "gluos.h"
^
compilation terminated.

It was a fresh clone.

?

Cheers,
JM.

[seandepagnier]

You have OpenCPN/src/glu/include/gluos.h ?

[Hakan]

Originally Posted by bdbcat

Hakan/Sean...

Build for VS2010 on XP corrected in github now. Sean's _MSC_VER method adopted. This means that MMX intrinsic mipmap code will not be compiled at all on VS2010, and the default methods will be used.

Dave

Thanks, no mipmap errors in VS2010. But a question to see if I understands this correct:
Giving a suitable CPU on a specific PC some rendering is now faster if the binary is built by VS2013 compared to a binary built by VS2010. - Correct?


BUT.. also in VS2010 (and not in VS2013) the release .lib files are no longer build???
I build for release (opencpn is still start up project) and have rebuilt it all, several times.
This could be the initial cause: (When trying to build opencpn only)

------ Build started: Project: opencpn, Configuration: Release Win32 ------
LINK : fatal error LNK1181: cannot open input file '..\buildwin\libcurl.lib'

And .. In VS2013 the Release builds OK but the Package build now receives errors:

Error    1    error : Problem running NSIS command: "C:/Program Files (x86)/NSIS/Unicode/makensis.exe" "C:/builds/OpenCPN/build/_CPack_Packages/win32/NSIS/project.nsi"    C:\builds\OpenCPN\build\EXEC    PACKAGE
Error    2    error : Problem compressing the directory    C:\builds\OpenCPN\build\EXEC    PACKAGE
Error    3    error : Error when generating package: OpenCPN    C:\builds\OpenCPN\build\EXEC    PACKAGE
Error    4    error MSB3073: The command "setlocal
cd C:\builds\OpenCPN\build
if %errorlevel% neq 0 goto :cmEnd
C:
if %errorlevel% neq 0 goto :cmEnd
"C:\Program Files (x86)\CMake\bin\cpack.exe" -C Release --config ./CPackConfig.cmake
if %errorlevel% neq 0 goto :cmEnd
:cmEnd
endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone
:cmErrorLevel
exit /b %1
:cmDone
if %errorlevel% neq 0 goto :VCEnd
:VCEnd" exited with code 1.    C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets    132    5    PACKAGE

Thanks
Håkan