Beta Test / Technical

[PeteCross]

Originally Posted by Psyches

Hi Pete, yes I do this. I haven't noticed any big perf problem when I compile, and I generally compile and run the debug version on VC2008EE as well. I haven't done a side-by-side comparison though. Feel free to post specifics on problems you see.

Mark

Hi Mark,

So, you use the Sourceforge CVS code, good. Is the dev .exe we use, compiled with exactly Sourceforge CVS code?
The problems I see are that my version is extremely sluggish when panning/zooming. 20 seconds is not unusual and sometimes 60 secs to pan from one CM93 chart to the next. Sometimes it will to go into an endless loop, and doesn't change charts. Zoom in/out several steps and same problem. Just thought I would touch base to see that everything I have is correct before I delve in...... Could I send you my home-made .proj file?

/Pete

[Psyches]

Originally Posted by PeteCross

Hi Mark,

So, you use the Sourceforge CVS code, good. Is the dev .exe we use, compiled with exactly Sourceforge CVS code?
The problems I see are that my version is extremely sluggish when panning/zooming. 20 seconds is not unusual and sometimes 60 secs to pan from one CM93 chart to the next. Sometimes it will to go into an endless loop, and doesn't change charts. Zoom in/out several steps and same problem. Just thought I would touch base to see that everything I have is correct before I delve in...... Could I send you my home-made .proj file?

/Pete

Pete, I don't see the same behavior, using a mix of bsb and s57 noaa charts - so I'm not sure what's up. How about this - I've put a pointer to my latest proj, and you can check it against yours, or follow the instructions to just use it. Here's a link to the post: http://www.cruisersforum.com/forums/...tml#post393825

As far as the perf problem, I'm not sure what to tell you - you may need to do a bit of debugging or analysis to see where the time is going.

Mark

[philocat]

[QUOTE=HamishB;393431]I am curious to know if anyone has compared AIS support against the new AIS decoder from Gpsd?
/QUOTE]

Hamish,
Ref my post for additional background. #10 http://www.cruisersforum.com/forums/...nux-35178.html Gnuradio is active project unlike gnuais. The code to decode gmsk appears to reside in two c source files and should be a resonable pluging to gnuais. Transcribing to the nmea output code is relatively straight forward in comparison and many programs should be able to do this as does gnuais. I have not looked at how these compare to the gpsd code.

Since my post I have now got gnuais working standalone, but not robustly as I have determined my receiver is not sensitive enough. However I have also not been able to forward to OpenCPN via a 'virtual serial port' as Hackoon indicated. Gnuais is not very user friendly to a casual ubuntu user and on my machine it says it is unable to access port parameters.
As always when something doesn't work it is very difficult to track down what part of the software chain is broken.

[PeteCross]

Originally Posted by Psyches

Pete, I don't see the same behavior, using a mix of bsb and s57 noaa charts - so I'm not sure what's up. How about this - I've put a pointer to my latest proj, and you can check it against yours, or follow the instructions to just use it. Here's a link to the post: http://www.cruisersforum.com/forums/...tml#post393825

As far as the perf problem, I'm not sure what to tell you - you may need to do a bit of debugging or analysis to see where the time is going.

Mark

Mark,

Thanks for the help.
It was the compiler switches I was thinking about. Yours has much fewer, so I have tried this and it compiles without any warnings, just like mine, but the results are the same...
So I think it probably points to my charts....
We here in Europe and elsewhere, don't have the luxury of free official charts, so we often make do with various "dubious" sources of charts, plus own scanned, of varying quality.

I'll start digging now, no more excuses left....
Get back to you when I have something concrete.

/Pete

[raisin56]

Pete
Might I suggest that you download a few of our "free official charts" for testing. They may not help you out on the water but the can be used to see if it is the chart or not that is causing your sluggishness.

Dan

[cagney]

No, I did not give up

Here is another patch. This time I have done more testing on my box, and I'm fairly sure this one will work. But more testing is still needed. Please test and report back.
Psyches, please test on Win as well, as this patch affects other operating systems in a minor way, but anyway......better safe than sorry.
Replace nmea.h and ais.h in the source code "include" directory with the two provided files.

Thomas

[sredna]

Thomas, I promise I will give it a spin in a bit
Btw, maybe my failure yesterday could be a result of not doing make clean?

Anders

[Psyches]

Originally Posted by cagney

No, I did not give up

Here is another patch. This time I have done more testing on my box, and I'm fairly sure this one will work. But more testing is still needed. Please test and report back.
Psyches, please test on Win as well, as this patch affects other operating systems in a minor way, but anyway......better safe than sorry.
Replace nmea.h and ais.h in the source code "include" directory with the two provided files.

Thomas

