The rendering seems most prone to fail at three points in openCPN.
First the AIS triangles and the lines that extend forward from the triangles that show the ship's projected course.
Second, the 4g radar plugin fails at the render triangle point in the code - it has data but doesn't paint
Third, there are frequent problems with charts
made from google earth
when they are quilted together. These problems show as blank rectangles in the quilt and as occasional black squares.
This third problem may however be a result of trying to quilt too many chartlets together - my maximum open charts
is set at 1000 and even so the program generally chokes if I try to zoom out. Generally the best strategy is to focus in using CMap and then switch to GE chartlets since openCPN is quite happy if there are less than a dozen to quilt - much more than that and it gets confused. (ie the quilt fails and it shows a mixture of CMap and GE chartlets and blank rectangles).
I *think* I see a correlation between the AIS triangles and the google earth
chartlets. If I'm showing GE charts then the AIS triangles are drawn much more sloppily; if I'm showing only CMap the AIS triangles are often fine. That seems to suggest some kind of a resource issue - it seems as if the GE chartlets need more processing power/memory to quilt and to display and that leaves less oomph to display the AIS triangles properly. Or maybe that's a red herring...
I don't think this is really a hardware
limitation - it chokes more on the machine with the fastest processor and most memory.
Clearly there is something about the way openGL is behaving on these linux boxes that doesn't mesh well with openCPN.
I don't see these issues in any other program but then I don't use any other graphics intensive program so extensively so that's not really a useful data point.
If you do have any ideas about alterations I can make to the environment
that would make a difference I'm more than willing to try.