OpenCPN Beta test 4.1.1108 Release

[Hakan]

Rick
-To disable the slider creation is very simple, comment out two rows, and can be done if it's only that.
-Let,s see if someone find the CPA oddity and if that's an obstacle for the scaling algorithm.
-Personally I think scaled targets are way to small, See pict, and I didn't found a method to control it. ("targetscale", now 50%, has no impact??)

Håkan

[P_Dub]

Originally Posted by rgleason

PDub - I have Chart Groups = All Charts, Empty, Enc, Rnc, CG01Enc, CG01Rnc, etc but no Windows. Try just deleting it.

All done, Waiting for next beta. Thanks for help.
Bye

[rgleason]

Håkan: "scaled targets are way to small" - agreed. I think the temporary sliders are a great idea as they are enabling us to understand what is happening. Thanks for disable suggestion. Yes, one step at a time... looking more like it goes into the next beta to me.

[rgleason]

I do not know if all OpenGL & Chart Display improvements are made, but I would like to compliment everyone who worked on it from major optimizations, debugging, chart display improvements, fixing unnecessary cpu cycles, finding memory leaks, optimizing more code, plugging more cpu cycles, etc. I followed much of the discussion on github and here, and am impressed how you guys do this and work together, helping with specialized knowledge. Yes, there was some pain, and people were concerned, including me, but after using OpenGL with texture cache yesterday and today, I am finding it quite efficient and smooth.

I am not sure I understand did-g comments about the piano buttons, but have confidence that that will be improved in some ways too.

I know it was all hard dedicated work, so

THANKYOU!

[rgleason]

What is the current Plugin version number?
Why (0.??) in version.h now?
Trying to keep up.

[rgleason]

Also, since compiling plugins for 4.0, required a wholesale change in API for all plugins to PI 113, because of the change to widgets 3.0, can we just compile 4.1.x (4.2) with the newest API, assuming users will be using 4.2 rather than 4.0? Or is v4.0 going to still be an option? .. Now, I realize 4.0 may stay an option, but I just want to ask.

Also what is the number of the lasterst PI API ?

[P_Dub]

When do you expect the next beta or stable release?
Best Regards.

Note:- Happy Holiday (coming soon) to every one.

[did-g]

Dave

Originally Posted by bdbcat

@did-g...

Re:
1) Chart downloader xml parser

Have you identified a particular method in the downloader PlugIn that seems slow?

Thanks
Dave

Not really. Most of the time is in TiXML::loadFile called by SetSource() but I have the US all ENC in the list, that's a big xml file.

In my understanding there's not need for calling SetSource after SelectCatalog, it's done indirectly as a list event, cf PR.

What can be done (for testing I will make another PR) is:
- load the list but don't select a catalog on init, it's slow, moreover it kills two birds with one stone: Jean-Pierre problem is triggered by the wxYield call in SetSource.

- freeze/thaw charts list when updating, it may help a little with Gtk, it's awfully slow.
On the other hands it could be cargo cult, the AIS list is fine even with a lot of rows, I don't know how much of Gtk wx is using.

- cheat. In the US catalog, which is the biggest, there's a lot of attributes decoded but not used later, not decoding them speed up a little.

After all my wxExecute problem is not related to this code it's called earlier.

i still don't know why sometime I've an empty charts groups panel.

Last but not least while testing I've downloaded the ENC South China, here the rendering is slow, 100% in libtess KillFace for minutes.

[bdbcat]

Hakan...

re:
CPA calculation is sometimes not taking the option "No CPA calculation if target range is greater then...." in consideration.

Perhaps we should rename this Setting selection.
CPA and TCPA are calculated for all targets, whatever the range. However, there will be no warnings nor alerts issued if the range is greater than the value selected.

