Plugin Development Help

[THEMuffinMan7]

Also, is there some sort of memory limit for plugins??

I am getting strange happenings now. For instance creating new wxBitmap now doesn't work. It always returns an invalid bitmap even though I successfully create one the same size when it starts up. Also converting from a large wxBitmap to wxImage crashes as well. As does trying to save a bitmap. I stepped through the code and cannot determine the cause of these errors but it seems to occur when creating or handling big files (my wxBitmap is 13000x13000 pixels)

Also these problems seem to go away if I reduce the size of the bitmap.

[bdbcat]

Well, I suppose you understand that a 13k x 13k bitmap requires about 650MB of real RAM? That will push just about everything else into swap, if you have it enabled. Unlikely to work in any real system environment.

Rethink your logic...

Dave

[THEMuffinMan7]

Yea.. its just it has worked great on a couple machines up until now that I am trying to add a couple final features (such as save/ load). And my system memory usage only goes up a fraction of that (under 200MB as viewed on task manager) when I run the plugin, which seems fine to me.. Even at 600+MB its not ideal but I don't see why it shouldn't still work. My memory usage is only 30% nothing should be in swap memory. It seems that either wxWidgets cant handle big files or more likely opencpn is limiting the memory it or my plugin allocates.

Assuming I have to switch methods, what would be a good alternative for overlaying a bitmap? I need coverage of at least several continuous square miles zoomable fairly close (at least around 3000 chartscale). I thought of having multiple smaller bitmaps (saved to disk) but seamlessly switching between them might be tough and id probably need another thread to preload them and everything. Also I'd have to have 4 loaded at once (worst case) so the worst case memory allocation could still be high. Rendering real time would be fine memory-wize but would be too slow for the number of potential lines (unless boat_alexandra's track drawing optimization is order of magnitudes faster than getCanvasPix->DrawLine)

Maybe SVG?

it should be possible to dramatically compress my bmp since its only made of two colors. Red and transparent. ie bit depth could be 1 lol. I don't know how I'd implement that to solve my problem though

[did-g]

Originally Posted by THEMuffinMan7

Yea.. its just it has worked great on a couple machines up until now that I am trying to add a couple final features (such as save/ load).

Is your system 64bits? If not you should use one, with a little memory fragmentation it's unlikely you could get many 650 MB arrays in a 32 bits process space.

[THEMuffinMan7]

Its a 64bit system with 16 GB of RAM shortly after a reboot so I don't think that was the problem, but your point about fragmentation is a good one, thanks.

Saw in the user manual:

"If you do not enter any memory management specification in the config file, the following defaults apply:

a. Linux... behavior is the same as previous versions, Open chart limit is 20 charts.
b. Windows and Mac...Application memory limit target is used. Target limit is 50% of available physical RAM, up to a maximum of 1 gigabyte."

^ Looks like openCPN limits memory to 1GB under windows. Ill try setting MEMCacheLimit in the config file over the weekend to a larger value and see if it changes anything. Not a good fix either way. Ill have to think of a better implementation

[did-g]

Originally Posted by THEMuffinMan7

Its a 64bit system with 16 GB of RAM shortly after a reboot so I don't think that was the problem, but your point about fragmentation is a good one, thanks.

Saw in the user manual:

"If you do not enter any memory management specification in the config file, the following defaults apply:

a. Linux... behavior is the same as previous versions, Open chart limit is 20 charts.
b. Windows and Mac...Application memory limit target is used. Target limit is 50% of available physical RAM, up to a maximum of 1 gigabyte."

^ Looks like openCPN limits memory to 1GB under windows. Ill try setting MEMCacheLimit in the config file over the weekend to a larger value and see if it changes anything. Not a good fix either way. Ill have to think of a better implementation

It doesn't matter how long the OS is up if you're running a 32 bits software.

I'm not sure MEMCacheLimit is the problem here, it's mostly used for OpenCPN charts cache size and It's not a hard limit, it'd only make zoom in and zoom out slow I think.

I'd be very slow but can you try without openGL?

[THEMuffinMan7]

I'm not using openGL

[did-g]

Originally Posted by THEMuffinMan7

I'm not using openGL

Ok,

For me there's nothing obvious for such behavior, it should work...

Yo can recompile wxWidgets in debug mode, it has many asserts and may trigger one if there's an overflow somewhere in wx or ocpn code.

[seandepagnier]

Originally Posted by THEMuffinMan7

uld be too slow for the number of potential lines (unless boat_alexandra's track drawing optimization is order of magnitudes faster than getCanvasPix->DrawLine)

It is. You can have millions of line segments, and it very quickly formulates just a few, well not more than the pixels on the screen, usually much fewer. I had maximum of 120 segments worst case from 80,000 segment track.

it should be possible to dramatically compress my bmp since its only made of two colors. Red and transparent. ie bit depth could be 1 lol. I don't know how I'd implement that to solve my problem though

First of all, if you have this 600MB bitmap, then likely in various operations, wxwidgets will allocate 2 or 3 copies of it. For this reason you should use tiles of 512x512 or maybe 1024x1024.

What are you doing with such files? Opencpn already efficiently handles this sort of thing rendering charts.

If you are using opengl, then you can easily use a single channel texture cutting memory consumption considerably. Further you could use rgtc which would half again with still very high quality using only 80MB of memory.

[THEMuffinMan7]

Hi folks.

This project is very close to being completed however I am struggling with OpenGL at the moment. It seems to draw on top of waypoints in OpenCPN and I cant figure out how to fix this issue as I need to be able to see the waypoints through the overlay. Thanks in advance.

[nohal]

You can't currently change the drawing order beyond changing order of the plugins (But still all of them always draw over the core layers). There are probably 3 approaches possible:
* You can make your overlay semi transparent so that the waypoints will be visible through it (Looking at your picture, I would actually also like to see the underlying chart, so this solution IMHO makes the most sense)
* You can draw the waypoints yourself over the overlay (Easy to implement - you can copy most of the code from the core application)
* You can submit a patch to OpenCPN core to implement the layer draw ordering feature, which will become available in the next release

Pavel