OpenCPN was very inefficient at rendering many things, basically emulating WxWidgets on top of OpenGL instead of a native call for lots of stuff still.

I went ahead and optimized most of the slow stuff, and greatly reduced idle cpu usage while increasing the frame rate. This helps reduce power consumption as well. OpenCPN is significantly faster on my netbook now. There are actually a lot of improvements in this fork, see the git log for details. It is really only the first pass at optimization though, many things are possible in the future. It is a rather large change (4000 lines added 3000 lines deleted) so it certain to break things in minor ways, which is why I need testers on many platforms.

I think Dave may be a bit busy, so it would be helpful to get other testers to correct issues with this fork to make it easier for him to merge.

I have no display for my raspberry Pi, I would love to hear about any testers on raspberry pi, but you would almost certainly need hardware accelerated opengl to reap much benefit. Of course all platforms need testing.

Sean I'll try it in a separate instance. Looks like it could be a real improvement. I was very impressed when I found out you did the OpenGL driver, which has made a big difference to many in speed.
It will be interesting to see how this is brought into the main program with all its changes, through git.

Optimizations for OpenCPN Implemented
optimize fbo caching by adding more overlay objects which are on the cached texture, which rarely update and move with the chart. optimize ownship drawing optimize chart bounding box logic use textures for waypoint rendering and eliminate a few glitches. remove glDrawPixels calls (these are very inefficient) improve speed of s52plib text rendering by using texture based fonts improve smooth zooming/panning/rotation integration and remove use of timers, and improve the use of keyboard input add keyboard control of viewport rotation to make setting configurations such as: south/up. route/up, wind/up possible. fix a few initial issues with rotation... rotated viewports are still not well tested in opencpn, more bugs are likely, but it seems to work well now allow hiding compass window eliminate events generated in the frame timer which consume extra cpu at little advantage. delay loading of disabled plugins to improve startup speed consolidate optimize and improve clipping regions eliminate builtin projection code in gshhs and use our projection to allow the world map, on any projection (eventually many projections possible), and also more efficiently support panning by using bounding boxes on the subregions of the world map. use std::string instead of wxString in nmea parsing to avoid slow character type conversions notify plugins of cursor lat/lon change when map pans These optimizations are mainly targeted at opengl, and slow processors. but in some cases, the changes should give noticable improvements in many cases.

Future plans are commented in glChartCanvas.cpp

TO DO listbugs:
vector chart display lists, build fonts for all text, with optional display list for strings, review patch

oversized fbo -- to allow quick panning, zooming and rotation without lag or delay because it only queues commands for worker thread(s) to upload the texture or to render to the fbo so there is no blocking or data manipulation in the render code, and high frame rate is guaranteed.

If the user zooms or rotates, the fbo _eventually_ must be updated to keep
the text level and avoid distortions, but in the mean time we can take the last fbo and simply rotate, scale and pan it as needed to extrapolate the desired view. In the background thread, the fbo is rendered to a viewpoint "most" likely where we will be when it is completed. eventually with alpha blending, we may combine two or more fbo views for better interpolated imagery.

If the user pans, the fbo may _never_ update as long as they don't stray too far, but if they do, then the update will have much wider rectangles and not occur very often. This is much more efficient than the current way which has skinny rects to update each frame.

If the user pans or zooms out too fast (overshooting edge of fbo) then we can render black or possibly some tessellation or message to make this obvious.
textures will "arrive" into place, and when they do, they can set a dirty rectangle in the fbo, and update it. In any case, this is unlikely unless there is extreme slowness loading the image.

The bounding box to test if we should upload a texture can also be expanded to give a similar effect with and without the fbo.

The textures are in a priority queue based on their distance from the center of
the screen and possibly scale factor difference from current. Can also factor
in rate of change of center of screen and scale factor as derivative terms
(so we prioritize texture loads off center, in the direction we are panning)
using past measurements of the time it takes to upload a texture cell.

longer term-
multi projection mode to allow better navigation especially for high latitudes
with polar and spherical projections
this also corrects the whole transverse mercator problem since we can
"remap" the chart into simple meractor, or any other projection which
corrects the image to make all the charts the same projection.

In immediate mode from a grid of points and texture coordinates.

Eventually glsl fragment shaders real-time raytrace raster charts as
needed to give any projection with per pixel accuracy (no polygons)
and also offloadthe trig for converting coordinates to and from mercator
the gpu which speeds up the software.

floating overlay objects to a framebuffer object so that they do not update very often with dirty rectangles for things like scale-bar, emboss, overlay images, compass, toolbar chart. selection window, status bar.. can all be rendered this etc..

This fbo can be blended in a single operation if it does not need to update that frame for more efficient rendering.

plugin routines to allow plugins to take advantage of the acceleration in the
fbo from grounded and floating overlay objects.

opencpn made to work with egl and opengles to allow running opencpn
without x11 and using the most efficient hardware acceleration for arm processors.

Wow! An ambitious undertaking, for which I am very grateful. There is no substitute for a tightly focused, fresh look at very old-fashioned code in light of newer hardware and software APIs.

I encourage all who can build from source to git and try this fork, report faults to Sean, and shape it up for a merge into the mainstream as soon as it is ready. Makes a good target for the next Release, planned for the spring.

I'm especially excited by the proposed rework of the fbo logic, for those systems that support fbo. Also opengles, for the future. OpenGL classic is getting pretty long in the tooth....