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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
