Community
Participate
Working Groups
Why is ProgressbarDialog so noticably slower on OSX and slightly slower on Linux compared to Windows ? After some testing I created https://github.com/maxandersen/broken-progressbar Which is nothing but the jface ProgressDialog example modified to use setTaskName. Here are three videos showing the difference across the platform: OSX: 50 seconds - http://screencast.com/t/DhqW9lU3md5 Linux: a few seconds - http://youtu.be/J35JJOcxYWw Windows: Almost instant - http://screencast.com/t/0IHIxx6MrQUv Also notice that Cancel does not work - it as if the event for cancel is never registered. This means we simply can't use progressdialogbar for telling the user what is going on in i.e. a copy operation what files are being copied since it simply blocks OSX UI. This is reproducible on several years of eclipse releases so its not a new issue, but finally got around to reduce it to the simplest testcase. Any idea ?
Created attachment 242193 [details] YourKit trace report I traced this under YourKit and have attached the call time report on setTaskName(). The problem seems to be something to do with the Cocoa and Label's implementation.
What is weird is subTask() also uses a label afaik and that is not slowing things down at all.
I should have done more digging. The problem is ProgressMonitorDialog/AccumulatingProgressMonitor. PMD uses a JFace AccumulatingProgressMonitor to accumulate changes so as to avoid bombarding SWT with label & progress bar changes (while an asyncExec is pending, it just updates its internal values). APM doesn't accumulate task-name changes and instead causes those to be pushed out directly to SWT. So every task-name change is being blasted out. Typically callers aren't expected to call setTaskName() and just use subTask() instead. So Max's code is unusual. My guess is that Label's implementation on OSX and GTK requires calling back into SWT, whereas it's immediate on Windows.
Now that I think about it, I've hit this problem previously too. It's easy to accumulate the task-name too, so I pushed a fix to: https://git.eclipse.org/r/25370
Committed as: https://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=137422974418e2e46577cdd103448072d3952a23
Awesome work Brian!!
Awesome! Just to explain why we use settaskname: We did use subtask more in past but: A) wtp progressmonitors often swallowed it B) the text gets appended so you can't actually read/see the progress so this solution is much much better! Thanks!
Verified with broken-progressbar test program against I20140428-2000.
This causes NPEs, see bug 436328.
And another regression: bug 436356.
I'll put up a patch in 15 mins
Regression tracked in bug 436358
