qt: retain pages in memory when navigating in the interface and when player opens
This is VLC 3 dialogs approach, once a page loads it is kept in memory. This makes sense because if the user opens a page/view once, there is a high chance that it is going to be opened in the future again.
At the same time, currently the player is considered a page and going back from player causes the previous page to be re-loaded.
Since going this way retains the page in the memory,
the twitching of items is limited to the scene graph
node re-generation. In other words, the images are
retained (independent of cache) as long as
QSG_TRANSIENT_IMAGES
is not set (default) but
textures may be discarded.
Image nodes own the texture for QQuickImage
, and
setting an item invisible causes its node to be
deleted. If we want to retain the textures as well,
we can set the opacity to 0.0 instead of unsetting
visibility. When opacity is 0.0, the nodes remain
in the scene graph but are not rendered.
In this case I think we don't want to retain the textures (and other stuff owned by the nodes), as video memory is not as available as system memory.
We have not followed this approach previously to reduce the memory usage. However, there have been complaints so we should probably proceed with this.
If necessary, in the future we can implement a mechanism to unload the pages. For example, we can use a timer approach, such that if a view is not opened for a long time we can unload it.
This was also requested by @ePirat if I remember correctly.
Request review @chub.
Merge request reports
Activity
The memory impact of this would not be as huge as anticipated, because Qt Quick views do not keep (load) all the items in the memory, but only the items necessary to fill the viewport and some additional items to cover
cacheBuffer
and display margins.So if a page is opened that had big view with many items, not all of these items are kept in the memory. In fact, unless the user scrolled the whole view the majority of the items are not even loaded.
This excludes the model itself (if model itself consumes a lot of memory, it is a concern), I'm talking about the items that are displayed on the interface (delegate).
If we want to use
StackView
, we need to get rid of custom history and use its own history because I have not found a way to go to an arbitrary page with it. I'm not againstStackView
, but I'm not really willing to modify the navigation/history side at the moment, that is too complicated.Note that if we rely on its own history, I'm not sure if it supports what we try to achieve here (if page exists, switch to it and adjust properties), especially with supplying a
Component
orurl
directly instead of anItem
. For that,StackView
should support pointing to the same page in its history nodes.Can you explain the reasoning from your side?
I am personally not really convinced that the player page should be treated differently. If it shouldn't behave like a page, then it shouldn't be a page. If it is, then it should behave like a page.
From the looks of it it, it can be justified to be a page.
I am personally not really convinced that the player page should be treated differently
player and minimal are state of the application, they don't share much with the rest of the ml views in terms of aspect and navigation.
If it shouldn't behave like a page, then it shouldn't be a page
If they are page, this means that, when you go back in history you may sometime end up on the player view (even with nothing playing).
We already have signal differentiated from History to request the player to show up.
I think that navigation between the player and the ML is the case where reloading might be the most disturbing, if you make the video full then go back, it might be annoying if your view has changed.
while navigating between views, when pressing back you may be more forgivable if the view gets reloaded. like a page may get reloaded when you press back in your (web/file) browser.
what's annoying at the moment is that the list/grid animates when the view loads when navigating back, maybe we can improve on how page are restored (maybe restoring the y position in the scrollview instead of placing it on the last selected item, etc...)
If we treat Player not as a page, it should not be a page. What I do in this merge request is not a good solution for that.
That being said, what do we lose if we retain the medialibrary pages in memory? The idea of "if opened once, has relatively higher chance to be opened again" still applies.
If we used
StackView
, it would only unload when going back (pop()
). So we can think that a standard Qt application would keep the pages in memory in general.This aligns with the Qt Quick views not keeping all the items in the memory. If we have a Qt Quick application (that we have), we should follow the conventions of it.
Regarding browser or file explorer case, there are tabs for pages (as in VLC). When I switch tabs on a browser or a file explorer, I don't expect the browser to re-load the page.
added MRStatus::Reviewable label
added MRStatus::InReview label and removed MRStatus::Reviewable label
changed milestone to %4.0
added Component::Interface: Qt label
added 467 commits
-
ee9eb8ff...94f27356 - 462 commits from branch
videolan:master
- dbbfc237 - qt: do not request polish if invisible in `VideoSurface`
- f72019c4 - qml: unset video surface provider if invisible in `PIPPlayer` video surface
- a482704b - qml: load the content only when visible in `Player`
- fdf0e9d8 - qml: change component only when visible in `MainViewLoader`
- d800a7ee - qml: do not unload pages in `PageLoader.qml`
Toggle commit list-
ee9eb8ff...94f27356 - 462 commits from branch