OpenCPN Beta test 4.1.1108 Release

[Hakan]

And BTW, isn't it the same for src/opencpn.rc_
Håkan

[transmitterdan]

Sort of. OpenCPN.rc is created during the cmake configure process. But it should get overwritten by each new config process unlike version.h which is being handled differently now. So I don't think there is any need to worry about OpenCPN.rc. Cmake will take care of it.

[Hakan]

Dan
Thanks, but I'm not worried at all, just lazy. Even though added to gitignore I've to handle it after each major build since I added it first after first occurrence.
Håkan

[bdbcat]

Gilletarom...

I have a comment in my notes which I would like to understand better.

"2. Gilletarom: Windows tablet, soundings too small to read..."

I guess this is with cm93 charts.

Have you tried the Settings->UserInterface->"Enable Tablet Scaled Graphics interface", and move the slider up? Does this work for you? Is there still any problem here?

Thanks
Dave

[rgleason]

Test of Hakefjord.txt with most recent Opencpn

* master cb77247 Improve DUSK/NIGHT color presentation by eliminating bright decorations.
4:44 pm 5:15 pm
Hard Fault 0 0
Commit 244,860 169,972
Working 141,988 143,356
Shared 23,536 23,536
Private 118,452 119,820
-------
Memory 3.2gb 3.65 gb

[Hakan]

Dave..
Todays git fetch including "Improve DUSK/NIGHT color.............."
Windows, built VS13, OpenGL=on.
The dusk mode for vector charts is nice, left shot, but for raster are the "decorations" good but not the chart itself, right shot.

Håkan

[bdbcat]

Hakan...

The Raster chart you show does not have alternate dusk/night palettes embedded, so shows only the default daylight palette.

For these types of charts, the display dimming method, (F6) may be best.

Theoretically, it may be possible to create dim palettes for this type of chart if using OpenGL. Perhaps a Feature Request is in order to capture the idea, anyway. Not sure when we could get it implemented, though.

Any more observations on "your" leak?

Thanks
Dave

[Hakan]

Dave
Dusk/dimming - Ok, silly, should have known.

Leaks - No, no real news, still the same increasing memory usage.
I'm not sure what you mean but if you're talking about building 4.1.409 it's still the same errors.
Anything I can do?

Thanks
Håkan

[Gilletarom]

Dave,

Originally Posted by bdbcat

Gilletarom...
"2. Gilletarom: Windows tablet, soundings too small to read..." with cm93 charts.

Settings->UserInterface->"Enable Tablet Scaled Graphics interface", and move the slider up? Does this work for you? Is there still any problem here?

Dave

Regarding this comment, I forgot that some charts as charts S57 Netherlands, or in certain areas of the charts CM93 or S63, there was a very high density of display depths. Therefore, the ability to adjust the font size is useful.

I correct my remarks:
On my Lenovo U41, 8.1 W:
With O 41108, position 0 is too small. But the 5-position, it is almost too big. In any case, it depends on the view of the user. one who has great eyes will simply position 1 or 2, otherwise, it will be necessary 3, 4 or even 5.
On My ASUS EeePC, Linux Ubuntu 14:
The caratères even 0 position are larger than the Lenovo. So it depends on the brand of PC, and probably of the operating system.
On ASUS, in position 5, the characters are great, too, no doubt.

I added an idea:
To change, at sea, the size of the characters used, both for terminal display texts that depths should be easy access to the cursor.
But now, this slider is difficult to access. We must open the "Options" then "Personalization" and then scroll down the window with the elevator, and then move the cursor and confirm to close the window ... It's long. And to return to previous size, you must start all over. This is a process that takes too much effort.
The cursor should be accessible more easily. Can be put in the toolbar with a specific icon to open it, to implement a new setting and without having to confirm.

I take that answer and ask you, even if it is another topic, if you have seen this thread:
http://www.cruisersforum.com/forums/...ts-156977.html

[transmitterdan]

Dave,

