Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ui] Refactor the access to the list of recent project files #2637

Open
wants to merge 6 commits into
base: develop
Choose a base branch
from

Conversation

cbentejac
Copy link
Contributor

Description

This pull request addresses some performance issues that were detected when interacting with the list of recent project files.

It mostly focuses on refactoring the access to the list of recent project files, which involved reading the QSettings every single time the content of the list was to be accessed, and accessing it far too many times.

It also decouples the need for thumbnails between the homepage and the application: while the homepage needs access to thumbnails (if available) to set up the list of recent project files, the application has no use for them. When the list of project files is edited, there is no need to retrieve the corresponding thumbnail (if it exists) unless the current view is the homepage's.

Finally, it prevents the homepage from performing any such request for thumbnails unless it is actually being displayed.

Performance Summary

QSettings used to be read every single time recentProjectFiles was called:

  • When getting the list of project files to add a project file.
    • This includes "open file" and "save as" operations.
  • When getting the list of project files to remove a project file.
  • When getting the list of project files to set the root folder of any file dialog.
  • When getting the list of project files to fill the "Open Recent" menu.
  • When getting the list of project files to set the model for the homepage.
    • For this specific case, the model for the homepage was updated for every single update to the list (either adding or removing a project file) as many times as there were entries in the list. For example, if there were 30 project files in the list, QSettings were read 30 times just to setup the homepage at launch, and then 30 times again when a file was added (+ 1 time) or removed (-1 time).

=> QSettings are now only read once throughout the lifetime of the Meshroom instance.

Features list

  • Reduce the reading of the QSettings to a single occurrence (upon Meshroom launch)
  • Refactor the accesses and interactions (addition/deletion) with the list of recent project files
  • Separate the update of the project files' path and thumbnail
  • Prevent the homepage from requesting updates when it is not the active view

Implementation remarks

Prior to this PR, a call to the recentProjectFiles property necessarily involved a full reading of the QSettings, which provides for each entry both a path to the project file itself and a path to its thumbnail (if it exists). Upon the launch of Meshroom alone, if there were 40 project files in the QSettings, these QSettings were fully accessed and read 40 times just to set the homepage properly.

recentProjectFiles is now only an accessor to a list that is filled and edited in other calls, and which is initialized with a full reading of the QSettings when Meshroom is started, and never again during the lifetime of the instance. QSettings are thus only read once.

From there, any project file that is added or deleted leads to an update of the QSettings, but these settings are not read again to update the content of recentProjectFiles: recentProjectFiles is updated directly within these methods, ensuring it is always accurately reflecting the content of the QSettings.

When a project file is added, only the path to the project is added to the QSettings; there is no attempt to retrieve the thumbnail. However, a flag indicating that there may be some thumbnail paths to retrieve will be set.

When the homepage will become the current view again, it will request an update of the thumbnails. If the flag is set (meaning at least a file has been added to the list), all the project files in recentProjectFiles will be parsed in an attempt to retrieve their thumbnails. Otherwise (meaning that files have either been deleted or nothing has happened), nothing will happen.

The property itself only accesses a list instead of reading the QSettings
every single time it is called.

It is set once during the application's launch with a full reading, and
is then updated without performing extra reading operations every time
a file is added to or removed from the list.
When the list of recent project files is updated, there is no attempt
to retrieve its thumbnail as the update is said to be "minimal".

This minimal update is justified by the lack of use for the thumbnails
in the Application part of Meshroom. Thumbnails are only useful when
displaying the Homepage, hence their retrieval during Meshroom's
initialization. There is only a need to update them once we want to
display the Homepage again.

The Homepage thus requests an update of the thumbnails before setting
its model. If there have been some updates to the list of recent project
files, the reading of the QSettings is performed again and thumbnails
are retrieved whenever it is possible. Otherwise, nothing happens to
prevent useless readings.
Instead of doing it directly within the `_getRecentProjectFiles` method,
add a function that attempts to retrieve a thumbnail corresponding to
an input project file path.
…jects

There is no need to read the QSettings again as the content of
`self._recentProjectFiles` reflects their content accurately and they
do not store any thumbnail-related information.

QSettings will now only be read once, upon Meshroom's start.
@cbentejac cbentejac added this to the Meshroom 2024.1.0 milestone Jan 3, 2025
@cbentejac cbentejac self-assigned this Jan 3, 2025
Copy link

codecov bot commented Jan 3, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 69.93%. Comparing base (0586336) to head (60029f4).

Additional details and impacted files
@@           Coverage Diff            @@
##           develop    #2637   +/-   ##
========================================
  Coverage    69.93%   69.93%           
========================================
  Files          121      121           
  Lines         7088     7088           
========================================
  Hits          4957     4957           
  Misses        2131     2131           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant