OpenCPN Beta test 4.1.1108 Release

[bdbcat]

TDan...

re:
Maybe you or someone else knowing how chcanv.cpp works could check out this patch:

OK, does the job fine. Corner case not well tested, I guess. Code style a little off.

Better:

            if( ( pRouteDraw == active_route ) || ( pRouteDraw == active_track ) ){
                node = node->GetNext();
                continue;
            }

Thanks
Dave

[did-g]

Originally Posted by NahanniV

Thanks, for that explanation. My sleep deprived brain is not always working properly when using OpenCPN at night.

So, is doing the compression 4 times a reasonable solution to this ?

Is RGB necessary ?

There was a suggestion (with pull request?) to have an indicator on screen when any of the modifiers, like "S"oundings, "C"olour, etc..., were active. It seems like a good idea, but unfortunately it did not get included.

Cheers,
JM.

Yes if you're actually using DUSK and NIGHT schemes you can compress textures, select DUSK then option, rebuild cache, and so on, it works, of course your cache will be bigger.

[seandepagnier]

it would be nice to somehow use a fragment shader to apply color schemes. This would avoid the enlarged cache, it would allow for infinite customizable schemes (so alternate schemes for day etc...)

[Hakan]

Dave.. Test result below.
Sum: AIS ON/OFF seems to be the "rascal".

Originally Posted by bdbcat

Hakan...

OK, lets focus in here on the leak. I want to narrow this down to a specific feature/function that induces the problem.

Questions:
1. Is it obvious in a few minutes that the memory is growing, or do you have to wait some hours to detect it?

It's really obvious. Once the VDR file starts to play from the other O instance the the memory start to grow say 200 kB every second.

2. Do you have a custom ownship icon?

No, the inbound real scale vector type. I changed to default and no difference in M building up.

Lets narrow down to a specific test set, so we can get repeatability.

Try this configuration, please.
Test 1:
a. VDR recording playback, Sweden.
b. cm93 only
c. AIS OFF (toolbar button grey'ed out)
d. Not auto following, but ownship on-screen somewhere, and moving.

- No memory build-up. Just normal memory use and release on scale changes etc.
- Add Auto follow: No memory built-up.
- Add AIS ON. - Direct memory build-up as earlier. AIS=OFF stops memory build-up but don't release erlier built-up.
Auto follow = OFF or ON, the same result.
And, the results using raster charts are the same.

Next test:
Test 2:
a. Remove all charts, or set up an empty group. No charts shown at all except world background.
b. Auto-follow ON.
c. Same VDR playback.
d. AIS OFF
e. Large scale, so that the chart moves fairly quickly.

- No memory build-up.
- Auto-follow ON, > No memory build-up.
- AIS ON, > memory build-up at the same rate as before.
- Changed to a not empty chart group and no difference in memory build-up rate.

Thanks for the good test instructions. Are the results narrow enough or do you need more? Please advice.

Håkan

[bdbcat]

Hakan...

I think we are narrowing down to AIS.

Funny, I think I am seeing the same thing here, although on a linux system.
Lets try to absolutely confirm this.

Please run a test with full cm93, autofollow on, VDR playback, and AIS disabled. Then again with AIS enabled, no other change at all.

I'll do the same.

Thanks
Dave

[Hakan]

Dave
I got the same result again:
"Add AIS ON. - Direct memory build-up as earlier. AIS=OFF stops memory build-up but don't release earlier built-up."

Just to stress is more I used full screen and small screen, auto follow and look ahead mode.
AIS=ON Memory build-up, AIS=OFF no memory build-up.

But: If I, with AIS=ON, switch to scale like 50 000 000 the memory build-up stops and returns at less then ~500 000.

Håkan

[rgleason]

Yeah! You guys figured out the source of the leak! I was going to say I have a opencpn_4.1.718_setup.exe if that will help. It is uploaded to main directory of Opencpn Beta File Thingie rguser rgpass


but isn't this strange to occur?

"But: If I, with AIS=ON, switch to scale like 50 000 000 the memory build-up stops and returns at less then ~500 000. "

[rgleason]

After a short test with hakefjord.txt I can confirm that when the
AIS Icon is ON and AIS is displaying in the screen (with alerts off) Memory is used up.
AIS Icon is off Memory is not used up.
AIS Icon is off, Alerts are on, Memory is not used up.

[bdbcat]

Hakan/Rick, etc...

Memory leak:

Resolved. Issue was OpenGL texture leak (failure to delete) related to texture-based rendering of AIS target names.

If the target names are not displayed, there is no leak. If target names are displayed, it leaks about 1 texture per second, about 150KB, depending on the font used.

Hard to say exactly when this bug was introduced. Long time, anyway...

Fixed in github now.

Thanks for all your extra effort to help isolate and zap this one.
Dave

[Hakan]

Dave
And thank you for listening and your knowledge to find the cause.
"The simple is the hard to find" (- or something like that)
Håkan

[rgleason]

Thankyou bdcat and hakan for finding it! A very good one to swat.

[cagney]

Originally Posted by bdbcat

Hakan/Rick, etc...

Memory leak:

Resolved. Issue was OpenGL texture leak (failure to delete) related to texture-based rendering of AIS target names.

If the target names are not displayed, there is no leak. If target names are displayed, it leaks about 1 texture per second, about 150KB, depending on the font used.

Hard to say exactly when this bug was introduced. Long time, anyway...

Fixed in github now.

Thanks for all your extra effort to help isolate and zap this one.
Dave

Dave & All

Great catch. I have used v 4.0 for some time now. (We just arrived in the B.V.I.) In the AIS "Zoo" called the North Sea & English Channel, with constantly new targets appearing I had crashes about every 2-3 days. Across the Atlantic, with very few targets, no crash at all after 3-4 weeks.
Now I know why! I'm just in the process of changing to the beta series. Hopefully I'll be able to contribute to the testing, depending on wifi connections etc.

Cheers
/Thomas

[bdbcat]

Thomas!

A voice returns from the great blue sea.

Congratulations. I hope you had a good passage, and all well aboard. Looking forward to your Beta test contributions.

Dave

[rgleason]

Win7 v4.1.1108 getting back to charts.
I had to delete the Opengl Texture cache because of recent compile.
Opengl with texture caching.
With quilting on and unchecked No full quiliting on the advanced tab.

ENC and CM93 seem to work acceptably fast, even as the texture cache gets filed and SENC files are being made. CM93 appears to be seamless when zooming with hardly a pause.

RNC iappears a problem. It appears to be slow to respond when zooming in or out and sometimes hangs. Sometimes it just sits there with the wheel spinning. More about this tomorrow after some more testing.

[seandepagnier]

Rick,

I just want to confirm that this is because it is building the cache in the background. If you rebuild the texture cache is it acceptably fast?

Sean