OpenCPN Beta test 4.1.925 Release

[seandepagnier]

Originally Posted by bdbcat

Sean...

Hakan's reported problem is not related to Projections/Regions merge. It crept in between 4.1.409 and 4.1.602. I am bisecting now to discover the cause. I'll let you know the results.

The problem that JP(ptizef) reported is real, easily reproduced by my recipe. I am almost certain this is coming from new region logic around Lon0.

Dave

Ok, I will try to fix the lon0 issues. Is there a reason cm93 internally uses 0-360 longitudes where all the other enc use -180 to 180? I think it would be the easy way to fix this and future problems as well as simplify the code to just make cm93 use -180 to 180 unless I am overlooking something.

[Gilletarom]

Hello Dave,

Originally Posted by bdbcat

Gilletarom...
Its nice to see you back online.
Have you succeeded to load your new chart? ...

I just retturn to my home after 95 days at sea (St Malo to the Baltic).

I will kindly provide information about the version for Android but my tablet does not work well. The GPS does not work and now i can not install applications provided by google store. Pfuuuu.

Returning to the PC version. The chart, which was sent to me, was displayed correctly after restarting O 4.1.925.

Best regards.

[kubek]

Originally Posted by hoolie

I have the same problem with a disappearing tool bar on Windows10 64-bit Pro. The icon disappears after using one of the tool dialogs.

Hi,

I have the same problem with disappearing toolbar on Windows 7 64bit.
It is enough to switch OpenCPN to full screen (F11) and back again (F11) to normal to see this behavior.

Kubek

[Ptizef]

Dave

During my test I came back to 4.0 and I am sorry to say that, I found distinctly a regression in 4.1.925 in fluidity and speed when zooming and panning CM93.
tests on 10' low power device windows 8.1, same parameters

In the shot attached you can see a zone where the regression is very important.
Another remark is the difference in the light sectors rendering which was less aggressive in 4.0.

Jean Pierre

[bdbcat]

Sean, Hakan, etc...

After looking at this a bit, I see that Hakan's reported problem with cm93 detail loss is actually not new at all. At certain zoom levels, O4 does exactly the same thing.

It's a logic problem in the cm93 quilt compositor, exacerbated by accelerated panning where we bring small rectangles of arbitrary scale onto the canvas, and try to avoid a full canvas repaint when the new scale is mismatched. So, nothing to do with LLRegion logic, you will be relieved to hear.

And also, not the same thing as Ptizef's issue. Something else there.

I'll push a patch that tries to do this composition a little better without a serious performance hit after I figure it out.

Dave

[bdbcat]

Sean...

re:
" Is there a reason cm93 internally uses 0-360 longitudes where all the other enc use -180 to 180?"

Historical. This is how the coordinates come out of the database.
Also relates to the cell file names.

Could be changed to +-180, I suppose. Would allow us to get rid of some cm93 special case code, which is scattered everywhere. That would be good.

However, I fear the logic/math difficulties will just shift out to the mid-Pacific. They will still have to be resolved.

Dave

[bobofthenorth]

When I install the new beta and try to open it with the BSB4 plugin in the plugin directory I get a message saying that the plugin is not compatible with this version of OpenCPN.

[bdbcat]

@Ptizef...

jp, re:

"I found distinctly a regression in 4.1.925 in fluidity and speed "

I agree completely. I see the same.

After some study, I see that the problems with chart detail, viewport location, and performance are all linked. We are not doing accelerated panning very well on cm93 at this moment. We are needlessly re-rendering all sectored lights, and some other features, on small pan operations. This would seriously affect user perception on panning, less so on zooming.

@Sean
The issue is building the correct small viewport for accelerated panning, so that we can do object inclusion filtering on the VPBBox. This relates to what you are looking at for Lon0, so I will leave this alone for now so we don't collide. Please keep in mind that we need the BBox and the center lat/lon to be coherent, or the filtering does not work right.

Thanks for the heads up.

Dave

[LeaseOnLife]

Originally Posted by bdbcat

@Ptizef...

....

After some study, I see that the problems with chart detail, viewport location, and performance are all linked. We are not doing accelerated panning very well on cm93 at this moment. We are needlessly re-rendering all sectored lights, and some other features, on small pan operations. This would seriously affect user perception on panning, less so on zooming.

