Weather has had me pinned away from
internet. I went ahead and rowed the 2km in and got completely soaked! Anyway I believe I have fixed all of the problems reported as well as a lot more, and I am ready for the next round of testing.
I updated the version to distinguish these changes, but maybe I did it wrong?
The following is probably too much detail and involved for everyone, but if you are interested and would like to provide performance feedback, read on.
I added the ability for my statusbar
plugin (
http://github.com/seandepagnier/statusbar_pi) to display frame rate
(display string "%02.1f") With this, anyone can measure basic performance, please post your numbers.
It is well known that the status bar (and to a lesser degree
compass window) slow performance, and are incredibly inefficient for what they do. Both are disabled for my tests.
Vector and world background
charts greatly benefit from the use of the fbo optimization for panning (less so for diagonal panning) in north-up mode. If the viewport is rotated, this optimization is not used so panning will be slower (although much faster than without opengl still)
All measurements are taken using keypresses, not the mouse. Diagonal panning achieved by using two arrow keys at the same time.
Results:
eee pc 900a netbook (1.6ghz atom
single core) and Intel mobile 945GM (keep in mind vector charts are extra slow on intel because due to a driver bug we must use the slower
depth buffer instead of the stencil buffer)
opengl:
raster charts:
25-30 fps for panning zooming and rotating
single chart
15-20 fps for panning zooming and rotating quilted with 3 charts visible
vector chart in single chart mode: (see screenshot for scale used)
5-10 fps panning north-up
3-6 fps diagonal panning north-up
1-2 fps panning (rotated) or rotating
2-3 fps zooming
world background chart only (no charts visible) conveniently accessed by hiding the cm93 chart in quilt mode
zoomed out enough so
china size roughly fills
screen (zooming in gives faster frame rates)
5-10 fps panning (rotated) zooming rotating
30 fps panning north up
These are basically all worst case scenarios. Vector charts are often much faster at a different scale or view with less detail or items displayed. This is apparent as zooming is faster than panning, because it is traveling through scales which are faster to render during this test. I was careful to avoid needing to load data into video memory (zooming or panning very far) as this causes a "glitch" much slower frame rate while it loads data from disk and uploads to video memory.
I have a pretty good understanding of how the rendering process works, and I am fairly sure (with a lot of work) it is possible for every single test listed above to be 30 frames per second or in most cases much higher, as well as eliminate the "glitches" (when stuff has to be loaded) as it can be uploaded in a background thread in most cases just before it is needed. This applies to vector mode as well since rendering can be done in the background and the texture produced quickly extrapolated for the following 10-20 frames (while the next update is rendered in the background), same as
current fbo optimization, but for all possible cases, not just panning north-up. Vector charts can also greatly benefit from display lists, or vbos.. and if stored natively to disk in this format could make loading and rendering these charts extremely fast as well as reduce disk
storage space needed (once they get converted). I believe the speed of loading raster charts can be grealy improved by at least a factor of 10 by storing the compressed texture on disk and memory mapping it directly to where the graphic driver can upload. This means only 1/6th of the
current amount of data need be transfered, and there are no longer any intermediate copies performed (currently 2 or 3). therefore much less ram usage (same as now if
opencpn is running with no charts loaded). At the same time reducing the disk space needed to store the raster charts once converted. An additional optimization would use
hardware acceleration to produce the mipmaps (currently produced in a very slow routine which consumes a significant amount of total cycles used by opencpn) and/or store these on disk as compressed mipmaps don't take a lot of space.
If the above is ever implemented, I estimate very smooth graphics and completely useable operation on very slow machines like cell phones and raspherry pi. Faster machines will be able to have smooth graphics high resolution and the cpu will still be idle. This also opens the possibilites for more taxing graphics operations in the future.. ie: projection conversions. I have no idea if/when I can actually implement these things. Any ideas/comments?
Known bugs:
The tiles used for raster chart mode are clearly visible in overzoom. This is because we do not interpolate pixel values between two different tiles (textures). I think the best way to fix this is to overlap the tiles by 1 pixel to allow for this interpolation... is it worth bothering with?
Boundaries for
ENC text is calculated after it's rendered once. Unfortunately we don't know when to render it the first time so the "guess" of .25 degree box is usually badly incorrect. This results in sometimes text anomallies when panning with the fbo optimization, and text "poping" into view when zooming rather than it being part of the chart as would be expected. This is for both opengl and non.