Periodically update progress bar
ClosedPublic

Authored by wcpan on Oct 19 2016, 9:36 AM.

Details

Summary

To avoid progress bar event flooding, adds a long-term timer to send the events periodically

BUG: https://bugs.kde.org/show_bug.cgi?id=369374

Diff Detail

Repository
R33 KDevPlatform
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
wcpan updated this revision to Diff 7537.Oct 19 2016, 9:36 AM
wcpan retitled this revision from to Periodically update progress bar.
wcpan updated this object.
wcpan edited the test plan for this revision. (Show Details)
wcpan added a reviewer: kfunk.
Restricted Application added a subscriber: kdevelop-devel. · View Herald TranscriptOct 19 2016, 9:36 AM
wcpan updated this revision to Diff 7539.Oct 19 2016, 9:48 AM

Add reviewer

wcpan updated this revision to Diff 7540.Oct 19 2016, 9:52 AM
wcpan edited reviewers, added: kdevelop-devel; removed: kfunk.

Change reviewers

wcpan edited reviewers, added: KDevelop; removed: kdevelop-devel.Oct 19 2016, 9:54 AM
wcpan updated this revision to Diff 7629.Oct 24 2016, 7:28 AM

update metadata

kfunk requested changes to this revision.Oct 27 2016, 7:37 AM
kfunk added a reviewer: kfunk.
kfunk added a subscriber: kfunk.
kfunk added inline comments.
language/backgroundparser/backgroundparser.cpp
210

There must be a different way to implement this feature, a constantly running timer is not good style. Maybe start/resume based on whether there are active jobs running?

In that regard, you should also be able to eliminate the need for m_needEmitProgress.

This revision now requires changes to proceed.Oct 27 2016, 7:37 AM
wcpan updated this revision to Diff 7715.Oct 28 2016, 6:37 AM
wcpan edited edge metadata.

Start/stop the progress timer in resume/suspend method.

brauch added a subscriber: brauch.Oct 28 2016, 2:33 PM

Good change in general, but why don't you simply start the timer at the place where showProgress() was emitted before, in case it's not running yet? Then you wouldn't need the "toggled on/off" state for the timer.

wcpan added a comment.Nov 3 2016, 9:29 AM

You mean make the timer single shot and change to this in updateProgress?

if (!m_progressTimer.isActive()) {
    m_progressTimer.start();
}

Yes, that sounds good to me.

wcpan updated this revision to Diff 7878.Nov 4 2016, 5:36 AM
wcpan edited edge metadata.

update patch

kfunk updated this object.Nov 16 2016, 11:51 PM
This revision was automatically updated to reflect the committed changes.
brauch reopened this revision.Nov 24 2016, 7:14 PM

Since this patch, I frequently see the background parser idle but the progress bar displaying "0%" like it's doing something. Did anybody else see this?

In D3110#65004, @brauch wrote:

Since this patch, I frequently see the background parser idle but the progress bar displaying "0%" like it's doing something. Did anybody else see this?

I'm see this annoying progress bar too. Should be fixed.

Maybe we need to move this check

//We don't hide the progress-bar in updateProgressBar, so it doesn't permanently flash when a document is reparsed again and again.
if(m_doneParseJobs == m_maxParseJobs
    || (m_neededPriority == BackgroundParser::BestPriority && m_weaver.queueLength() == 0))
{
    emit m_parser->hideProgress(m_parser);
}

to updateProgressBar().

Can you try this out and push it if it fixes the issue? Thanks :)

kfunk accepted this revision.Nov 30 2016, 7:10 PM
kfunk edited edge metadata.

Follow-up patch pushed.

This revision is now accepted and ready to land.Nov 30 2016, 7:10 PM
kfunk closed this revision.Nov 30 2016, 7:10 PM