OpenCPN: "Chart cache purge" in logs

[CarCode]

Yes, of course, a software which kills the keyboard is a feature and not a bug. Wonder what comes next.
Gerhard

[seandepagnier]

Originally Posted by bdbcat

To the point:
1. FWIW, to me, the underzoomed DC mode chart shown above is unacceptable if there is an alternative. I very much prefer the GL rendition of same.

This is a good reason why we should extend glshim to also wrap libGL so that we can choose hardware or software opengl acceleration. Then everyone can have the option to have the nicer image quality even with unusable graphics drivers.

2. Not quite sure why one needs to fully rebuild the GL cache, for every chart in the book. Disk space is cheap, however, so no foul, I suppose.

Ideally we would do it your way and rebuild on the fly as needed, but the current implementation has a few issues:

1) It should leave one core free for opencpn itself when rebuilding the cache in the background (not possible with a single core), or make the threads somehow lower priority so they cannot slow the main program.
2) It should push the data as fast as possible into an uncompressed texture without any mipmaps just to get something on the screen (image quality may be as dc-mode for underzoomed) and when the cache is ready swap it out seamlessly for the compressed version. There are a bunch of details I am omitting which are needed to ensure it is really fast and doesn't use much video memory in all possible cases.

Without the above two features, the slowdown and lag on initial caching is great, and we will continue to hear reports of dc-mode being faster than opengl mode.

5. Finally, I would like to see some instrumented tests of DC vs texture-cached GL mode on a modern, high performance Mac. It is certainly possible that the hardware on these machines is "unbalanced", so that the CPU and memory frame buffer channel is much, much faster than the attached graphics adapter configuration. Could certainly be true if Intel GPU is used.

Once the cache is fully built, it is not theoretically possible that gl mode is slower. If it is, then somewhere there is a bug (either in opencpn or the graphics drivers)

The only exception is maybe maybe with software opengl, it would decompress the compressed texture in software which could be slower. This case is very unlikely I don't know of any computers that would exhibit this because already the other improvements greatly outweigh the penalty to decompress the texture. I think only occurs with lots of ram but little cpu, so in this case it can just not use compressed textures to get at least the performance of dc-mode.