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.