> On Feb 10, 2016, at 7:26 AM, Sebastian Kügler <[email protected]> wrote: >> Tempted by the hypothesis of the slow profile rendering being the the >> issue of the "strange scrolling behavior", I did the following >> experiment. Commented the entire QMLProfile block (and the references to >> it) from the DiveDetails.qml. This does result in a page without the >> profile, so, with knowing much about the internals of QML, I assume that >> this suppresses any dive profile rendering related computations. >> >> This does not change the strange scrolling behavior. >> >> I agree that the profile rendering is an computational serious effort, >> and that asynchronous computation, and caching are very relevant ideas >> to tackle this, but I doubt that it touches the "80% scrolling" behavior. > > Hm, I tried this a while ago myself, and back then it had a noticeable > effect... I wonder what changed. (It's of course awesome that the profile > rendering doesn't seem the culprit anymore.) > > Next thing I can think of is a too complex details page.
That page is very simple. If you watch the effect you'll clearly see that everything is rendered already. What I'm wondering is if reaching the "80%" mark triggers the rendering of the NEXT page in the background (for caching). But I don't know enough about the QML implementation to make much sense of all this. It definitely feels awkward. This is one of the things in QML that are so frustrating - so much of the inner workings are completely opaque to the developer. /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
