[ui] Refactor the access to the list of recent project files #2637
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:=> QSettings are now only read once throughout the lifetime of the Meshroom instance.
Features list
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.