Defer short-running jobs from the progress view#4131
Conversation
| } | ||
| }; | ||
| pendingJobAdditions.put(job, graceTimer); | ||
| display.asyncExec(() -> { |
There was a problem hiding this comment.
This can flood UI thread with asyncExec / timerExec tasks for short living jobs. I would not misuse UI thread to dispatch tasks just to make sure progress view don't show jobs.
There was a problem hiding this comment.
Reworked to avoid per-job UI dispatch: pendingJobAdditions is now a Map<Job, Long> of grace deadlines instead of per-job timers. Scheduling only puts the deadline in the map; notifyListeners() (the throttler's coalesced UI pass) drains and announces the expired entries, re-arming once via throttledAsyncExec() while any remain. Cancelling is a plain ConcurrentHashMap.remove, no dispatch.
| return false; | ||
| } | ||
| if (display != null && !display.isDisposed()) { | ||
| display.asyncExec(() -> display.timerExec(-1, pending)); |
There was a problem hiding this comment.
Same fix: cancelling is now just pendingJobAdditions.remove(job), no asyncExec/timerExec.
vogella
force-pushed
the
worktree-progress-grace-period
branch
from
7f66863 to
382bc50
Compare
vogella
force-pushed
the
worktree-progress-grace-period
branch
from
382bc50 to
65fabb6
Compare
vogella
force-pushed
the
worktree-progress-grace-period
branch
from
65fabb6 to
b04f881
Compare
|
@iloveeclipse any additional feedback? |
merks
left a comment
merks
left a comment
There was a problem hiding this comment.
Looks okay. Just nit questions.
|
@merks I assume M1 is already out or at least finished. Please let me know if that is wrong. |
vogella
force-pushed
the
worktree-progress-grace-period
branch
from
b04f881 to
24b81ed
Compare
Non-system jobs were shown in the progress view the moment they were scheduled and removed when they finished, so jobs that complete within a few hundred milliseconds flashed in and out and could not be read. Add a per-job grace period before a job is announced to the progress listeners. Jobs that finish, sleep or are cancelled before the grace period elapses are never shown, which removes the flicker for refresh, validation and decoration bursts. The grace period defaults to half of getLongOperationTime() with a lower bound of 200ms and can be overridden through the org.eclipse.ui.progress.viewGracePeriod system property. Jobs kept after completion (KEEP_PROPERTY or an error result) are still captured. Fixes eclipse-platform#4126
vogella
force-pushed
the
worktree-progress-grace-period
branch
from
24b81ed to
3528265
Compare
|
Yes, the Platform has contributed M1 so M2 is started and we have some breathing room again. Thanks for asking. Speaking of which, the following issue is why I wanted to complete the Platform target platform removals for M1 because I was pretty sure this problem would happen: eclipse-simrel/simrel.build#1432 Doing this for M1 gives much more runway for projects to address it., so I'm glad about that. |
3 participants
The progress view added a job the moment it was scheduled and removed it when it finished, so jobs that complete within a few hundred milliseconds flashed in and out and could not be read (very noticeable with system jobs enabled).
This adds a per-job grace period before a job is announced to the progress listeners. Jobs that finish, sleep or are cancelled before the grace period elapses are never shown, which removes the flicker for refresh, validation and decoration bursts. The grace period defaults to half of
getLongOperationTime()with a 200ms floor and can be overridden through theorg.eclipse.ui.progress.viewGracePeriodsystem property. Jobs kept after completion (KEEP_PROPERTY or an error result) are still captured, and running jobs remain queryable throughgetJobInfos().Fixes #4126