Skip to content
Snippets Groups Projects

qt: retain pages in memory when navigating in the interface and when player opens

Open Fatih Uzunoğlu requested to merge fuzun/vlc:qt/dontunloadviews into master
1 unresolved thread

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

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
    • Author Reporter

      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).

    • Why not rely on qml stack view? it should be able to push and retain views. It's made for this.

      I tried to use this before, it was working for the most part. The (only?) issue I had was that the video widget was existing at two places during the "transition".

    • Author Reporter

      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 against StackView, 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 or url directly instead of an Item. For that, StackView should support pointing to the same page in its history nodes.

    • If we want to use StackView, we need to get rid of custom history and use its own history because

      I mean only between the player and the medialib

    • Author Reporter

      I thought the problem is not isolated to media library <-> player switch, but that it is a general problem which is also relevant with intra-media library navigation.

    • we probably shouldn't retain intra-medialib views. I think it's acceptable to reload when navigating back in history.

    • Author Reporter

      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...)

    • Author Reporter

      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.

    • Please register or sign in to reply
  • Steve Lhomme changed milestone to %4.0

    changed milestone to %4.0

  • Fatih Uzunoğlu added 467 commits

    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`

    Compare with previous version

Please register or sign in to reply
Loading