OpenCPN Beta test 4.1.1108 Release

[seandepagnier]

You have made a good point that LLRegion breaks USE_GL=NO.

I think we should simplify things by removing the current internal tesselator, then in the case of USE_GL=NO (or for GLES) we can build and link with our own static version of glu. This will ensure consistent results.

[Tupaia]

Originally Posted by Hakan

Win10 mystery ??
XP was no problem but when I should end the Win10-O it wont close but just stop "answering" after a while and I had to force it close. The log file is full of CM93 messages I never seen before, like:
Håkan

Hakan, see my post 3 in this thread.

OpenGL - ON
2. prevents OCPN from closing, screen is hatched but remains active. If you then go into tools and switch OPENGL off you can close normally.

Peter

[Hakan]

Originally Posted by Tupaia

Hakan, see my post 3 in this thread.

OpenGL - ON
2. prevents OCPN from closing, screen is hatched but remains active. If you then go into tools and switch OPENGL off you can close normally.

Peter

Peter.
I've read your post but I don't think this issue is connected. I always use OpenGl and has run this version every day. I use BR24radar_pi and a other plugins as well.
If I get some tips about the CM93 log entries I'll make some more Win10 tests.

Thanks
Håkan

[Littlechay]

Originally Posted by Tupaia

Hakan, see my post 3 in this thread.

OpenGL - ON
2. prevents OCPN from closing, screen is hatched but remains active. If you then go into tools and switch OPENGL off you can close normally.

Peter

I'm seeing this; OCPN not closing but with OPENGL off .. happening all the time with this build (downloaded from the OCPN site beta).

Windows 10 machines x3

Not sure if it's submitting crash reports or not... need logs?

Chris

[ve7mdl]

I had O lock up on me today when trying to debug a serial port. When I unchecked the "Show NMEA Debug Window" it just hang with the little circle with rotating dots inside.

Gear: 32-bit Ubuntu 14.04.3 with the latest updates. CPU is i5-4200U and Graphics is Intel Haswell Mobile x86/MMX/SSE2. I had a port enabled, but it was not connected to anything. The port was using a serial-USB adaptor.

The problem is reproducable.

Cheers, ....Erik.
m/v B.C. Girl.
Richmond, BC.

[seandepagnier]

Originally Posted by ve7mdl

I had O lock up on me today when trying to debug a serial port. When I unchecked the "Show NMEA Debug Window" it just hang with the little circle with rotating dots inside.

Gear: 32-bit Ubuntu 14.04.3 with the latest updates. CPU is i5-4200U and Graphics is Intel Haswell Mobile x86/MMX/SSE2. I had a port enabled, but it was not connected to anything. The port was using a serial-USB adaptor.

The problem is reproducable.

Cheers, ....Erik.
m/v B.C. Girl.
Richmond, BC.

Can you rebuild with cmake -DCMAKE_BUILD_TYPE=Debug ..
then run in gdb or ddd, and when it is stick, hit ctrl-c and type "bt" at the prompt to get a backtrace and post that.

[Hakan]

Today's git on Win10:
CM93 is still OK on my part of the globe apart from a little piece of the world map at a very specific scale. (The usual VDR )
But:
There's a constantly increasing use of memory. (I'm not saying this is introduced now)
Dedicated memory use increases at around 5 000 kB/minute, from ~200 000 at start to 582 320 after 1 h 15 min.
The increase scheme has the following reproducible pattern:
-At start and no activity: Usage is stable around 200 000 kB
-Start receiving NMEA data from UDP network: Usage increases by ~5 000 kB/min
-Stop receiving NMEA data: Usage still increases with ~5 000 kB/min

After 24 hours the memory use will be huge if it's continuing??

-No increased memory use for the 4.1.1108 instance replaying the VDR

Is there a explanation for this behavior? (Multiplexer??)

Håkan

[seandepagnier]

Originally Posted by Hakan

Today's git on Win10:
CM93 is still OK on my part of the globe apart from a little piece of the world map at a very specific scale. (The usual VDR )

Where is the problem at what specific scale?

But:
There's a constantly increasing use of memory. (I'm not saying this is introduced now)
Dedicated memory use increases at around 5 000 kB/minute, from ~200 000 at start to 582 320 after 1 h 15 min.

The increase scheme has the following reproducible pattern:
-At start and no activity: Usage is stable around 200 000 kB
-Start receiving NMEA data from UDP network: Usage increases by ~5 000 kB/min
-Stop receiving NMEA data: Usage still increases with ~5 000 kB/min

I don't usually use udp. Which plugins are enabled? Can you disable all the plugins? If this doesn't help, can you try older versions to try to determine when this problem begun?

