I've found what appears to be a very severe memory leak in the DataChartView component. Something related to bitmap caching or something possibly related to synchronized scrolling. Sample project here:
https://dl.dropboxusercontent.com/u/56947838/MemoryLeak.zip
It manifests when you rotate the device, and with this sample it takes 4-5 rotations before the process runs out of memory.
This is with the public CTP builds, but other builds we're using also exhibit similar problems.
I've replicated on both a real device (Samsung 4.4) and a Genymotion Android 5.x emulator.
Thank you!
let me try this out so that we can see if the issue is the same for me as well
I've updated the memory leak sample. No rotations necessary, it crashes after about 30 seconds of adding/removing charts, cycling between one and two visible. The exact timing will depend on your device heap size and dpi, no doubt.
I also posted this to the private case.
Thank you.
There's a potentially deep recursive call that gets executed as part of the line simplification routines. Under normal circumstances this should get nowhere near the stack size limit, but certain line shape create a degenerate case, I believe. We only hit the stack limit once with one data shape with this logic on desktop in over 5 years, and fixed that case a month or 2 ago.
However, Android likely has a much lower stack size upper limit than desktop given how it partitions memory between processes. I know the fix we made for this isn't in the latest public release for Android yet, but am I correct in that we give you an untested build?
If that is the case, and the issue isn't resolved, then either the fix we made for desktop hasn't been propagated to the Android release, or we need to adjust some parameters of the fix to deal with the smaller stack limit for Android. Let me check the status of the fix first, but if you could let me know whether you are running a recent private build, that would be appreciated.
-Graham
Gotcha. We worked around this by disabling syncing (a nice to have feature).
The other problem with fastFlatten, though (different forum post)... that's our pain point today. We don't have a workaround for it. And for that reason it is impeding our business. If you have an easy fix for that we would be very grateful.
Note, though, that Andrew has been running a sample he created that isolated the problem with the sync setting, he'll try it out with the exact sample that you sent soon.