Android app -755

[Dirk Hohndel]

On Fri, Jan 29, 2016 at 04:23:36PM +0100, Jan Mulder wrote:
> >I keep thinking of a way to avoid this - but as it works "most of the
> >time" it hasn't bubbled to my top priorities, yet.
> Agree that this is not a very high priority thing, and your hypothesis
> sounds plausible.

I still want to go through the profile code and see if we can make it
faster / make sure all the options that could slow it down are disabled.

> >>3) After 5 minutes of clicking and swiping I ran into a SIGSEGV. One thing,
> >I assume you don't have a stack trace for that, do you?
> In fact, I do have a full tombstone on this. The contents is, however, not
> very interesting. A very tiny fragment:
> 
> Build fingerprint: 'Wileyfox/Swift/crackling:6.0.1/MMB29T/29bf0bab96:userdebug/test-keys'
> Revision: '0'
> ABI: 'arm'
> pid: 8435, tid: 8449, name: QtThread  >>> org.subsurfacedivelog.mobile <<<
> signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xe0502fdc
> 
> [snip]
> 
>  backtrace:
>     #00 pc 00017b90  /system/lib/libm.so (pow)
>     #01 pc 0281816c  [heap]

Yeah, not really helpful.
And once again the current calgrind / valgrind is broken and can't deal
with Subsurface, so this is even harder to test. Julian is aware of this
and working on a fix...

> Further, as you probably have seen, the logcat is full of warnings saying:
> 
> 01-29 08:31:01.801  8435  8457 W Subsurface: (null):0 ((null)): QObject::startTimer: Timers cannot be started from another thread
> 
> Somehow, this sounds suspicious, but might well be a Mobilecomponents or Qt/QML thing.

This is on my list of things I'm trying to track down and always get lost
in the weeds. Definitely ominous.

> >>I thing, that is very useful for an open beta is making sure that the
> >>profile does only renders (and computes) the things we want. I believe that
> >>this crash is coming from profile drawing, but cannot pinpoint at this
> >>moment.
> >I'm not sure what you mean by "only renders (and computes) the things we
> >want". Can you explain a bit more?
> As on IRC, the profile drawing seems very dive profile length dependent in
> the sense of performance. Currently, this is not a real problem for most
> users, as they are doing relatively short (in my vocabulary) dives. However,
> all unnecessary processing not only slows things down, but can also have a
> negative impact on stability, or even prevent usable crash stacks. So my
> philosophy here is: less processing is better. Not sure how easy it is to
> suppress the numerous options as available in the desktop software with
> respect to profile drawing, but it might be a "quick fix" for performance or
> stability on the mobile app. best, 

Oh yes, I 100% agree. This would be a great project for someone to dive
into because it will take some time to read the code, understand what we
do and make sure everything and anything that we can avoid has been either
turned off or maybe even compiled out.

/D