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/>.
|
|
|
|
*/
|
2020-10-31 22:49:03 +03:00
|
|
|
import QtQuick 2.6
|
2020-08-25 00:02:08 +03:00
|
|
|
import Sailfish.Silica 1.0
|
2020-12-03 05:42:51 +03:00
|
|
|
import WerkWolf.Fernschreiber 1.0
|
2020-08-25 00:02:08 +03:00
|
|
|
|
|
|
|
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
|
2020-11-17 20:18:22 +03:00
|
|
|
property MessageOverlayFlickable overlayFlickable
|
|
|
|
property var rawMessage: messageListItem ? messageListItem.myMessage : overlayFlickable.overlayMessage
|
2020-12-03 05:42:51 +03:00
|
|
|
property var photoData: rawMessage.content.photo
|
|
|
|
readonly property int defaultHeight: Math.round(width * 2 / 3)
|
2020-08-25 00:02:08 +03:00
|
|
|
|
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
|
2020-12-03 05:42:51 +03:00
|
|
|
height: singleImage.visible ? Math.min(defaultHeight, singleImage.bestHeight + Theme.paddingSmall) : defaultHeight
|
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
|
|
|
|
2020-12-04 06:12:00 +03:00
|
|
|
function clicked() {
|
|
|
|
pageStack.push(Qt.resolvedUrl("../pages/ImagePage.qml"), {
|
|
|
|
"photoData" : imagePreviewItem.photoData,
|
|
|
|
"pictureFileInformation" : imageFile.fileInformation
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2020-08-25 00:02:08 +03:00
|
|
|
Component.onCompleted: {
|
2020-08-29 17:58:48 +03:00
|
|
|
if (photoData) {
|
2020-08-25 00:02:08 +03:00
|
|
|
// Check first which size fits best...
|
2020-12-03 05:42:51 +03:00
|
|
|
var photo
|
2020-08-25 00:02:08 +03:00
|
|
|
for (var i = 0; i < photoData.sizes.length; i++) {
|
2020-12-03 05:42:51 +03:00
|
|
|
photo = photoData.sizes[i].photo
|
2020-08-25 00:02:08 +03:00
|
|
|
if (photoData.sizes[i].width >= imagePreviewItem.width) {
|
2020-12-03 05:42:51 +03:00
|
|
|
break
|
2020-08-25 00:02:08 +03:00
|
|
|
}
|
|
|
|
}
|
2020-12-03 05:42:51 +03:00
|
|
|
if (photo) {
|
|
|
|
imageFile.fileInformation = photo
|
2020-08-25 00:02:08 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-12-03 05:42:51 +03:00
|
|
|
TDLibFile {
|
|
|
|
id: imageFile
|
|
|
|
tdlib: tdLibWrapper
|
|
|
|
autoLoad: true
|
2020-08-25 00:02:08 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
Image {
|
|
|
|
id: singleImage
|
|
|
|
width: parent.width - Theme.paddingSmall
|
|
|
|
height: parent.height - Theme.paddingSmall
|
2020-12-03 05:42:51 +03:00
|
|
|
readonly property int bestHeight: (status === Image.Ready) ? Math.round(implicitHeight * width / implicitWidth) : 0
|
2020-08-25 00:02:08 +03:00
|
|
|
anchors.centerIn: parent
|
|
|
|
|
|
|
|
fillMode: Image.PreserveAspectCrop
|
|
|
|
autoTransform: true
|
|
|
|
asynchronous: true
|
2020-12-03 05:42:51 +03:00
|
|
|
source: imageFile.isDownloadingCompleted ? imageFile.path : ""
|
2020-08-25 00:02:08 +03:00
|
|
|
visible: status === Image.Ready
|
2020-12-03 05:42:51 +03:00
|
|
|
opacity: visible ? 1 : 0
|
|
|
|
Behavior on opacity { FadeAnimation {} }
|
2020-08-25 00:02:08 +03:00
|
|
|
}
|
|
|
|
|
2020-10-26 17:15:53 +03:00
|
|
|
BackgroundImage {
|
2020-08-25 00:02:08 +03:00
|
|
|
visible: singleImage.status !== Image.Ready
|
|
|
|
}
|
|
|
|
}
|