OpenCPN Beta Version 3.3.1731 Released

[Gilletarom]

Hello Boat_alexandra,

Originally Posted by boat_alexandra

Are you sure you aren't just tapping the button? Try in touchscreen mode. Otherwise, it zooms while the mouse button is down for better control.

Otherwise.. we need to slow the mouse wheel down as suggested by pitzef, and it fixes problems or?

I have a "normal" screen. Not a touchscreen". so I canot use this kind of mode.

So, I use the touchpad of my PC.

But on reflection, my problem may be the same as Ptizef. It has two levels of zoom. My first level may be so small that nothing seems to happen. ....??

[seandepagnier]

To anyone who finds building the compressed cache slow: I found compiling opencpn without optimizations (default and probably the distributed beta) is very slow.. takes me an hour to build a cache that takes 5 minutes if compiled with optimizations.

[seandepagnier]

Originally Posted by Gilletarom

Hello Boat_alexandra,



I have a "normal" screen. Not a touchscreen". so I canot use this kind of mode.

So, I use the touchpad of my PC.

But on reflection, my problem may be the same as Ptizef. It has two levels of zoom. My first level may be so small that nothing seems to happen. ....??

I only asked as a test to help determine the problem. I believe all the issues with zooming can be solved by tweaking a few things. I agree with pitzef to slow the wheel by half, but as for other changes, I don't know.

[RhythmDoctor]

On my Windows 7 desktop computer, the Display Options dialog has an inefficient spacing of the settings which requires an unnecessary vertical scroll bar. On prior versions, the settings we spaced closer so that everything fit in the dialog:

[seandepagnier]

Originally Posted by tom_BigSpeedy

Hi there,

I know this not the precise post you'd like to see, and maybe also not 100% related to 1731, but I can confirm some unclear hangups of the system, as stated earlier in the thread.
I did compile my own versions till the morning of June 01 when I left for a doublehanded 500 miles race. Already the week before, I noticed those hangups, w/o a real crashdump. It simply comes to a standstill and doesn't react anymore (instruments are frozen), after 1 ... 3 hours. You have to kill O via task manager ...

Next time it becomes frozen, you should stop it in the debugger and figure out where it's stuck.

[Gilletarom]

Hello Boat_Alexandra,

Originally Posted by boat_alexandra

I only asked as a test to help determine the problem. I believe all the issues with zooming can be solved by tweaking a few things. I agree with pitzef to slow the wheel by half, but as for other changes, I don't know.

I did the test. And, indeed, the fault disappears if the check box "Enable touchscreen / tablet interface" is ON.

Best regards, Gilletarom.

[Ptizef]

Sorry but I am a little confused : Gerard (Gilletarom is speaking about zoom menu keys and Sean is answering about mouse wheel)
I re-test and will try to make it clear :
1) About zoom menu keys
I definitely agree with Gerard smooth zooming and GL on = need double click and no smooth (zoom one step at each double click)
activate touch screen suppress the double click but still not smooth
smooth zooming and no GL : no double click but still not smooth
No smooth zooming seems OK
In all case ALT has no action to reduce zooming with these two keys
2) mouse wheel zooming
slowing wheel by half is good but not enough.
The problem is that when you turn the wheel several times, you accumulate the amount of rotation and it become sufficient to go full zoom in and/or out.
make a test stressing wheel in and out as when creating a route or searching a site on the map and very quickly it become uncontrollable
this is done line 5760 :
m_wheelzoom_stop_oneshot += mouse_wheel_oneshot
I tried to replace += by + in this line . It work but is less efficient than my second proposal ( restart the timer )
In addition, and it's a good luck for me, it fixes the above menu keys problem
Smooth zooming become perfectly smooth both with mouse and keys and both GL and not GL
this have been tested on my two hardwares ( relatively old Vista one and recent small W8.1)
more : my second device is equipped with a touch screen : with touch screen option on, I had the same behavior when zooming with two fingers as with wheel and the same improvement after my two changes
JP

[bcn]

