OpenCPN Beta Version 4.6.22

[bdbcat]

Fabbian...

May we inspect your logfile?

Thanks
Dave

[bdbcat]

BitTomSpeedy....

I cannot reproduce a hang on Win7, cm93, overzoom torture.

Anyone else?

Try without OpenGL?

Dave

[transmitterdan]

Originally Posted by fgd3

Since 4.6 I've noticed OpenCPN is slow to start. I'm running 4.6.22 on Windows 10 now. When I launch OpenCPN my chart appears quickly, then I have to wait about six seconds before the toolbar is painted. I remember the program starting much quicker before. Have others noticed the delay?

Fabbian

Fabbian,

I notice the same thing. The toolbar paints quickly for me but the program isn't really up and running for about 5 seconds. I don't think it means anything is wrong. I believe O is trying to prebuild some data structures so that later on things happen much more quickly than before. For example, O builds the entire options dialog box with all the tabs at the beginning so that when you click the options button you get the options dialog without a lot of waiting.

Another thing is when you have NMEA streams coming in via Ethernet or WiFi this can slow down O's startup process. A bunch of messages pile up in the queue right after startup and O dutifully processes each message. This can take some time depending on how many plugins that handle NMEA you have enabled.

[transmitterdan]

Originally Posted by bdbcat

BitTomSpeedy....

I cannot reproduce a hang on Win7, cm93, overzoom torture.

Anyone else?

Try without OpenGL?

Dave

I don't have a mouse wheel but I use the two finger zoom on a touchpad. Cannot reproduce a freeze.

What I noticed is that if you keep trying to zoom in, the status bar blinks a bit as it is being bombarded with updates of the scale and zoom factor values. For example, in a test case it says "scale 800 (63x)" but the 63x flips between 62x and 63x a lot when trying to zoom beyond the max zoom level. With CM93 charts I can zoom in and out really fast.

Would be interesting to know the exactly setup in terms of "smooth panning / zoom", OpenGL options like texure cache and so forth.

[transmitterdan]

Originally Posted by P_Dub

Look Fabbian in the version 4.6.0 you right clik on the waypoints icon and the properties box open the same with double click also. Know you right click on the icon and it turn yellow and the spinning wheel for long time no access to the properties box. If you use Esc somethimes it will come up sometimes not.
The problem is existing and it as nothing to do with my computer it is the only program that does that. Better take a look at what was done. I have no hard feeling for your own information. I will wait for future version.
Have a good day.

P_Dub,

Right click on a waypoint brings up a context menu. One of the items in that menu is the waypoint properties. Other items are "Navigate to this", "Delete", etc. But it should not go to the properties dialog box on a single right click only. A double left click will bring up the waypoint properties dialog box.

While waiting for the context menu to pop up if you press ESC then you may never see the context menu. Same for the double click property dialog. ESC says to close the dialog even before it is shown.

If you see a waiting circle when you right click on a waypoint that may mean something is wrong with your system. Pressing ESC won't help. It could be that you have lots and lots of waypoints or some other large list of things that is causing O to take a long time to fetch the dialog box.

[Moo]

Originally Posted by bdbcat

BitTomSpeedy....

I cannot reproduce a hang on Win7, cm93, overzoom torture.

Anyone else?

Try without OpenGL?

Dave

I think this I may have been seeing something related. See earlier post.

Zooming out fast with two fingers on a pad often causes a crash - I've sent several crash reports. It does not happen when zooming with the wheel on my trackball (Logitech M570).

OpenGL is ON
Smooth panning is ON
Zoom to cursor is ON
Chart outlines OFF
Texture Compression ON
Preserve scale when switching charts ON
Show depth units OFF

Operating System
Windows 10 Home 64-bit
CPU
Intel Core i7 4510U @ 2.00GHz 45 °C
Haswell ULT 22nm Technology
RAM
8.00GB Single-Channel DDR3 @ 798MHz (11-11-11-28)
Motherboard
INTEL Corporation CRESCENTBAY (SOCKET 0)
Graphics
CY-465 (1024x768@60Hz)
Intel HD Graphics Family (Intel)

[tom_BigSpeedy]

Hi,

maybe it's really something like too much or too fast zooming by simply turning the mouse wheel too much.
See my opencpn.ini as attachement opencpn.ini.doc
and a short videoocpn_crash622.wmv
What you don't see in the video is the constant, quick "flickering" of the mouse cursor changing between normal arrow and hour glass, as soon as I start zooming (I'll try to find a better screencam tool ...).
In the end I just do nothing, ... cursor still flickering constantly ... just waiting till it finally stops flickering and shows the normal arrow again.
Then I move the chart with the mouse and it hangs up.
Finally just moving the cursor over the button bar and it's dead ("not responding").

Thomas
Edit: Sorry, video doesn't work somehow at least on my firefox setup ... I'll try to do another example ...

[tom_BigSpeedy]

Here is a short .mp4 video.
opencpn_622_crash.mp4.doc
Just save and remove the .doc from the file name. Sorry for the reduced quality, I had to keep it below 400kb to be able to upload as .doc. But you can see what I mean. There's only 1 instance of O running it's a graphics error of the screen capture tool.
I'm not zooming (turning the mouse wheel) all the time !
Just zoom in till max overzoom or maybe a bit more, wait, zoom out again, wait, etc.
At the end there's just a long waiting period doing nothing at all, till the cursor recovers ...
Then I try to pan around with the mouse and O dies ...
Thomas

[bdbcat]

