OpenCPN: "Chart cache purge" in logs

[Strolls]

Originally Posted by boat_alexandra

Basically there are three possible options:

1) no compression -- maybe fastest for initial results, but uses by far the most memory
2) compression -- maybe slower initial results, uses little graphics memory (you must have expert mode enabled for this option)
3) compression with caching -- maybe even slower initial results, but uses the least memory, and gives good performance once the cache is built. It also uses about as much disk space as the normal chart file.

Just to be totally clear: these 3 options only apply when OpenGL is enabled, right?

I'm sorry for being so short yesterday, but I did spend several hours testing this.

Having spent a little time testing again today, I can confirm that on my compy raster charts are faster with OpenGL disabled than they are with OpenGL ticked but "Texture Compression with Caching" unticked (in the basic options).

To test OpenCPN and become familiar with it, I started by loading all the NOAA charts into it (RNC + ENC, about 7.5GB), some Dutch vector ones, and the New Zealand raster collection (which covers the whole of the Pacific).

With OpenGL disabled, I can zoom in and out perfectly smoothly, using raster charts all the way down to the 1:25,000 charts of the US west coast (e.g. Roche Harbor, NOAA chart 18433), out to the 1:10,000,000 chart (NOAA chart 50), then zoom back into the Hawaii islands (e.g 1:5000 NOAA 19341) and it is perfectly smooth.

Switching back and forth between the two settings has led to confusion sometimes - at least twice I have experienced spinning beachballs and thought "this isn't right, I thought the non-openGL performance was better than this", only to find that I had accidentally enabled OpenGL. It is indeed the OpenGL ("Texture Compression with Caching" unticked) that is slower.

I will enable the OpenGL advanced-advanced options and try to spend some time with it the next couple of days.

Initial impressions are that OpenGL + "Texture Compression with Caching" is not as fast as OpenGL disabled, on my system.