Just built against the latest changes on GIT on the ARM/Olimex A20 and now the response to zoom (+/-, mouse wheel) and pan behaves as expected.
Much better than before.

[bdbcat]

jp, Sean, et al...

I have committed a couple of changes to address the scroll zoom questions. I adjusted the wheel scroll code so that:
a. Isolated single click wheel zooms will not zoom more than a factor of 2, or 0.5, depending on direction. It may zoom less than 2/0.5, depending upon your system performance.
b. Single click wheel zoom in and then out ( or vice versa) will result in the expected zoom value, namely the same value as before the in/out action.
c. Multiple wheel zooms in the same direction do not accumulate.
d. Toolbar zoom buttons will not zoom more than 2/0.5, and may zoom less.

Maybe this will work better.

I still do not follow the ALT key problem you experience.


All other testers, please listen up.
There are a few things things to know about the new smooth-zoom user interface:
1. In smooth zoom mode, the zoom hotkeys (+/-) will zoom in or out as long as the button or key is pressed. This means that the resulting zoom value will depend upon your system performance, and how long you press the key. This is new behaviour relative to all previous Beta code.
2. With this latest commit, the toolbar zoom buttons will zoom as long as the button is pushed, up to a maximum of 2/0.5.
3. If you need exact binary zoom values in or out, it will be better to disable smoooth zoom/pan. Your choice.
4. Finally, smooth zoom is essentially "eye candy". We will get it right after some more testing. But in the end, if you don't like it, then don't use it.


Thanks
Dave

[Ptizef]

Built last GIT this morning
zooming with mouse wheel, "+" & "-" keys and menu buttons works as expected now
(except dysfunction with ALT keys)
Many thanks
JP

[P_Dub]

Dave[/QUOTE]
could you recompile a new version please (Windows)! I would appreciate
very much.
Best Regards

[bdbcat]

SailorF54...

I note that you report some unexplained hi CPU load hangups on 3.3.1731.

Lets focus in on this, and give smooth-zooming a little rest....

Can you give some more specific info?
1. What OS?
2. OpenGL configuration (from OCPN log)
3. How to induce hangs?
4. Charts in use.

Thanks
Dave

[sailorF54]

Originally Posted by bdbcat

SailorF54...

I note that you report some unexplained hi CPU load hangups on 3.3.1731.

Lets focus in on this, and give smooth-zooming a little rest....

Can you give some more specific info?
1. What OS?
2. OpenGL configuration (from OCPN log)
3. How to induce hangs?
4. Charts in use.

Thanks
Dave

Dave, I wish I could be more specific...
However
OS is uptodate W7 on a low grade dualcore laptop
OpenGL on, all 7131 options on (panning, texture compression, 128 Mb of texture cache...)
S63 charts with (important !) quilting on...
CPU usage goes to 100% (on the proc O uses) and remains so for several minutes (at least 5), blocking the app.
When this happens, any mouse /keybord action will sound a 'ting'
After killing the app in the task manager, nothing specific in the log.
BTW, memory usage is quite low (e.g. 77 Mo only)
FWIW: my S63 are not always next to each other (see pic)