Thomas...

OK, I see your video, understand, but cannot reproduce this. Works fine for me.

So lets try some experiments, to narrow it down.

1. What if zoom slowly with mouse wheel ( 1 click per second)?
2. What if use the zoom toolbar buttons, fast or slow?
3. What if use PgUP/PgDown keys, fast or slow.
4. What if turn off smooth zoom...
5. What if make the application window smaller...

Yada,yada... You get the idea. Change the parameters, and get the behavior to change in a repeatable way. This will give us some hints.

Dave

[tom_BigSpeedy]

Dave,
it took a while yesterday evening till this weird behaviour started. I guess I had about 10 O starts / shutdowns without any problems, and couldn't reproduce it as well.
But then all of a sudden it started, and then it was reproduceably every time I tried it...

All I can say for now is :
* Opencpn 4.4 does not have these crashes and also does not show the flickering cursor, no matter how fast I spin the mouse wheel
* it's definitely not related to the screen size nor the chart area
where I'm zooming in
* I need to hit the max overzoom limit to provoke a crash.
* playing (any) vdr file for a while seems to help provoking a crash.
--> Is it memory related ?
Can it be the mouse (wheel) settings in the windows control panel ?
--> you can define the number of "clicks"/lines per mouse wheel step.
Do I manage to get beyond the max overzoom limit somehow ?
Some buffer overrun, loosing some "clicks" when too fast ?

I'll give it a try tonight when I'm back home.

Thomas

[transmitterdan]

Thomas,

I may have missed it but can you tell us the type of CPU you have? Also, what video chip system?

[tom_BigSpeedy]

Hi,
it's an HP ProBook 450 G3
Intel® Core™ i5-6200U
Intel® HD-Graphics 520 (onboard)

and 2x8GB (16 GB) of SDRAM, i.e. both RAM slots filled, and graphics uses the 2nd chip ...

Thomas
Edit :
the second laptop where I can reproduce it is an old
Fujitsu Siemens Esprimo Mobile M10
Celeron dual core
w/ Intel onboard graphics as well
and 8GB of Ram on 2 slots ..

[transmitterdan]

Thomas,

Ok, so not a core i7 super fast CPU. I suspect there is some hard to reproduce set of conditions where the wxWidgets system causes event processing to slow to a crawl and the event queue is never emptied. So the program is not really hung but it's in what I would describe as a zombie state. A faster computer can empty the event queue and O can get out of trouble whereas slower CPUs cannot.

When this happens is the CPU usage of O really low or is it using 100% of one processor? That would be about 20-25% of total CPU. If the CPU usage is low (<5%) then that's what I have seen occasionally and I call it zombie mode. I have not been able to reproduce it reliably but I will keep trying. The spinning wait cursor is a clue. It probably means O called for a wait busy spinner and then never released it. That may help narrow down where it could be happening.

[tom_BigSpeedy]

Hi guys,

thanks for your help !

I just did some testing ...
if O hangs, CPU is constantly on 25%, i.e. full load on one CPU ...

I think it's OpenGL related.
Whenever I turn OpenGL on I manage to hang O, no matter if
* turn the mouse wheel fast
* turn the mouse wheel very slow, click by click
* turn smooth panning/zooming off (which I have normally set to on)
* use the zoom in / out buttons in the button bar by clicking them with the mouse either fast or slow.
* change the mouse wheel setting from 3 lines per tick to 1 lines per tick
* turn on/off the fog / blur effects on overzoom
...

As soon as I turn OpenGL off, I don't manage to crash O !

These are my OpenGL settings :



As I can reproduce it on my 2009 Fujitsu Laptop with Intel onboard graphics as well, I assume this may be "Intel OpenGL" related ???

Thomas

[tom_BigSpeedy]

Found an ocpn_gltest1.exe in my old 4.4 installation directory, but it doesn't seem to produce any output even if I run it from the command line ...

Here is some opengl related output from my opencpn.log file :
...
20:32:13: Creating MyFrame...size(1642, 1074) position(64, 20)
20:32:13: Creating glChartCanvas
20:32:13: Metrics: m_display_size_mm: 344 wxDisplaySize: 1920:1080
20:32:13: OpenGL-> Renderer String: Intel(R) HD Graphics 520
20:32:13: OpenGL-> Version reported: 4.4.0 - Build 20.19.15.4444
20:32:13: OpenGL-> Detected Intel renderer, disabling stencil buffer
20:32:13: OpenGL-> Texture rectangle format: de1
20:32:13: OpenGL-> glGenerateMipmap unavailable
20:32:13: OpenGL-> Detected Windows Intel renderer, disabling Vertexbuffer Objects
20:32:13: OpenGL-> Vertexbuffer Objects unavailable
20:32:13: OpenGL-> Using Framebuffer Objects
20:32:13: OpenGL-> Using FBO Stencil buffer
20:32:13: OpenGL-> Using Depth buffer clipping
20:32:13: OpenGL-> Not Using compression
20:32:13: OpenGL-> Minimum cartographic line width: 1.0
20:32:13: OpenGL-> Minimum symbol line width: 1.0
20:32:13: ChartDB Cache policy: Application target is 1024 MBytes
...
20:32:13: Loading CM93 cell C:\charts\CM93ed2_31May2010\CM93\03300840/D/03660840.D
20:32:13: OpenCPN in 407 ms initialisiert.
20:32:14: Warning: Color not found CHDRD
...

The only weird thing for me is the colour not found warning...

Thomas