Prepare another optimization round

[jgibbon]

I initially only thought about optimizing OverviewPage, because that didn't get much love, yet. But then some ChatPage issues "popped up", as well.

As I am not able to assess all of those points (not very familiar with how/why some of these things were done exactly, especially c++ interaction), I'd appreciate some feedback (or even implementation help later on) at least on the less obvious ones marked with :question::question:. They are numbered to make referencing a tiny bit easier.

1. OverviewPage

• 1.1 Initialization is quite heavy: The opacity fade when loading gets false does stutter a bit. It will already be better if the other issues here are done. :question::question: Alternatively: Handle loaded in a Timer (maybe an existing one), as well?
• 1.2 updateContent()
  • not a huge performance problem, but it gets called onStatusChanged which means also on PageStack.pop. :question::question: Do we need that for all calls inside? Or would it be enough to call (some of them?) on init?
• 1.3 :question::question: Is redrawModel really, really needed? It recreates all rendered delegates AFAICT, which is a bit heavy & weird on init. Almost all other init issues' impact gets doubled by this one, I think.
• 1.4 :question::question: onChatChanged: Doesn't do much, but it gets called a lot. Thousands of times on init for me. Do we really still need that?
  • :question::question: Also, does chatListModel even need to emit it multiple times on init?
• 1.5 We should do a variant of the ContextMenu Loader workaround from ChatPage, as well. Profiler shows quite a bit of time wasted here.
• 1.6 We should do a variant of precalculatedValues to reduce time spend on repeated (mostly width) bindings/calculations uselessly, which according to the Profiler adds up on init/while scrolling.

2. ChatPage

• 2.1 viewMessageTimer: Only do viewMessage if the last read index < lastQueuedIndex?

2.2 MessageListViewItem

• 2.2.1 chatModel Connections
  • 2.2.1.1 onMessagesIncrementalUpdate: chatModel.getLastReadMessageIndex gets called for every message instance after every scroll
    • put lastReadMessageIndex into precalculatedValues, bind everything to that (also for the other signals)
    • :question::question: does chatModel need to emit it every time, even if nothing changed?
  • 2.2.1.2 onLastReadSentMessageUpdated: gets called for every visible message? Perhaps that can get handled with precalculatedValues, too?
• 2.2.2 :question::question: getMessageStatusText: put inside messageDateText, call directly without parameters (DRY). Perhaps cache the old text to prevent unneeded emojify calls? Or use a rawText property to change & don't touch the text binding at all – it should then be updated when the other properties change, as well. Maybe there's also something to be optimized with the lastReadSentIndex checking inside.
• 2.2.3 replace model.display.type['@type'] === "chatTypePrivate" with chat_type check?

3. visible/opacity bindings

Some bindings are checked twice instead of just checking on visible and referring to that, or visible even rechecks on every change of the opacity Behavior:

• 3.1 ProfileThumbnail: Make profileImageComponents visible binding dependent of singleImage.status, and opacity dependent on it (switch around), or it may get called pretty often because of opacitys Behavior. This exact issue is also present in StickerPreview(twice), ImagePage and InitializationPage.
  • 3.2 BackgroundProgressIndicator: use opacity: visible ? 1.0 : 0.0

    visible: progress < 100
    opacity: progress < 100 ? 1 : 0

  • 3.3 ImagePreview/LocationPreview singleImage: see above
  • 3.4 StickerPicker stickerPickerFlickable/loading column: see above
  • 3.5 OverviewPage loading column: see above (mind negative value)
  • 3.6 WebPagePreview singleImage: see above
  • 3.7 :question::question: PinnedMessageItem unpinMessageIconLoader is the Behavior on opacity even used?

    4. CoverPage

• 4.1 The CoverPage duplicates some functionality from OverviewPage. This leads to both requesting tdLibWrapper.getAuthorizationState() & tdLibWrapper.getConnectionState() and adding connections to listen to changes for themselves. This could be merged in applicationWindow. This would reduce the need for the JS functions setUnreadInfoText (CoverPage) and setPageStatus, as well, in favour of more optimized bindings.
• 4.2 All Texts inside the CoverPage should be OK with Text.PlainText. I guess there are dozens of other places where we know we don't have emojis/html. This could be implemented globally.

[jgibbon]

Prioritization:

The only really bad thing that I can't handle without some context is 1.3 from the OverviewPage:

1.3 :question::question: Is redrawModel really, really needed? It recreates all rendered delegates AFAICT, which is a bit heavy & weird on init. Almost all other init issues' impact gets doubled by this one, I think.

The other things either aren't really bad or I can fix them myself.

[monich]

Slightly off topic but since opacity animation was referenced.... There're two ways to bind opacity and visibility. This:

visible: opacity > 0
opacity: needToDisplay ? 1 : 0

and this:

opacity: visible ? 1 : 0
visible: needToDisplay

Both make sense but behave differently with respect to opacity animation. In the first case visible: opacity > 0 the item's opacity is being animated both ways, when it's appearing and when it's disappearing. In the second case opacity would be animated only when the item is appearing on the screen. When visible becomes false, the item disappears immediately regardless of its opacity.

I typically use the first variant by default.

And yes, it's a good idea to set visible to false for the items which are not needed, to completely remove them from the event processing chain.

[monich]

I would also look towards using enums (e.g. for chat/message types) and compare numbers rather than strings. C++ part (exposing more enums and associated roles from the models) need to be done first, and in that sense doesn't interfere at all with QML-only optimization.

Using TDLibFile can remove some signal processing from QML and push it to native code which should be good for performance.

[jgibbon]

Not off topic at all, that is a very good point! I'll make sure to skip 3.1, since it's very much intended.

[jgibbon]

Using TDLibFile is also a good addition.