On 2019/11/08 00:25, Dirk Hohndel wrote:
On Nov 7, 2019, at 2:02 PM, Linus Torvalds <torva...@linux-foundation.org>
wrote:
On Thu, Nov 7, 2019 at 12:14 PM Berthold Stoeger
<bstoe...@mail.tuwien.ac.at> wrote:
It doesn't have to. Just like you defined a proxy model on top of the
DiveListModel, one could implement a proxy model on top of the tree model that
"linearizes" it.
Maybe we should do that in general, even for the desktop case.
I don't think there is any major reason why the model should contain
all the dives. In many ways it would be much better if the model only
contains the *visible* dives, and we'd have a totally flat model,
where a trip (whether it's a collapsed header only, or the header for
a list of dives that has been exposed) is just a special model entry.
That would mean that we'd handle collapsing and exposing trips by just
removing/inserting the dives in the trip into that flat model.
IOW, get rid of the tree model entirely, and make that "proxy" model
be "the" model.
Yes, yes, we have this very clever code to keep dives selected even
when they're not visible. It's a pain. it's probably not worth it.
And it might be truly *lovely* for startup if we didn't populate the
whole model at all. For the git format, we could literally avoid even
parsing the dives that are in a collapsed trip and this not visible.
So we'd have a dive_table that isn't populated? That sounds entertaining.
And some magic code that figures out when we need a dive and then
quickly parses the information from git? But if loading XML we don't?
And statistics functions would trigger fully populating the dive_table?
Maybe it's the jet lag, but that sounds like a LOT of work and a lot of
new corner cases - and I'm not 100% sure what we'd gain.
I have only 640 dives in my dive list, so maybe that's not a good
benchmark, but even in a very low end VM with a single core and
not a lot of memory (2GB) I have never had issues with the Subsurface
startup speed on the desktop. Our mobile startup speed is terrible,
but that has other reasons.
/D
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
I would like to see retaining the feature of selecting a relatively
large number of dives for manipulation, many more than what is shown
on-screen at the time.
Given that, however, and as a totally separate issue, I must mention
that selecting a long list of dives for the first time from the dive
list currently is quite painfully slow, maybe around 6 sec. However,
once a selection has been made, subsequent selections are relatively
more fast. My guess is that, initially, not the whole dive list
structure is loaded?
Kind regards,
willem
--
This message and attachments are subject to a disclaimer.
Please refer to
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf
<http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf> for
full
details.
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