@Sean
The issue is building the correct small viewport for accelerated panning, so that we can do object inclusion filtering on the VPBBox. This relates to what you are looking at for Lon0, so I will leave this alone for now so we don't collide. Please keep in mind that we need the BBox and the center lat/lon to be coherent, or the filtering does not work right.

Thanks for the heads up.

Dave

Can we add S57 rendering to above?

I haven't used US S57 much, but now I am following friends going from Chicago to Mobile. I downloaded the S57 USACE inland charts in it's own directory, created a group for just these charts. I have the hardest time to have any chart detail shown. Zooming in on any section randomly starts calculating and rendering some sections and not others. Previously rendered details often disappear when zooming in further or when panning.

Attached pics show

1. outline of all the USACE IENC charts
2. zooming in on Kentucky Lake ~ 36 53N 088 11W, overzoom
3. zooming in further, still overzoom
4. zooming in further, yeah, some detail, no overzoom
5. zooming in further, lost any detail, no oversoom

"Chart quilting" option seems to have little effect on above, as does opengl on/off. Option "disable full screen quilting" is unchecked, all chart weighing options for quilting are at highest (+5).


For charts of similar scale, as in this use case, a satisfying user experience could be:

Render the most centered chart and any directly connected chart of similar scale. Keep rendered charts when zooming in. When moving, keep rendered charts rendered and apply logic above for newly visible charts.



I can't wrap my head around how to do this for charts of differing scale and coverage.... Sean will fix it


Dirk

[bdbcat]

Dirk...

Although I agree that we don't do a great job of quilting the large scale iENC charts, rendering of these s57 cells is a completely different technical issue.

You may find that panning the cursor until the center screen is actually on a chart will allow zoomin to see full detail. We have an idea to improve this chart display by combining similar scale cells into a single (huge) meta-chart for faster and smoother rendering. Just not done yet....

Thanks
Dave

[rgleason]

Is it supposed to be [ahead 435]?

C:\..\GitHub\OpenCPN>git branch -va
android 7ed3cbd 4.1.915
* master cc57a1f [ahead 435] 4.1.925
remotes/OpenCPN/android 7ed3cbd 4.1.915

[Hakan]

Originally Posted by bdbcat

Sean, Hakan, etc...

After looking at this a bit, I see that Hakan's reported problem with cm93 detail loss is actually not new at all. At certain zoom levels, O4 does exactly the same thing.

It's a logic problem in the cm93 quilt compositor, exacerbated by accelerated panning where we bring small rectangles of arbitrary scale onto the canvas, and try to avoid a full canvas repaint when the new scale is mismatched. So, nothing to do with LLRegion logic, you will be relieved to hear.

And also, not the same thing as Ptizef's issue. Something else there.

I'll push a patch that tries to do this composition a little better without a serious performance hit after I figure it out.

Dave

Dave..
Ok, thanks but although old I do claim it's worse in this version than ever before. I'll of course patiently await a fix to test.

I can also confirm JP's report in http://www.cruisersforum.com/forums/...ml#post1923255, that the own track is drawn not directly after the boat but either a scale dependent distance or time behind. (And it's not the same track issue as some versions ago.)
I can see it on W7 but not WinXP!. (The W7 has the Intel 965 graphic chipset, if relevant for this?)

Håkan

[bdbcat]

Håka....

I think the solution is as simple as this:

cm93.cpp:4946

      //        Check for overzoom at the theoretically calcuolated chart scale
      //        If overzoomed possible, switch to larger scale chart if available
      double zoom_factor = scale_breaks[7 - cmscale_calc] / vpt.chart_scale ;
      if( zoom_factor > 4.0) {
          if( cmscale_calc < 7 )
              cmscale_calc ++;
      }

Note two lines un-commented...

For me, this reverts behaviour to the same as O4, at least for viewports that do not cross Lon0.

I would appreciate your test reports before I commit this.

Thanks
Dave

[Hakan]

Dave..
Sorry not a big difference after that change. See screen shot.
Håkan

[rgleason]

Is it supposed to be [ahead 435]?

After trying different git commands, tried using gitHub to sync v4.1.925 cc57a1f D.Register and it seemed to compile with 86 warnings, no failures. Then found and downloaded the one on the downloads page instead.

Second time there were no warnings, but to run cpack I need to download the libcurl file again.