I tried to prerender by enabling OpenGL and starting OpenCPN with the -rebuild_gl_raster_cache flag, but the number of maps I have loaded (you probably think excessively many) make it a 17 hour job. I had to leave it running overnight, and 4.0.0 seems to keep crashing at a certain point (when the raster_texture_cache directory is about 10GB or 11GB in size (NB: that's about twice the size of the original .KAP files)). I have just installed 4.1.602 and am now heating my laptop up again.

Not sure what you mean by "DC-mode" - with OpenGL disabled? I guess if you're sceptical that non-GL rendering is adequate, then I'd understand that, but really it's perfectly fast and totally usable.

You mention course-up mode - I'm sitting at home on my laptop with North-up, but where the maps are skewed with north at a funny angle on the page, that doesn't take long to paint, at all. Get the Golden Gate Bridge in the middle of the screen, quilting off, and switch between charts 18652 and 18645. On my Mac the charts switch, rotated, just as fast as you click them. I think chart 18652 (big PDF) has the bridge at two scales at two different angles, so that's three angles OpenCPN is switching between instantly.

In fact that big PDF is overloads the Preview.app PDF viewer, and spinning beachballs make it unusable (maybe if I had more patience), whereas viewing the same area in OpenCPN (with OpenGL disabled) is fine.

Underzoomed - well, it's too fine to see detail, but I wouldn't call it "ugly".

I'm halfway tempted to do a screencast for you guys, so you can see I'm not bullshitting you about the Mac's non-GL performance, and to make sure we're not talking at any cross purposes.

HTH,

Stroller.

[nohal]

Stroller...
To understand what course-up mode is about, get the VDR plugin, download some dataset (http://www.navmonpc.com/Downloads/Pa...12%20Start.zip is a good one) and play it.
It is perfectly fine that you are happy with the non-opengl (=DC mode) performance of your Mac, at the end it is a very powerful machine both CPU and GPU wise. It is just very hard to understand why the performance could be better than with OpenGL enabled as it is technically "impossible"...

Pavel

[CarCode]

Stroller,

several reasons for your observations.
OpenCPN was done with the wxWidgets framework and this framework has actually about 380 bugs for its Mac OS X port, which is newer than the Linux and Windows port. Furthermore the OpenGL code of OpenCPN has seen a fabulous optimization last year done with a small Raspberry Pi to make it run on small machines. Since then I observed also the OpenGL code is somehow broken on Mac. However the code is too complicated for me to get it fixed.

Gerhard

[Strolls]

Originally Posted by nohal

It is just very hard to understand why the performance could be better than with OpenGL enabled as it is technically "impossible"...

I wondered if it might be the case that OS X is using the GPU for rendering DC mode, offloading it to Quartz.

That's only speculation, though - anything more would be above my grade.

My laptop is now 7 years old - I would think current models much more powerful!

[CarCode]

Originally Posted by Strolls

I wondered if it might be the case that OS X is using the GPU for rendering DC mode, offloading it to Quartz.

That's only speculation, though - anything more would be above my grade.

My laptop is now 7 years old - I would think current models much more powerful!

Your assumption goes in the right direction. The wxRegion class of wxWidgets for Mac OS X has been broken years ago because Quickdraw in OS X was abandoned in later OS X versions and so other Region routines was implemented in the OpenCPN code. You may have a look here:
All wxOSX bugs – wxWidgets
to see all the wxWidgets bugs for Mac OS X.

However for your Mac you don't need any compression or cache methods. The machine has enough power. I have some with same age and they show a max CPU usage of 4-5 percent with heavy loaded OpenCPN with charts.

Gerhard

[Strolls]

Originally Posted by CarCode

However for your Mac you don't need any compression or cache methods. The machine has enough power. I have some with same age and they show a max CPU usage of 4-5 percent with heavy loaded OpenCPN with charts.

That's in DC mode?

The performance of OpenGL + "Texture Compression with Caching" is substantially improved now the (17 hour) raster cache rebuild is complete.

OpenGL is now comparable with DC rendering - I was initially so impressed with its smoothness that I thought I was going to validate nohal's insistence that it's better, and I am seeing 150fps+ in the status bar, but on switching back to DC, I don't see any difference.

If boat_alexandra is still interested in the results I'll fire up advanced mode in the next couple of days.

[seandepagnier]

Originally Posted by Strolls

That's in DC mode?

The performance of OpenGL + "Texture Compression with Caching" is substantially improved now the (17 hour) raster cache rebuild is complete.

OpenGL is now comparable with DC rendering - I was initially so impressed with its smoothness that I thought I was going to validate nohal's insistence that it's better, and I am seeing 150fps+ in the status bar, but on switching back to DC, I don't see any difference.

If boat_alexandra is still interested in the results I'll fire up advanced mode in the next couple of days.

I think maybe you have 150fps with opengl, and something in dc (non-opengl) mode that is > 40 frames per second so you can notice a difference. Both are fast enough. Perhaps we should limit the frame rate to the refresh rate to reduce cpu and gpu usage and power consumption since you can't tell anyway.

By course up mode you can also try adding "EnableRotateKeys=1" to your opencpn.conf, then pressing '[' ']' and '\' and try panning with this.

I think the problem is how it handles dynamic cache building. Can you compare the difference with opengl and compression not enabled? We need to ensure this works at least as fast as dc mode. If so, then in the future, compression with caching can be made to work as fast.

I think from you screenshot you can see what I mean by image quality, it's clearly better with opengl. Finally, there are many features only available with opengl and many more in the future, so it's important to make it work.

[Strolls]

Originally Posted by boat_alexandra

I think maybe you have 150fps with opengl, and something in dc (non-opengl) mode that is > 40 frames per second so you can notice a difference.

That makes sense to me.

Originally Posted by boat_alexandra

Perhaps we should limit the frame rate to the refresh rate to reduce cpu and gpu usage and power consumption since you can't tell anyway.

Sounds sensible.

I have Activity Monitor pinned in my Dock, and in OpenGL mode the laptop gets hot while the CPU usage bars remain low. I assume it's the GPU getting hot, then.

Originally Posted by boat_alexandra

By course up mode you can also try adding "EnableRotateKeys=1" to your opencpn.conf, then pressing '[' ']' and '\' and try panning with this.

I think the problem is how it handles dynamic cache building. Can you compare the difference with opengl and compression not enabled?

Will have a go at these this weekend.

Originally Posted by boat_alexandra

I think from you screenshot you can see what I mean by image quality, it's clearly better with opengl.

You're aware that screenshot is in DC mode?

It looks fine to me, and the difference in underzoom between the two modes is not obvious to me. I might have to take screenshots of both so I can compare them side-by-side.

[CarCode]

Originally Posted by Strolls

I have Activity Monitor pinned in my Dock, and in OpenGL mode the laptop gets hot while the CPU usage bars remain low. I assume it's the GPU getting hot, then.

Get iStat or a similiar app to check your temperatures. Don't use any cache or the such with Mac OS X, they are useless and implemented for small machines like Raspberry Pi only. Sadly none of the developers has a Mac and so they often talk without any background.

Gerhard

[bcn]

Gerhard,

Dave has a Mac - not a recent one, so if this is interesting the question is just how to get such one to him.
Sean has none obviously...

[bdbcat]

Gerhard...

I am following this thread. I have a two 2007 Mac Minis. I spend about as much dev time on Mac as is justified by the market percentages, which means that it is not exactly central to my workflow, but certainly on the list.

I find it useful to test new stuff initially on older, slower machines. It brings performance issues to the front immediately. We can be fooled by quad core 16 GB desktop linux boxes. And for sure we don't want (or need) a gaming class graphics card for OCPN. Distorts our thinking....

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.

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.

3. After a close look, very very few of the wx3.0 bugs reported against Mac have anything to do with OCPN. We just don't use those classes that are buggy.

4 Further, understand that the GL wrapper in wx means that the OCPN GL code has very little to do with wx3 on any platform. That is one advantage of GL. It is quite portable.

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.

Thanks
Dave

[CarCode]

Originally Posted by bdbcat

3. After a close look, very very few of the wx3.0 bugs reported against Mac have anything to do with OCPN. We just don't use those classes that are buggy.

Please write the whole truth.
It is well known that wxWidgets is extremly buggy especially the Mac port. As far as I know version 4.0.0 of OpenCPN is the last stable version and I don't know a fix of the known bug until now for a stable version:
http://www.cruisersforum.com/forums/...ml#post1732649

In the last betas of OCPN is a bug in the wxSlider class which exists since 10 years:
http://www.cruisersforum.com/forums/...ml#post1850690

I published a patch which is not even included in latest wxWidgets trunk:
http://www.cruisersforum.com/forums/...ml#post1863344

These are only 2 examples.

Gerhard

[nohal]

Gerhard...
So from 300 serious bugs making OpenCPN totally unusable on OS X we are magically down to one minor visual annoyance (which still makes it totally unusable because you decided so) and one bug in OpenCPN fixed months ago? Com'on

Originally Posted by CarCode

Please write the whole truth.
It is well known that wxWidgets is extremly buggy especially the Mac port. As far as I know version 4.0.0 of OpenCPN is the last stable version and I don't know a fix of the known bug until now for a stable version:
http://www.cruisersforum.com/forums/...ml#post1732649
[/code]
This is fixed for months as you very well know. No, we are not going to make a new 4.0.x release because of it.
[code]
In the last betas of OCPN is a bug in the wxSlider class which exists since 10 years:
http://www.cruisersforum.com/forums/...ml#post1850690

I published a patch which is not even included in latest wxWidgets trunk:
http://www.cruisersforum.com/forums/...ml#post1863344

These are only 2 examples.

Gerhard

As we explained to you so many times already, by spreading FUD on the forum, you won't resolve anything, it is the amount of patches you submit (by means of pull requests on github), not the amount of times you tell us we are all totally incompetent noobs (You already did reveal this secret to us, so we are aware of it), which will make you a respected member of the community

Pavel

[CarCode]

Pavel,
some things are hard to understand for you.
Since January there is a stable release for Mac OS X for download which stops some keyboard chars from working. A fix is known and is working in the beta versions but people can't use it for the stable version. Why?
Gerhard

[nohal]

Gerhard...
Because we consider this particular bug not worth a new release? I don't know - tell me what I don't understand, please.

Pavel