Android app -755

[Jan Mulder]

On 29-01-16 15:01, Dirk Hohndel wrote:
> On Fri, Jan 29, 2016 at 09:11:26AM +0100, Jan Mulder wrote:
>> 2) Swiping trough the dives I still sometimes get an empty profile.
> Yes, I had that yesterday. I believe this is caused by our somewhat
> asynchronous way of drawing the profile. Basically when you we set the
> dive, all we do is we tell the profile which dive it is supposed to draw.
> Then the profile "draws itself". Which is really nice and all in the
> desktop app because you don't need to worry about it. But in
> Subsurface-mobile we then paint the profile to a pixmap and show that
> pixmap. And if we do that before the profile was finished rearranging
> itself, we paint an empty pixmap. Or sometimes one that has only part of
> the depth / time grid drawn.
>
> 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.

>> 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]


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.

>> 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, --jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160129/ed7a825e/attachment.html>