1. Pass chat_id where appropriate
2. Pass message_id and chat_id (which are numbers) as numbers
3. Use pre-initialized QStrings more often
4. Don't pass numbers by const reference, it doesn't make sense
5. Removed some redundant const modifiers
Combination of maximumLineCount and TruncationMode.Elide (or Fade)
breaks Emoji image alignment, pushing the image down. Explicitly
truncating the text fixes the problem, at expense of certain runtime
overhead.
Also, toggle full and truncated Web page preview on tap.
1. Store and handle message ids as numbers rather than variants/strings
2. Incrementally update message id map
3. Expose additional roles and properties to avoid unnecessary lookups
The crash was happening when Repeater was adding context menu items
instantiated by PollPreview to context menu owned by MessageListViewItem.
It's fixed by instantiating those extra menu items inside context menu
itself. Generic ListElement couldn't be used because it doesn't like
functions as property values, hence this NamedAction thing.
there are still a few areas where there's no press effect (message items themselves: Text, profile thumbnail, sent icon,…)
but for now I've just aligned the components to the image changes
MouseArea filling the image was eating mouse events which should be
handled by the list item. Handle them all at the list item level and
forward the "clicked" event to the extra content items which declare
the clicked() function.
fixes#150: Now basically everything is inside a loader; ChatInformationPage is added to ChatPage with pageStack.pushAttached
fixes#166: Replaces the clunky VisualItemModel in tab view and doesn't initialize multiple times.
Profile images seem to be loading significantly faster after
moving file fetching logic to the native code and removing the
artificial delay.
TDLibFile is a generic object which can hopefully be used
elsewhere as an efficient replacement for JavaScript.
https://doc.qt.io/archives/qt-5.6/qtquick-performance.html
In general, "property var" should be considered to be superior to "property variant" for every use-case from QtQuick 2.0 and newer (note that "property variant" is marked as obsolete), as it allows a true JavaScript reference to be stored (which can reduce the number of conversions required in certain expressions).
First of all: Take all measurements I mention with a grain of salt – all of them are rough and not necessarily measured more than a few times. All times were measured on an Xperia X run via SDK.
Visiting a chat page can take a long time, especially before the qml is cached by the engine.
When opening it for the first time after application launch, it sometimes takes >1000ms from onClicked (OverviewPage) to Component.OnCompleted (Chatpage).
Subsequent activations take roughly 470-480ms.
With these changes, I was able to reduce these times to ~450ms for the first, ~100ms for subsequent activations of the ChatPage on my test device.
Things changed:
- The components for displaying extra content to a message are (mostly) gone and replaced by a single Loader. This Loader does not use sourceComponent to trade the initial compilation boost for a neglegible bit of runtime penalty.
- Connections were consolidated
- I was surprised how costly the inclusion of the RemorseItem was (compiling ~75ms, initializing up to ~20ms for every delegate). So I traded a bit for a compromise. deleteMessageRemorseItem is now defined on the appWindow level, where it gets a bit mitigated by the animations at application start. Also, only one deletion at a time is now possible. We can easily revert this change, but I thought it worthwhile despite its drawbacks.
- profileThumbnailComponent is now defined directly as sourceComponent, removing the need for its id. Probably didn't do anything.
- InReplyToRow had width: parent.width, so I removed horizontalCenter. Also probably didn't change compilation time at all.
- Another compromise I was willing to take – your opinion may differ: The PickerPages took ages (~200ms) to just parse/compile inside those Components, so I replaced them with the "string notation" of pageStack.push. Drawback: The first time a picker gets activated, you'll see how slow it is. Subsequent activations aren't that bad – also for the other pickers.
