Community
Participate
Working Groups
M20080911-1700 When profiling use of a custom WizardDialog on Linux/GTK, a lot of time was spent in WizardPage.setMessage(...). It turns out that this was because we were setting a message of null after each keypress, and the page's description (DialogPage.getDescription()) was also null. In this case the short-circuit in TitleAreaDialog.setMessage(String, int) fails to notice that the message has not changed, and does a layout every time. For our dialog this takes about 40ms each time, which is noticeable when compounded with other work.
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Good catch. Fixed in HEAD >20090928. I spent some time trying to build an automated regression test for this, but I had trouble demonstrating the problem in a test using public API. There's no hook to count the extra layouts and all the relevant methods in TitleAreaDialog are private, so the test case couldn't hook them to prove that the extra layout computations were happening. You can't count resizes because SWT ultimately decides that no resize is required. I stepped through the code to prove that the fix does indeed short circuit the layout now, so that is going to have to be good enough.
verified on WinXP, Build id: I20091027-0100 through source inspection
