<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 29-01-16 15:01, Dirk Hohndel wrote:<br>
</div>
<blockquote cite="mid:20160129140105.GG107838@rrmbpvm.gr8dns.org"
type="cite">
<pre wrap="">On Fri, Jan 29, 2016 at 09:11:26AM +0100, Jan Mulder wrote:
</pre>
<blockquote type="cite">
<pre wrap="">2) Swiping trough the dives I still sometimes get an empty profile.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
Agree that this is not a very high priority thing, and your
hypothesis sounds plausible.<br>
<br>
<blockquote cite="mid:20160129140105.GG107838@rrmbpvm.gr8dns.org"
type="cite">
<blockquote type="cite">
<pre wrap="">3) After 5 minutes of clicking and swiping I ran into a SIGSEGV. One thing,
</pre>
</blockquote>
<pre wrap="">
I assume you don't have a stack trace for that, do you?</pre>
</blockquote>
In fact, I do have a full tombstone on this. The contents is,
however, not very interesting. A very tiny fragment:<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<pre>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
<title></title><meta name="generator" content="LibreOffice 5.0.4.2 (Linux)"><style type="text/css">
@page { margin: 0.79in }
p { margin-bottom: 0.1in; line-height: 120% }
</style>
Somehow, this sounds suspicious, but might well be a Mobilecomponents or Qt/QML thing.
</pre>
<title></title><meta name="generator" content="LibreOffice 5.0.4.2 (Linux)"><style type="text/css">
@page { margin: 0.79in }
p { margin-bottom: 0.1in; line-height: 120%</style>
<blockquote cite="mid:20160129140105.GG107838@rrmbpvm.gr8dns.org" type="cite"><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
I'm not sure what you mean by "only renders (and computes) the things we
want". Can you explain a bit more?</pre></blockquote>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
</body></html>