After 24 hours the memory use will be huge if it's continuing??

-No increased memory use for the 4.1.1108 instance replaying the VDR

Is there a explanation for this behavior? (Multiplexer??)

Håkan

Maybe the udp multiplexer

[Hakan]

Sean..
Memory:
- Plugins on/off has no impact
- UDP multiplexer still suspected. I tried to disconnect the UDP receiver and instead connect an AIS feed via TCP - no increase of memory usage! Back to UDP - increased usage. I'm sorry not having the opportunity to test a normal serial input here but could visit my boat for a test if required.

My UDP set-up is as of attached shot.
I didn't traced back in O versions but have a feeling it's not new.

CM93:
The world map glimpse is very short and not easy to replicate. I'll see if I can force it to show up again. Stand by on this - not a big issue.

Håkan

[.Paul.]

Refer back to my post #118.

Originally Posted by .Paul.

I built O from the source Dave revised on 15 Nov, and I have run Hakan's VDR several times in this version.

It renders the quilted chart detail much better. Also, the small region south of St Dagholmen (an island) from 57 59.8N 11 46.8E and SE from this lat/lon now has spot soundings and depth contours. My previous build from 14 Nov only had blue (shallow water) there. All of the water areas appear to be correctly rendered.

A few place name text labels disappear once in a while when the chart canvas is redrawn. The next redraw brings the labels back.

The text labels blinking off and on is caused by having "De-Cluttered Text" checked under Options>Charts>Vector Chart Display. With the checkmark removed, there are many overlapping labels, but they don't switch off and on.

The C scale chart that fills the right side of my screen has the buff color of land with one symbol ... (BUIREL) ...

From time to time this region is displayed in gray ...

It stays gray for only a short time, then the buff land and BUIREL symbol return as the charts move under the red boat.

All in all, it is an improvement.

Thanks,
Paul

I built O from the source including yesterday (19 Nov 2015) morning's commit by bdbcat that merged Cm93 rendering fixes from Sean. I ran this build in Win10 with Hakan's VDR many times. I have not observed the gray region replacing the buff color of land in the C scale chart region. The rendering problem seems to be fixed.

Thanks,
Paul

[.Paul.]

The problem of a gray field replacing the C scale chart region while running Hakan's VDR just came back! My previous post was based on running a build from yesterday afternoon. That source included yesterday (19 Nov 2015) morning's commit by bdbcat that merged "Cm93 rendering fixes" from Sean.

I just pulled last night's changes including Dave's commit to "Implement mag variation calculation at object location if WMM is available". I built O. Now, when running with the VDR, the C scale chart on the right side of the screen switches from the buff land color to gray and back to buff.

Paul

[Hakan]

Sean..Dave..Paul..
Ref to my CM93 indication about the world map glimpse.
I still have trouble to shot it because it's short lived and resolve itself after a some seconds. But the appearance is as of my screenshot at non quilt mode. The world map area is C scale and the screen scale is around 26000(1.9x)
As said, not a big issue but for the record....Ans I didn't saw it using the git build Nov 18.

Håkan

[seandepagnier]

Originally Posted by .Paul.

The problem of a gray field replacing the C scale chart region while running Hakan's VDR just came back! My previous post was based on running a build from yesterday afternoon. That source included yesterday (19 Nov 2015) morning's commit by bdbcat that merged "Cm93 rendering fixes" from Sean.

I just pulled last night's changes including Dave's commit to "Implement mag variation calculation at object location if WMM is available". I built O. Now, when running with the VDR, the C scale chart on the right side of the screen switches from the buff land color to gray and back to buff.

Paul

Can you sync back to before the last change or so and try to find which change broke it for you?

[bdbcat]

Paul/Hakan...

Just for fun, will you make the following change and try to reproduce the quilt background anomalies reported?

bool cm93chart::IsPointInLoadedM_COVR ( double xc, double yc )
{
    //  Provisionally revert to older method pending investigation.
#if 0
    return m_region.Contains(yc, xc);
#else
      for ( unsigned int im=0 ; im < m_pcovr_array_loaded.GetCount() ; im++ )
      {
            if ( G_PtInPolygon_FL ( m_pcovr_array_loaded.Item ( im )->pvertices, m_pcovr_array_loaded.Item ( im )->m_nvertices, xc, yc ) )
                  return true;
      }
      return false;
#endif
}

Note the conditional change "if 0"...

Thanks
Dave

[Hakan]

Dave..
This old friend again

Ok, with #if = 0 it was easy to get the attached screenshot. With #if = 1 it's better.
Håkan