Community
Participate
Working Groups
When the preferences dialog is resized it takes a too long to re-layout the contents of the page. I know that this a vauge bug report, and I appologize, but the repainting, layout on Eclipse under GTK is really bad and at least one bug needs to address that. This is not a computer speed issue since every other app on the machine resizes quickly.
Which build of 3.0 are you using?
I'm using 3.0M4
This performs fine for me in the 3.0M7 candidate; the only difference I notice from windows is that the widgets are a little more jumpy (ie.- probably more resize event coalescing happening on gtk). Are there any steps that lead to it becoming slow to resize (eg.- showing some particular page(s))? Also, there have been performance enhancements made since 3.0M4, so please try 3.0M7 on your machine and report here if it still seems slow. If it does seem slow then it would also be helpful (if possible) if you could provide some profiling information. If you don't have a profiler available then we can use one here, though its results may not be as helpful since the redrawing seems fine.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
In its current form, this PR is not very useful. Need to identify if there is still work to be done here, and if so, is it for the UI team (i.e. in the preference dialog code) or the SWT team.
This is still an issue on my laptop on GTK. STEPS 1) Open the preferences dialog to the Java Formatter page 2) Resize - there is a noticable lag in painting
Tod, the behaviour you are seeing is because you are using GTK+ 2.2.4 (RHEL3). GTK+ deferrs resizing to the idle loop, and so the window will not update until you stop moving your mouse. This is reproducable also using gedit. Note that the resizing responsiveness changes in GTK+ version 2.4 and higher. The code formatting preference page resizes smoothly for me under GTK+ 2.4.13. Given that this bug report is rather abstract, and that there are behaviour differences in GTK+ version that can account for the described behaviour, I am going to close this as WONTFIX. I do believe that resizing performance is something worth measuring, but it is better done first by getting some numbers from the UI performance tests.
