OpenCPN Beta test 4.1.1108 Release

[Ptizef]

Originally Posted by Gilletarom

Hello Dave,
I just opened on my Lenovo U41, the plugin window to start the download Grib a Grib file. Unable to expand. It is far too high. In the bottom right, illegible button .... And the characters are not legible.

Some questions :
what's the OS?
The window font size seems incoherent ( the caption font is big whereas the body's small)
Is the font your choice or the default one?
Is this different from the others OpenCPN's dialogs?
Thanks
Jean Pierre

[Gilletarom]

Jean Pierre,

Originally Posted by Ptizef

Some questions :
what's the OS?
The window font size seems incoherent ( the caption font is big whereas the body's small)
Is the font your choice or the default one?
Is this different from the others OpenCPN's dialogs?
Jean Pierre

Jean Pierre Sorry, I had already given in this thread all the features of Lenovo machine that replaced my EeePC, EeePC that no longer works. And ... pretentiously, I thought that everyone had memorized.

Therefore, Lenovo U41, W 8.1. 64 bits. Processor: Intel core i5-5200U, CPU 2.20 GHz, 4 GB RAM, Intel HD Graphics 5500. 13-inch screen.
Installation O 4.11108 in parallel with O40.

Important Note: I have this problem with other software. Small font displayed with CCleaner or Komposer for example. But not with some other sofware.

Original installation, except the two cursors that are in the "Customize" from "Options". In general, the characters are pretty small (or very small, it is a matter of personal perspective). Same problem with the route manager for example. The characters are small. For cons, the size of the window of the road manager is normal, and I can change the width and / or height without any problems. And all buttons of the route manager are "normal".

There were other things like that I reported in this thread, Dave hence the use of the two cursors. Pushing the two sliders to the right, thoroughly, no difference in displays of grib plugin windows.


I added (see screenshot) it is the same with the plugin options page Grib.

The attached screenshots made under 0 411108 for three of them and under O40 for one of them. Under O40, the characters are legible.

best regards. Gilletarom.

[bdbcat]

JP...

I think this display format issue with GRIB request dialog is fixed by your commit:

fc9f15ebd33b2f5455ed4ec77c727ae10db7218a
Correct grib_pi request & setting dialogues display

This commit sizes the Request dialog height in respect to the OCPN canvas, not the full screen. Better...

I do not understand the "clipping" of the "Send/Cancel/Save" buttons.

Dave

[Tupaia]

Originally Posted by bdbcat

NahanniV....

Regarding the Radar window docking.

"Expedient" is the word. We are soon going to release Version 4.2.

Any plan to move OCPN away from wxWidgets display base is longer term, and has no real design nor resource allocation yet. Lots of questions here, but the main one in my mind is: "What if user doesn't have OpenGL, for whatever reason."

Dave

OpenGL is a problem on many machines. It would be nice if openGL ON/OFF setting related to all plugins. I know that radar plugin for example can be configured to run without OpenGL (sean did this) but the released plugin itself prevents this.

The result of not using OGL is not as efficient but it does mean it CAN run on systems across the board with no OpenGL or dodgy drivers.

Using stable release of OpenCPN 4.0.0. I have one PC where the OpenGL driver works fine for radar and Google Earth KAP charts under XP, But but under Win8/10 only works for radar when OGL is ON and for Google Earth KAPs with it is OFF. Windows 8 seems to impose it's own generic OGL drivers. Totally confusing.

I am about to update this hardware but it does demonstrate that there are problems in this area.

IMO - OpenCPN should be able to operate across the widest range of systems even if at a lower speed/efficiency on systems without OGL or with it switched OFF.

Peter

[NahanniV]

Originally Posted by Tupaia

OpenGL is a problem on many machines. It would be nice if openGL ON/OFF setting related to all plugins. I know that radar plugin for example can be configured to run without OpenGL (sean did this) but the released plugin itself prevents this.

The result of not using OGL is not as efficient but it does mean it CAN run on systems across the board with no OpenGL or dodgy drivers.

Using stable release of OpenCPN 4.0.0. I have one PC where the OpenGL driver works fine for radar and Google Earth KAP charts under XP, But but under Win8/10 only works for radar when OGL is ON and for Google Earth KAPs with it is OFF. Windows 8 seems to impose it's own generic OGL drivers. Totally confusing.

I am about to update this hardware but it does demonstrate that there are problems in this area.

IMO - OpenCPN should be able to operate across the widest range of systems even if at a lower speed/efficiency on systems without OGL or with it switched OFF.

Peter

Possibly related: What is the option "Software OpenGL" ?
It shows up on my ARM system under Options->Display->Advanced->Graphics->Options.

Cheers,
JM.

[Ptizef]

Dave

Thanks.

"I do not understand the "clipping" of the "Send/Cancel/Save" buttons."
With Gerard(Gilletarom) 's help we are testing some fixes, (just feeling not certainty)
Coming back soon.

Jean Pierre

[LeaseOnLife]

Originally Posted by bdbcat

Hakan/Rick, etc...

Memory leak:

Resolved.

~snip~

Dave

Now that the memory leak is solved, I can play with the aishub.net stream, showing >20000 AIS targets.

It takes about 5min to acquire 15000 targets, CPU load is ~22% for my machine. After 15min, O sees 20000 targets and CPU load has crept to 70%. After 30 min O has 22500 targets and starts becoming unresponsive.

I watched memory usage, it's stable! It is the CPU load, creeping up steadily. I have tracks for AIS targets turned off, so that shouldn't cause any extra CPU load. What else to test?

This is an extreme stress test, but it shows something is still fishy around AIS. A 33MB VDR file (takes a few seconds to load), 7zipped to 5MB, is here:


https://drive.google.com/file/d/0B1c...ew?usp=sharing

Dirk

PS: The aishub stream is not public, I can receive it because I am streaming AIS data to aishub, and they then share their data, access bound to my IP address.

[LeaseOnLife]

Playing back above VDR file is waayyy to slow, compared to real time, even with the VDR set to fastest speed. After 20min (about 2/3 of file recording time) the progress shows only ~20%. Is there a better way to play back the VDR file? Modify the source of vdr_pi? I am on a linux machine here, so don't have NavMonPc to record / playback.

CPU load has been creeping up slowly though, using VDR playback.

Dirk

[bdbcat]

Dirk...

After 30 min O has 22500 targets and starts becoming unresponsive.

Nothing too fishy about that. The AIS calculations seem relatively simple, but they happen once every second for each target. And wait until we merge Dirk's patch for visual filtering....

What happens if you filter out any source of ownship position? This should force the logic to skip the more expensive (T)CPA computations.

When I get some better bandwidth here I'll take a look at your VDR file.
We might be able to tighten up the logic somewhat by profiling a large dataset.

Make's a nice stress test, I agree.

Thanks
Dave

[did-g]

Originally Posted by bdbcat

Dirk...

After 30 min O has 22500 targets and starts becoming unresponsive.

Nothing too fishy about that. The AIS calculations seem relatively simple, but they happen once every second for each target. And wait until we merge Dirk's patch for visual filtering....

What happens if you filter out any source of ownship position? This should force the logic to skip the more expensive (T)CPA computations.

When I get some better bandwidth here I'll take a look at your VDR file.
We might be able to tighten up the logic somewhat by profiling a large dataset.

Make's a nice stress test, I agree.

Thanks
Dave

perf top output

Samples: 1M of event 'cycles', Event count (approx.): 2951813927, DSO: opencpn                                                                       
 98,04%  [.] Select::DeleteSelectablePoint(void*, int)                                                                
  0,51%  [.] AISDraw(ocpnDC&)

At least we know the culprit...

[seandepagnier]

I also have a pull request that makes rendering ais targets about 4x faster.

[LeaseOnLife]

Originally Posted by bdbcat

Dirk...

After 30 min O has 22500 targets and starts becoming unresponsive.

Nothing too fishy about that. The AIS calculations seem relatively simple, but they happen once every second for each target. And wait until we merge Dirk's patch for visual filtering....

What happens if you filter out any source of ownship position? This should force the logic to skip the more expensive (T)CPA computations.

When I get some better bandwidth here I'll take a look at your VDR file.
We might be able to tighten up the logic somewhat by profiling a large dataset.

Make's a nice stress test, I agree.

Thanks
Dave

New test:

• set 1000NM target limit in AIS list
• target track length set to zero
• unchecked "show target track"
• clicked "hide all tracks" in AIS list

15:40 start, with ~ 20% cpu for O
15:45 25-30% cpu 1623 targets
15:50 35-40% cpu 1767 targets
15:55 65-70% cpu 2374 targets
16:00 80-85% cpu 3378 targets
16:05 85-95% cpu 4075 targets
stopped test, O starts being unresponsive

compare that with last test, when initially 15000 targets are just fine. I don't think CPA/TCPA is the culprit.

fishy, , still not biting ?


Dirk

PS1: with limit range set to 1000NM it still shows all targets worldwide on the chart, is this intended?

PS2: did-g seems onto something.

[LeaseOnLife]

Originally Posted by boat_alexandra

I also have a pull request that makes rendering ais targets about 4x faster.

Love to try it, but it says on https://github.com/OpenCPN/OpenCPN/pull/450

This branch has conflicts that must be resolved
Only those with write access to this repository can merge pull requests.

Dirk

PS: teach me how to merge open pull requests to my PC, git still evades me

[transmitterdan]

I see something similar here. O maxes out the CPU and "hangs". I am using the Python VDR player found here:

https://github.com/transmitterdan/VDRplayer

This is the command line I am using:

python vdrplayer.py vdr-ais-cpuload-reaching-100percent.log 192.168.1.255 10110 0.001 UDP

This command broadcasts the AIS data via UDP to port 10110 for all machines on my LAN. It tries to send 1,000 AIS records per second. If I send faster than that (say 0.0001) O hangs right away.

It's pretty cool to see 15K+ AIS targets around the world all at once.

[seandepagnier]

Dirk

I have resolved