Visit our Popular Forums

ghega · 27-09-2015, 13:42

Good moorning
Guys i version 4.1.909.
but I do not find to download the new version 4.1.925
can someone give me the download ?
Thank and good wind

Hakan · 27-09-2015, 14:08

Dave...
cont. re:
I think the solution is as simple as this:
cm93.cpp:4946

I've now tested the same built also on W7 and there is a change. I can't force it to show non-detailed parts on the same location as before.

Another experience on W7 is that the arrow keys are less sensitive than usual. I have to keep the key pressed a while before recognition. Is this the performance loss you mentioned before?

Håkan

Hakan · 27-09-2015, 14:18

Dave...again
This a randomized game. Next time I started W7 the non detailed parts where there again. I shut off and restarted ---- everything there with all details ??????
Håkan

bdbcat · 27-09-2015, 16:25

Hakan...

I think you will find that O4 does roughly the same thing, depending on the startup scale, and the availability of detailed cells at the screen center point.

The random nature you observe relates to the Lon0 problem, and depends on where you have been before you arrive at your test location. This will get fixed.

The whole issue poses an interesting design question. We choose the cm93 scale level to show based upon the availability of cells at the screen center point. What should we do when a user pans into an area with larger scale, i.e. more detailed cells available?

It then becomes a question managing screen density and CPU cycle availability. Too much detail can be worse than too little.

We have tried some logic before to try to guess what the user is trying to see. This approach is not reliable. So the patch I gave you causes O to choose a reference Scale and stick to it as you pan. If a cell at the chosen Scale is not available, then the next smaller available scale will be used.

Take the specific case we look at here:

0. We start at a specific point, at the church tower in Joerlanda. By computation of screen size, scale and cm93 detail slider in Options, we determine that the best scale to use here is cm93 Scale E. 1:50,000

1. However, there is no E scale chart available for this point. So we fall back to Scale D 1:100,000.

2. However, there is a part of the screen (to the West) that is well covered by Scale E 1:50,000, i.e. more detail. So we show this piece at Scale E.

3. We pan west, bringing more and more of the Scale E region onto the screen. It comes onscreen at Scale E, since that is the Reference scale.

This logic was broken in 4.1.925. The new stuff was coming in at Scale D.

The initial computation of "best" scale is tricky. There will of course be "breaks" in the visible scales chosen, because we have only a certain set of scales available, and larger scale cells are generally smaller in area. No sense in having a large scale chart of the central Sahara desert.

What we do know is that fiddling with this algorithm to make it better in Scandinavia almost certainly breaks it in North America. And vice versa. So we want the simplest, most general algorithm we can devise.

And we still have the "Vestas" problem to consider. This is the case where we have small scale charts of an ocean, with isolated larger scale charts of islands. We would like is to signal the navigator: "There is a larger scale chart on your rhumbline, a few miles ahead. There might be an island there. Please take a look".

So you can see that the issue is not local, but highly global. Finding an optimum is non-trivial.

Anyway, I think the patch I gave you reverts to the equivalent to O4, when the other bugs in cm93 viewport math are resolved.

Thanks for listening.
Dave

rgleason · 27-09-2015, 18:00

Minor issue, but charts don't seem to get rendered as soon as expected when zooming in. With the Setting>Display>Advanced (Detail Zoom setting set to 0).

x1-Great Lakes 14500_1.kap no chart rendered
x5-Great Lakes-14500_1.kap no chart rendered
x6-Great Lakes-14500_1.kap chart rendered
x4-Great Lakes-14500_1.kap Zoom out by x4 chart is "un" rendered

It should render at x1 I think. From a previous post it appears that this chart renders in linux before the boundaries are consumed by zooming.

It is actually somewhat annoying.

bdbcat · 27-09-2015, 18:19

Rick...

Not sure I understand you. Testing compared to O4 shows the switch from no-render to render occurs at just about the same point. I checked at Great Lakes polyconic, and Boston Mercator. Win and linux.

What am I missing?

Dave

janp391 · 27-09-2015, 19:08

Quote:

Originally Posted by Hakan

JP, Dave...
For me it's very reproducible. It happens "all the time" also in the same place. I think it's a quilt problem. In my three views I'm moving the chart by the arrow keys, same zoom level.
As soon the left chart part leaves the screen details are there(pic2), moving back so the left part is again visible details are gone(pic3).

Håkan

I have the same problem on exactly the same spot (utanför Soa och Galten) Running W10
//Jan

rgleason · 28-09-2015, 03:44

Quote:

Not sure I understand you. Testing compared to O4 shows the switch from no-render to render occurs at just about the same point. I checked at Great Lakes polyconic, and Boston Mercator. Win and linux.

What am I missing?

Yes, windows v4 is probably like v4.1.925 with regard to when charts get rendered in Windows. I believe there is a difference in handling from linux, because there was a forum post with a screenshot attachment by a linux user (showing the improved projections from Sean) which showed the entire Great Lakes 14500_1.kap in one screen. -I can't seem to find it.

That is not what happens in Windows. There may be reasons for having the program behave as it does that I don't know about (efficiency, overloading cpu, etc).

What I would like to see is the Great Lakes Chart 14500_1.kap rendered when we can see the entire rendered chart. Also when it does not render at 0.1x, the user has to zoom down to 0.6x to get it to render and by then a considerable amount of the chart has disappeared. Then when rendered at 0.6x when I zoom back out the rendering is not stickly, so it disappears at 0.5x or 0.4x. rather than letting us see the entire chart.

I think this would be a general improvement rather than being specific to this chart.

rgleason · 28-09-2015, 03:48

I am finding the pan, scroll and zoom functions much smoother and faster in v4.1.925 I think the optimizations for Android have really helped everyone.

rgleason · 28-09-2015, 04:04

Cape Sable to Hatteras 13005_1.kap renders at 0.4x disappears when zooming out at 0.4x Is there some reason the full chart should not show at something like scale 6671600?

Also with regard to quilting.. is it expensive to determine if something is rendered? Sometimes there are holes in the quilt where nothing is rendered.

P_Dub · 28-09-2015, 07:09

Important....
zooming with a scale inferior to the scale of the ENC S57, say a chart 1/15000 to a scale 1/16000 or less automaticly change the chart to the next smaller scale chart. This must be a bug in the version 4.1.925.
What change do we have to do in the config, if so?
Thanks

P_Dub]

bdbcat · 28-09-2015, 07:16

P-Dub...

Can you give us a specific test case? What charts/location, etc.

Thanks
Dave

bdbcat · 28-09-2015, 07:31

Rick...

The post you want is here:

http://www.cruisersforum.com/forums/...0&d=1443233792

I'm not sure how this image was generated. Dirk?

There is no difference between linux and Win on rendering rules.

So it sounds like what you want is a Feature Request to change the small scale rendering rules. That seems OK, I'll look at it.

Meanwhile:
re:
"Also with regard to quilting.. is it expensive to determine if something is rendered? Sometimes there are holes in the quilt where nothing is rendered. "

Examples, please?

Thanks
Dave

bdbcat · 28-09-2015, 07:38

Testers...

Gentle reminder....

I don't see a lot of activity over on the Flyspray tracker. There are 12 issues/tasks marked as "Implemented in current Beta" which I would like to close.

If you have posted a task on Flyspray, please take a look and see if your task is satisfied, so we can close some of these open issues.

Thanks
Dave