2020-08-25 00:02:08 +03:00
|
|
|
/*
|
2020-10-19 20:34:47 +03:00
|
|
|
Copyright (C) 2020 Sebastian J. Wolf and other contributors
|
2020-08-25 00:02:08 +03:00
|
|
|
|
|
|
|
This file is part of Fernschreiber.
|
|
|
|
|
|
|
|
Fernschreiber is free software: you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
Fernschreiber is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with Fernschreiber. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
import QtQuick 2.5
|
|
|
|
import QtGraphicalEffects 1.0
|
|
|
|
import Sailfish.Silica 1.0
|
|
|
|
|
|
|
|
Item {
|
|
|
|
|
|
|
|
id: imagePreviewItem
|
|
|
|
|
Reduce ChatPage.qml jit compile time
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.
2020-10-30 22:36:32 +03:00
|
|
|
property ListItem messageListItem
|
|
|
|
property variant rawMessage: messageListItem.myMessage
|
|
|
|
property variant photoData: rawMessage.content.photo;
|
2020-08-25 00:02:08 +03:00
|
|
|
property variant pictureFileInformation;
|
|
|
|
|
Reduce ChatPage.qml jit compile time
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.
2020-10-30 22:36:32 +03:00
|
|
|
width: parent.width
|
|
|
|
height: width * 2 / 3
|
|
|
|
|
2020-08-25 00:02:08 +03:00
|
|
|
Component.onCompleted: {
|
|
|
|
updatePicture();
|
|
|
|
}
|
|
|
|
|
|
|
|
function updatePicture() {
|
2020-08-29 17:58:48 +03:00
|
|
|
if (photoData) {
|
2020-08-25 00:02:08 +03:00
|
|
|
// Check first which size fits best...
|
|
|
|
for (var i = 0; i < photoData.sizes.length; i++) {
|
|
|
|
imagePreviewItem.pictureFileInformation = photoData.sizes[i].photo;
|
|
|
|
if (photoData.sizes[i].width >= imagePreviewItem.width) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (imagePreviewItem.pictureFileInformation.local.is_downloading_completed) {
|
|
|
|
singleImage.source = imagePreviewItem.pictureFileInformation.local.path;
|
|
|
|
} else {
|
|
|
|
tdLibWrapper.downloadFile(imagePreviewItem.pictureFileInformation.id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Connections {
|
|
|
|
target: tdLibWrapper
|
|
|
|
onFileUpdated: {
|
2020-08-29 17:58:48 +03:00
|
|
|
if (imagePreviewItem.pictureFileInformation) {
|
|
|
|
if (fileId === imagePreviewItem.pictureFileInformation.id && fileInformation.local.is_downloading_completed) {
|
2020-08-25 00:02:08 +03:00
|
|
|
imagePreviewItem.pictureFileInformation = fileInformation;
|
|
|
|
singleImage.source = fileInformation.local.path;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Image {
|
|
|
|
id: singleImage
|
|
|
|
width: parent.width - Theme.paddingSmall
|
|
|
|
height: parent.height - Theme.paddingSmall
|
|
|
|
anchors.centerIn: parent
|
|
|
|
|
|
|
|
fillMode: Image.PreserveAspectCrop
|
|
|
|
autoTransform: true
|
|
|
|
asynchronous: true
|
|
|
|
visible: status === Image.Ready
|
|
|
|
opacity: status === Image.Ready ? 1 : 0
|
|
|
|
Behavior on opacity { NumberAnimation {} }
|
|
|
|
MouseArea {
|
|
|
|
anchors.fill: parent
|
|
|
|
onClicked: {
|
|
|
|
pageStack.push(Qt.resolvedUrl("../pages/ImagePage.qml"), { "photoData" : imagePreviewItem.photoData, "pictureFileInformation" : imagePreviewItem.pictureFileInformation });
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-26 17:15:53 +03:00
|
|
|
BackgroundImage {
|
2020-08-25 00:02:08 +03:00
|
|
|
visible: singleImage.status !== Image.Ready
|
|
|
|
}
|
|
|
|
}
|