OpenCPN on OS X

[darkaegisagain]

I have been coming up to speed on OpenCPN on OS X and there are a few issues I should report.

This one is easy... The 7z utilities for pilot maps on OS X are pretty much non-functional links, I found the only way to get it to work was to actually build the command line version of the extractor from source. So that needs to be fixed (or released using some other compressed format)

This one is hard...The drawing libraries used in wxWidgets are really old carbon frameworks, I worked at Apple in the CoreGraphics group and I can tell you the frameworks wxWidgets are using are effectively no longer supported. Apple no longer cares about carbon apps, it hasn't been a priority since Tiger. I would recommend updating wxWidgets to use something more up to date like Quartz. I am sure the answer is we have to live on wxWidgets because of cross platform issues but its noticeably slower than GPSNavX which uses the Quartz interfaces. Quartz on OS X does all the heavy lifting and you get acceleration from the GPU.

Just my two cents, I would like to contribute to OpenCPN and I plan to use it but the cross platform wxWidgets libraries really need some work.

[daddle]

Ya wxWidgets was not the best choice. Especially for portability. But we are stuck with it. I think all the odd OS X behavior can be traced to its poor implementation.

My Purify code checker barfed on wxWidgets with approximately one billion coding infractions. I gave up at that point. But maybe I made a mistake...

[nohal]

Guys...
The upcoming wx 3.0 (we build ok against the dev 2.9, BTW) is of course Quartz based. But as you can see in the rest of recent Mac threads, there are some other problems with it (notably wxRegion performance is the big one right now).
As you can imagine, switching to another GUI toolkit at this point is unrealistic in a reasonable timeframe, so we will have to live with what we have at least for the foreseeable future.
One note: Please be specific with the problems you find, as we kind of lack Macs, for example for me fixing any problem described just as "it sucks on OS X" is really impossible
And yes, we are interested in complete outputs of commercial tools like Purify on the OpenCPN codebase. Just the count of "something" it reported is of very little value though.

Pavel

[bdbcat]

darkaegisagain...

Thanks for the comments.
Here's the situation: We are working to migrate OpenCPN on OS X to wxWidgets 2.9.4, which becomes easily 3.0 sometime this year maybe. This will give us Cocoa 64bit support, and leave carbon far behind.

We build and run on 2.9.4 now, with one big problem. The wxWidgets class wxRegion for polygon shape is bad broken. There is apparently no native support for such a class in the OS X libraries, so wxWidgets 2.9.4 employs a suboptimal approach using wxBitmap masks to create the polygon region. It is very slow. We depend on this class heavily for screen quilting. So, OpenCPN for wxWidgets 2.9.4 on OS X is unusable.

So, we have two choices:
1. Wait and hope that wxWidgets 3.0 for OS X will implement wxRegion in some better way, for example as maybe Cairo path-oriented backend.
2. ..or, implement a generic, cross-platform OCPNRegion class, derived from wxRegion, with methods that are native to OCPN data structures, and will migrate easily.

I took a very quick look at #2. I find that wxWidgets 2.8 for linux uses the gdk region classes, which are deprecated in gdk. But they work. I looked at the (deprecated) gdk code, and find that it is just data structures and logic, with very little (no??) dependence on graphics backend. So, we could simply extract the gdk source (LGPL license), bring it into OpenCPN, and hook it up. This would work.

So, my inclination is to take the bull by the horns and fix this inside OpenCPN. I'm afraid the wxWidgets port guys will have way too much on their hands to focus much on our wxRegion problem. If 3.0 releases without a fix for OS X, we are stuck. There are only a few google hits on this problem, and most are us

Now, having said all that, our development resources are thin on the ground. We are working priorities very carefully. OS X is lower on the list than some Windows issues, as I'm sure you understand. And as Pavel says, our Mac dev resource pool is very shallow.

So, is this wxRegion project something that you might be able to help us with?

Or, anyone else, for that matter. The port of gdk regions could surely start on linux, and probably should, anyway.

Dave

[darkaegisagain]

bdbcat, I can take a look. I would have to do some digging to understand the overall architecture of this and how it works with wxWidgets. My expertise is in OpenGL and OpenCL which lives under the Quartz / CoreAnimation / Window server.

I know OpenGL is an option but it can't do everything as easily as Quartz. Internally Quartz uses a tiled rendering system, something I would recommend moving forward for OpenCPN because the memory footprint from the BSB maps is actually quite high.

[cagney]

Originally Posted by darkaegisagain

I have been coming up to speed on OpenCPN on OS X and there are a few issues I should report.

This one is easy... The 7z utilities for pilot maps on OS X are pretty much non-functional links, I found the only way to get it to work was to actually build the command line version of the extractor from source. So that needs to be fixed (or released using some other compressed format)

......
.

Looking around a bit, there seems to be a few alternatives in Mac for handling 7z. Are all of those just crap?
How about rar on OSX?
I can easily change to another format, but hesitate to have multiple formats available. The size situation is roughly like this. A rar archive is about 10% larger than a 7z archive. Zip and tgz are about 10% larger than rar.

Thomas

[darkaegisagain]

From what I can tell they where bad links or just crap... any site posting MacClean should scare you..

Some of the links just took you to other sites or just really old (2008 - Sixty Five, Ltd.)

Or offline.. from macupdate

Rockin' Kat commented on 28 Mar 2013
The developer's page is offline... currently replaced by a domain squatter who has taken the domain for it and is trying to sell it for $70. His other domain which the download link goes to is not responding. It's been over 160 days since the developer's account has shown activity on MacUpdate. It may be time to find something else. :-(

[darkaegisagain]

Are .kap files not run length encoded? I wrote my own BSB viewer a few years ago and seem to remember that. RLE works great for irregular fills but fails on single pixel updates, I wonder if there is a better way to do this. (it would save on the memory loading footprint on mobile devices too)

[nohal]

Don't know much about how this iStuff works, but after about 1 minute with the big brother, Keka - the free Mac OS X file archiver does look neither dead nor suspicious to me...

Pavel

[darkaegisagain]

One out of 4 is good!

[nohal]

OK, if this one is up to the expectations (Is it? I really don't know), maybe we can just link to it and be done...

[darkaegisagain]

I just tested it and it works, remove all the bogus links and leave Keka