15:01:00: Background world map loaded from GSHHS datafiles found in: C:\Users\admini\Desktop\OpenCPN3.3.1731\gshhs\
15:01:00: Loading World Chart Q=4 in 0 ms.
15:01:05: Initializing Chart C:\ProgramData\opencpn\s63\s63charts\49\FR501150.os63
15:01:05: "C:\Users\admini\Desktop\OpenCPN3.3.1731\plugins\s63_pi\OCPNsenc.exe" -n  -i "C:\ProgramData\opencpn\s63\s63SENC\FR501150.es57" -o "C:\Users\admini\AppData\Local\Temp\3203.tmp" -u D4E75051883EE016A2500EE73147 -e 1050E3FB -p FR50115020140831180E8E38F2C431A1180E8E38F2C431A1051886B3774F0BFC,0,,49, -z "C:\Users\admini\Desktop\OpenCPN3.3.1731\plugins\s63_pi\s63_pi.dll"
15:01:07: Initializing Chart C:\ProgramData\opencpn\s63\s63charts\49\FR574010.os63
15:01:07: "C:\Users\admini\Desktop\OpenCPN3.3.1731\plugins\s63_pi\OCPNsenc.exe" -n  -i "C:\ProgramData\opencpn\s63\s63SENC\FR574010.es57" -o "C:\Users\admini\AppData\Local\Temp\3D7A.tmp" -u D4E75051883EE016A2500EE73147 -e 1050E3FB -p FR57401020140831FD17E86BE7E71E2AFD17E86BE7E71E2AA85C3F37BE06C8E0,0,,49, -z "C:\Users\admini\Desktop\OpenCPN3.3.1731\plugins\s63_pi\s63_pi.dll"
15:01:22: Initializing Chart C:\ProgramData\opencpn\s63\s63charts\49\FR401500.os63
15:01:22: "C:\Users\admini\Desktop\OpenCPN3.3.1731\plugins\s63_pi\OCPNsenc.exe" -n  -i "C:\ProgramData\opencpn\s63\s63SENC\FR401500.es57" -o "C:\Users\admini\AppData\Local\Temp\76E6.tmp" -u D4E75051883EE016A2500EE73147 -e 1050E3FB -p FR40150020140831B37BD99AB7C29A6AB37BD99AB7C29A6AC44EBFC55DA46C4D,0,,49, -z "C:\Users\admini\Desktop\OpenCPN3.3.1731\plugins\s63_pi\s63_pi.dll"

[Baikal]

does not apply color change for vector vessel
I correct the color code on the vessel and displayed standard A red color
three weeks ago everything worked

// Establish ship color
// It changes color based on GPS and Chart accuracy/availability

if( SHIP_NORMAL != m_ownship_state )
return GetGlobalColor( _T ( "GREY1" ) );

if( SHIP_LOWACCURACY == m_ownship_state )
return GetGlobalColor( _T ( "YELO1" ) );

return GetGlobalColor( _T ( "MYSHIPCOLOR" ) ); // default is OK
}

[tom_BigSpeedy]

Originally Posted by bdbcat

I note that you report some unexplained hi CPU load hangups on 3.3.1731.

Lets focus in on this, and give smooth-zooming a little rest....

Can you give some more specific info?
1. What OS?
2. OpenGL configuration (from OCPN log)
3. How to induce hangs?
4. Charts in use.

Thanks
Dave

Hi Dave,

I had another hangup yesterday after sailing a couple of hours with the original 1731 (downloaded the package and installed it in parallel to avoid any sideeffects with missing directories, or data. We had this in the past, as you remember ...).
The only thing I changed was the dashboard_pi, as there's still a bug with the Wind Instruments.

Anyway, this time the hangup happened when opening the waypoint properties (right mouse click). The waypoint dialogue window didn't completely open, I just saw the outer frame. Sorry, I was in a harbour entrance, so had no time to investivage any deeper.
After immediate "kill" with task manager and restart, the waypoint dialogue window opened normal, as expected, so I don't think it is really related to the waypoint dialogue ...
It's W7, OpenGL off (Climatology crashes O with OpenGL on, when you move the mouse across the CM93 chart).

Two more bugs I noticed :
Garmin waypoint upload doesn't work anymore, after you restart O.
And : once set, there is no way to change the Upload com-port, except maually editing the ini file. That's actually what I currently do :
Edit the ini file, remove the Garmin-Upload com-port (parameter MostRecentGPSUploadConnection) and start O.
When you try to upload a WP to Garmin, you get the dialogue now, can select it and upload works.
After a restart of O, O claims waypoints are sucessfully uploaded, but nothing arrives at the GPS. This bug is already reproducable in 3.3.1606.

The CM93 chart offset dialogue doesn't seem to accept user x,y values anymore. I tried both with opengl on and off.
I can access the dialogue, and enter the offset values, but nothing happens.
After reopening the dialogue, my user-settings are gone back to 0, 0


BR,

Thomas