2020-09-28 23:58:11 +03:00
|
|
|
/*
|
2020-10-19 20:34:47 +03:00
|
|
|
Copyright (C) 2020 Sebastian J. Wolf and other contributors
|
2020-09-28 23:58:11 +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-09-28 23:58:11 +03:00
|
|
|
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
|
2020-11-17 20:18:22 +03:00
|
|
|
property MessageOverlayFlickable overlayFlickable
|
|
|
|
property var rawMessage: messageListItem ? messageListItem.myMessage : overlayFlickable.overlayMessage
|
2020-12-05 00:47:03 +03:00
|
|
|
property bool highlighted
|
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-11-06 01:23:37 +03:00
|
|
|
property var locationData : ( rawMessage.content['@type'] === "messageLocation" ) ? rawMessage.content.location : ( ( rawMessage.content['@type'] === "messageVenue" ) ? rawMessage.content.venue.location : "" )
|
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-11-17 20:18:22 +03:00
|
|
|
property string chatId: rawMessage.chat_id
|
2020-11-06 01:23:37 +03:00
|
|
|
property var 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
|
2020-09-28 23:58:11 +03:00
|
|
|
|
|
|
|
Component.onCompleted: {
|
|
|
|
updatePicture();
|
|
|
|
}
|
2020-12-04 22:22:21 +03:00
|
|
|
function clicked(){
|
|
|
|
if(!processLauncher.launchProgram('harbour-pure-maps', ["geo:"+locationData.latitude+","+locationData.longitude])) {
|
|
|
|
imageNotification.show(qsTr("Install Pure Maps to inspect this location."));
|
|
|
|
}
|
|
|
|
}
|
2020-09-28 23:58:11 +03:00
|
|
|
function updatePicture() {
|
2020-09-29 16:50:21 +03:00
|
|
|
imagePreviewItem.pictureFileInformation = null;
|
2020-09-28 23:58:11 +03:00
|
|
|
if (locationData) {
|
|
|
|
tdLibWrapper.getMapThumbnailFile(chatId, locationData.latitude, locationData.longitude, Math.round(imagePreviewItem.width), Math.round(imagePreviewItem.height));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Connections {
|
|
|
|
target: tdLibWrapper
|
|
|
|
onFileUpdated: {
|
|
|
|
// we do not have a way of knowing if this is the correct file, so we have to guess the first new one should be right.
|
|
|
|
if(!imagePreviewItem.pictureFileInformation) {
|
|
|
|
imagePreviewItem.pictureFileInformation = fileInformation;
|
|
|
|
tdLibWrapper.downloadFile(imagePreviewItem.pictureFileInformation.id);
|
|
|
|
} else if(imagePreviewItem.pictureFileInformation && fileInformation.id === imagePreviewItem.pictureFileInformation.id) {
|
|
|
|
imagePreviewItem.pictureFileInformation = fileInformation;
|
|
|
|
singleImage.source = fileInformation.local.path;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
AppNotification {
|
|
|
|
id: imageNotification
|
|
|
|
}
|
|
|
|
|
|
|
|
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 {} }
|
2020-12-05 00:47:03 +03:00
|
|
|
|
|
|
|
layer.enabled: imagePreviewItem.highlighted
|
|
|
|
layer.effect: PressEffect { source: singleImage }
|
2020-09-28 23:58:11 +03:00
|
|
|
Item {
|
|
|
|
anchors.centerIn: parent
|
|
|
|
width: markerImage.width
|
|
|
|
height: markerImage.height * 1.75 // 0.875 (vertical pin point) * 2
|
|
|
|
Image {
|
|
|
|
id: markerImage
|
|
|
|
source: 'image://theme/icon-m-location'
|
|
|
|
}
|
|
|
|
|
|
|
|
DropShadow {
|
|
|
|
anchors.fill: markerImage
|
|
|
|
horizontalOffset: 3
|
|
|
|
verticalOffset: 3
|
|
|
|
radius: 8.0
|
|
|
|
samples: 17
|
|
|
|
color: Theme.colorScheme ? Theme.lightPrimaryColor : Theme.darkPrimaryColor
|
|
|
|
source: markerImage
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-26 17:15:53 +03:00
|
|
|
BackgroundImage {
|
2020-09-28 23:58:11 +03:00
|
|
|
visible: singleImage.status !== Image.Ready
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|