I am unsure if this is a bug or not but I have a new machine that I am running O on for the first time. I have a UDP stream running but since this is a clean install there are no tracks or routes yet. As soon as I click the "Enable Tracking" button O freezes. It is not a crash but rather an infinite loop in chcanv.cpp function:

void ChartCanvas::DrawAllRoutesInBBox( ocpnDC& dc, LLBBox& BltBBox, const wxRegion& clipregion )

The infinite loop is here:

    while( node ) {
        bool b_run = false;
        bool b_drawn = false;
        Route *pRouteDraw = node->GetData();
        if( pRouteDraw ) {
            if( pRouteDraw->IsTrack() ) {
                Track *trk = (Track *) pRouteDraw;
                if( trk->IsRunning() ) {
                    b_run = true;
                    active_track = pRouteDraw;
                }

                if( pRouteDraw->IsActive() || pRouteDraw->IsSelected() ) active_route = pRouteDraw;

            }

            if( ( pRouteDraw == active_route ) || ( pRouteDraw == active_track ) )
                continue;

The last statement is always true but the node pointer has not been updated so it runs the same code over and over with the same node pointer. Essentially it is stuck in an infinite loop. I'm not sure what was intended for this case.

The file navobj.xml contains in its entirety the following:

<?xml version="1.0"?>
<gpx version="1.1" creator="OpenCPN" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.topografix.com/GPX/1/1" xmlns:gpxx="http://www.garmin.com/xmlschemas/GpxExtensions/v3" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd" xmlns:opencpn="http://www.opencpn.org">
  <trk>
    <extensions>
      <opencpn:guid>25850000-8753-4a7d-ad9a-2cdc1efb0000</opencpn:guid>
      <opencpn:viz>1</opencpn:viz>
    </extensions>
    <trkseg>
      <trkpt lat="57.992333333" lon="11.747183333">
        <time>2015-11-29T00:41:26Z</time>
      </trkpt>
    </trkseg>
  </trk>
</gpx>

I think this infinite loop has something to do with the fact that the track has only one point. It won't ever get another because of the infinite loop though.

[transmitterdan]

Dave,

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

https://github.com/transmitterdan/Op...d612a4c42f21e1

It prevents the infinite loop and doesn't seem to have any bad side effects. But I am not very familiar with how this bounding box code is designed.

[did-g]

Originally Posted by bdbcat

Hakan...

The Raster chart you show does not have alternate dusk/night palettes embedded, so shows only the default daylight palette.

For these types of charts, the display dimming method, (F6) may be best.

Theoretically, it may be possible to create dim palettes for this type of chart if using OpenGL. Perhaps a Feature Request is in order to capture the idea, anyway. Not sure when we could get it implemented, though.

Dave

There's another small issue with raster charts.

OCPN by default uses DAY and the cache texture in Options only build textures for the current color scheme.

The 'C' key rotates DAY , DUSK, NIGHT, RGB, DAY,... but the difference between DAY and RGB is not obvious.

it's very easy to think you're back to DAY when you are in fact using RGB colors and suddenly OCPN is slow, it's computing RGB cache in the background.

[did-g]

Håkan

Originally Posted by Hakan

Dave
Dusk/dimming - Ok, silly, should have known.

Leaks - No, no real news, still the same increasing memory usage.
I'm not sure what you mean but if you're talking about building 4.1.409 it's still the same errors.
Anything I can do?

Thanks
Håkan

If you haven't already done it could you try with the latest git:
- north up
- no track
- no follow (F2)
and with ownship and AIS targets not visible on screen.

[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?

2. Do you have a custom ownship icon?

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.

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.

Thanks, and good luck.
Dave

[NahanniV]

Originally Posted by did-g

There's another small issue with raster charts.

OCPN by default uses DAY and the cache texture in Options only build textures for the current color scheme.

The 'C' key rotates DAY , DUSK, NIGHT, RGB, DAY,... but the difference between DAY and RGB is not obvious.

it's very easy to think you're back to DAY when you are in fact using RGB colors and suddenly OCPN is slow, it's computing RGB cache in the background.

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.