Throttle ui updates #9863
Throttle ui updates #9863
Conversation
|
Some of the stuff in there really needs to run on an item level. |
src/gui/folderstatusmodel.cpp
Outdated
| // every connect has its own progressUpdated | ||
| connect(f, &Folder::progressInfo, this, [progressUpdated = std::make_unique<std::chrono::system_clock::time_point>(std::chrono::system_clock::now()), f, this](const ProgressInfo &info) mutable { | ||
| // throttle how often we update the progress | ||
| if (std::chrono::system_clock::now() - *progressUpdated > progressUpdateTimeOutC) { |
There was a problem hiding this comment.
Hm, I suggest using QElapsedTimer class. More clean imho.
TheOneRing
force-pushed
the
work/9832
branch
2 times, most recently
from
1607e47
to
7fc04b0
Compare
|
Results for GUI-tests https://drone.owncloud.com/owncloud/client/12363/6/1 |
| roles << FolderStatusDelegate::SyncProgressItemString | ||
| << FolderStatusDelegate::WarningCount | ||
| << Qt::ToolTipRole; | ||
| const QVector<int> roles = { FolderStatusDelegate::SyncProgressItemString, FolderStatusDelegate::WarningCount, Qt::ToolTipRole }; | ||
|
|
||
| if (progress.status() == ProgressInfo::Discovery) { | ||
| if (!progress._currentDiscoveredRemoteFolder.isEmpty()) { | ||
| pi->_overallSyncString = tr("Checking for changes in remote '%1'").arg(progress._currentDiscoveredRemoteFolder); | ||
| emit dataChanged(index(folderIndex), index(folderIndex), roles); |
There was a problem hiding this comment.
I wonder if we should not check if progress.status() is different than the status that is stored currently. If it is not different we could save the dataChanged() emit completely, or not?
There was a problem hiding this comment.
Those states are only emitted once per discovery.
Only Propagation or Done are emitted over and over again
src/gui/folderstatusmodel.cpp
Outdated
| // progress updates are expensive, throtle them | ||
| if (std::chrono::system_clock::now() - _lastProgressUpdated > progressUpdateTimeOutC) { | ||
| computeProgress(progress, pi); | ||
| _lastProgressUpdated = std::chrono::system_clock::now(); |
There was a problem hiding this comment.
Ah, there is this QElapsedTimer which is very nice and neat...
There was a problem hiding this comment.
QElapsedTimer does not support std::chrono so I would need to perform an ugly duration cast on the qint64 returned by it or on our progressUpdateTimeOutC.
And in the end we would replace a subtraction with lots of casts.
There was a problem hiding this comment.
Yes, progressUpdateTimeOutC would be a qint64, which would result in more clear code for me. But... yes.
| Enhancement: Run vfs downloads with a high priority | ||
|
|
||
| This should reduce the probability for timeouts when downloading vfs files in the Windows explorer. |
There was a problem hiding this comment.
| Enhancement: Run vfs downloads with a high priority | |
| This should reduce the probability for timeouts when downloading vfs files in the Windows explorer. | |
| Enhancement: Run VFS downloads with a high priority | |
| This should reduce the probability for timeouts when downloading VFS files in the Windows explorer. |
|
Kudos, SonarCloud Quality Gate passed! |
In #9863 we started throtteling the the ui updates during sync, this throttles the updates even more.
In #9863 we started throtteling the the ui updates during sync, this throttles the updates even more.
In #9863 we started throtteling the the ui updates during sync, this throttles the updates even more.
In #9863 we started throtteling the the ui updates during sync, this throttles the updates even more.
In #9863 we started throtteling the the ui updates during sync, this throttles the updates even more.
Issue: #9832