I have made some good progress with the Intel VBO error case. Here is what I know.
1. The Intel drivers throw an unexpected (and seemingly nonsensical) error under certain conditions. For OCPN, those conditions can happen when tracks are rendered, though not always, and not predictably.
2. When tested downstream, the GL error is not handled well by OCPN. This happens in the VBO rendering code section.
3. The incorrect OCPN error handling soon leads to a crash.
4. If VBO is disabled, the unexpected error still happens. But the OCPN VBO code is not activated, so no harm is done.
This sequence of events
can be demonstrated by the method described by "ejs", up-thread. Use cm93, and import
the large GPX file referenced. Zoom into an area containing the imported tracks, and see the train-wreck.
So, maybe we have the root cause. I have prepared a version of OCPN v5 correcting for the spurious GL error report handling, while retaining full VBO support.
Here it is:
If using S63, the version should be tested with the existing Production S63 plugin.
If using oeSENC, it will probably not correct a similar crash on oeSENC plugin . That will come next.
Please report results here.
Thanks to all for your input and support