e.g:

                //    Skip distant targets if requested
                if( g_bCPAMax ) {
                    if( td->Range_NM > g_CPAMax_NM ) {
                        td->n_alert_state = AIS_NO_ALERT;
                        continue;
                    }

This is old code. The original thought was that CPA calculation would be expensive, and serve no purpose if the target is far away. It may seem to be redundant now, with the other Options settings available.

On the other hand, in real life with say 40 mile AIS range, it is easy to get a CPA alert on a distant target, depending on relative courses and speeds. But the alert is largely meaningless, since interaction with any target ca. 40 miles away will be many minutes (hours?) in the future, and so give plenty of time to react.

So, on the whole, I think we need the setting. Just maybe a new descriptive title that tells exactly what the logic does.

How about:
"No (T)CPA Alerts if target range is greater than..."

Dave

[seandepagnier]

Originally Posted by did-g

Dave
Last but not least while testing I've downloaded the ENC South China, here the rendering is slow, 100% in libtess KillFace for minutes.

I think these are charts which use boundaries with thousands of segments. This makes the region logic incredibly expensive. Switching to libtess2 might make it take seconds not minutes but still not acceptable.

Now maybe the thing to do for this case is somehow quickly clip the region to the viewport.. but then the regions calculations can't be cached and reused (possible future optimization) but we could flag these cases.

Another option is to maybe simplify the boundaries as we don't need 20,000 line segments to define the region of the chart... At least I don't think so. This could result in areas without charts or areas getting covered by less detailed charts.

I think you might notice version 4.0 doesn't have this problem, at least not as bad. So my starting point is single stepping both versions and trying to work out some sort of solution.

Let me know if you find anything otherwise I must look at this before a stable release.

What do you use for profiling?

Sean

[did-g]

Originally Posted by boat_alexandra

What do you use for profiling?

Sean

perf top
perf record
and valgrind callgrind tool

For uncached raster:
- I'm trying to set the busy spinner if the cache file is empty assuming it's going to be slow enough for the user to notice but it will work better if there's few caches mostly empty:

- do you thing it's possible to push new textures jobs when rendering? ie if the user doesn't change the view point after a while the background queue is emptied, the cpu is idle and often the display is not great there's fully compressed textures and low resolution ones. In PrepareTexture we know if a texture is low resolution and it should be possible to requeue them. It'd make building the cache faster too.

- the texture cache management is doing a lot of loops for nothing, for example in glTexture timer, if there's no jobs pending there's nothing new to save but it will loop over all textures again and again, it's the same if the texture cache memory limit is reached.

[seandepagnier]

Originally Posted by did-g

perf top
perf record
and valgrind callgrind tool

For uncached raster:
- I'm trying to set the busy spinner if the cache file is empty assuming it's going to be slow enough for the user to notice but it will work better if there's few caches mostly empty:

- do you thing it's possible to push new textures jobs when rendering? ie if the user doesn't change the view point after a while the background queue is emptied, the cpu is idle and often the display is not great there's fully compressed textures and low resolution ones. In PrepareTexture we know if a texture is low resolution and it should be possible to requeue them. It'd make building the cache faster too.

Do you mean for offscreen textures? So to build up the cache even for textures not yet viewed?

Currently it is supposed to push the texture as fast as possible uncompressed without mipmaps. Then the background threads generated compressed for all the mipmaps, and when ready the texture should be replaced with the compressed version to free video memory.

- the texture cache management is doing a lot of loops for nothing, for example in glTexture timer, if there's no jobs pending there's nothing new to save but it will loop over all textures again and again, it's the same if the texture cache memory limit is reached.

Yes, maybe, but I don't think it matters. Eventually we should use a priority queue that only fires the timer again if the queue isn't empty. Then when zooming, or panning, we can prioritize textures not yet visible but that are going to be needed.

[Hakan]

Dave
re: How about:
"No (T)CPA Alerts if target range is greater than..."
OK - Thanks for your check. Since all targets are treated in the same way this is then not a trace for the AIS scaling miscalculations. And yesterday Dirk mentioned a possible cause he will check today.

Your suggested text change is very good and obviously more relevant.

Thanks
Håkan

[rgleason]

Dave Is there a reason the program continues to use cpu to scan cpa for all targets no matter what range? I would think Sean and raspberry pi users would be interested in a setting "Turn off (T)CPA scans on targets greater than (variable) 20 nm"?

[rgleason]

Dave I think the longer range alerts are useful for Ocean. For Coastal a different shorter range setting is of greater utility.