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
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.