Okee...builds on win. This time I'll wait for other verification too, before checking in

Mark

[ChuckSK]

Hello Mark

Builds OK here on Win.

Chuck

[sredna]

Is there a forum for developer discussion? Maybe sourceforge forum?

I have run into a issue that I do not understand: I try to calculate a scale for zooming into a route, supposedly pixel pr meter. So I calculate the width and height of the route bounding box in meters, and divede those by window (the chart) width/height, and select the least scale.

However, I have to multiply with 0.55, then the chart zooms so that the route is fully visible. Why is it 45% off?

      // Calculate bbox center
      double clat = route->RBBox.GetMinY() + (route->RBBox.GetHeight()/2);
      double clon = route->RBBox.GetMinX() + (route->RBBox.GetWidth()/2);
      
      // Calculate ppm
      double rw, rh, ppm; // route width, height, final ppm scale to use
      int ww, wh; // chart window width, height
      // route bbox width in nm
      DistanceBearingMercator(route->RBBox.GetMinY(), route->RBBox.GetMinX(),
                              route->RBBox.GetMinY(), route->RBBox.GetMaxX(),
                              NULL, &rw);
      // route bbox height in nm
      DistanceBearingMercator(route->RBBox.GetMinY(), route->RBBox.GetMinX(),
                              route->RBBox.GetMaxY(), route->RBBox.GetMinX(),
                              NULL, &rh);
     
      cc1->GetSize(&ww, &wh);
      ppm = wxMin(ww/(rw*1852), wh/(rh*1852));

      cc1->SetViewPoint(clat, clon, ppm*.55, 0, 0);

Probably, I do not understand the workings of ChartCanvas::SetViewPoint() correctly. It would be nice to understand fully how this works.

[Psyches]

Originally Posted by ChuckSK

Hello Mark

Builds OK here on Win.

Chuck

Thanks Chuck - for me as well; I'm waiting for replies from linux folks before checking in, since they had some probs last time.

M

[Psyches]

Hi Anders, dev discussions have been happening here or in private email rather than sourceforge. But I think using sf.net might be a good idea because open dev discussions have been somewhat limited to keep work inside "the sausage factory" to a minimum to coin Dave's phraseology :-)

http://www.cruisersforum.com/forums/...tml#post366383

I already get all sf.net forum posts, and some discussion is needed, so...feel free to start. And when I get a chance I'll look into your question / issue.

Mark

[bdbcat]

Sredna....

Two things going on here:
1. constant ppm values for a Mercator chart are meaningful only measured along parallels of latitude, or the "x" direction without skew. Your code may be choosing the y direction in the wxMin() function....

but more importantly....
2. A limitation of the current architecture requires that the ppm scale as passed to SetViewPoint() of a Raster chart must be a binary multiple of the chart native (1x) ppm scale. In 1.3.6 and below, this requirement is met by some code in chart1.cpp which makes this promise. This is done for performance reasons. You will need to do something similar to avoid funny display artifacts at arbitrary scale value.

See
ChartBaseBSB::GetClosestValidNaturalScalePPM(doubl e target_scale, double scale_factor_min, double scale_factor_max);


This limitation for raster charts is going away very soon now, as it is unwieldy for building chart quilts.....


Good Luck
Dave

[Psyches]

Thanks Dave...I was hoping you might respond. #1 makes sense, but wasn't sure about #2 - I believe Anders was using vector not raster currently. I think route code should not care about chart type and scale granularity so it sounds like we need more or different abstractions...and need to start removing chart-type dependencies in various places?

Any comments on sf.net for more code tech conversations? Are you back online more now?

Mark

[bdbcat]

Mark....

Sorry, another "drive-by" posting. Tomorrow I'm offline for a good month at least.

History: In the olden times, opencpn version 0.0.1 supported only BSB charts, and needed to run on 300 Mhz 256MB machine. And it did, with lots of limitations/optimizations for performance. Binary math on pixel bitmaps was one thing, and there were others.....

Fast forward to V1.3.6. Lots of vestigial code is still in there, requiring dynamic casting for access to the old optimized methods. With reasonably modern processor and memory specs, a lot of this stuff can go away. And it is going, Version-by-Version, with much nicer looking code as a result. We move forward by steps.

This is classic organic development. Just barely manageable with 3 or 4 coders. Any more and we would need to stop and write/negotiate some specs. And we may come to that eventually, but I instinctively resist so far.....

Here is another example to think about: In a quilted model, the notion of a "current chart" (ChartBase *Current_Ch in the code) goes away completely, to be replaced by a "current quilt". The chart select bar at the screen bottom goes away...etc., etc..... Turning quilting on and off will be a great big mode switch, affecting the UI just as much as the code guts.

Enjoy....
Dave