Community
Participate
Working Groups
Steps to reproduce: * open a project (I tried with a big one); * open 10 java editors; * maximize one by double clicking on the tab header * see that the tabs redraw is late compared to the editor (0.5 secs); * unmaximize it by double clicking again; * again, the editor redraws almost immediately, but the tabs and the tree take quite sometime (again, 0.5 secs) The proof of the slowness is on the attached screenshots (you can't take them on a system that redraws fast, but the delay is long enough that I got them at first tentative). This happens on Linux Mandrake 10.0 on a Ahtlon 2600+, Radeon 9200, using ATI binary drivers, Eclipse 3.0 M9 and R21 theme.
Created attachment 11451 [details] First image, before maximizing
Created attachment 11452 [details] Second image, during maximization (half drawn window)
Created attachment 11453 [details] Third image, maximized state
Created attachment 11454 [details] Fourth image, during un-maximization (an eventual fifth image would be equal to the first)
Additional consideration: the default presentation is definitely faster, I can see it redraw the window but I can't take a screenshot for the un-maximizing action, whilst for the maximizing editor action it's still slow enough to allow me to take a screenshot without the tabs drawn (coming).
Created attachment 11456 [details] Maximizing the default presentation mode, still too slow
I can reproduce this problem here. The problem seems specific to maximizing editors. If I maximize a large number of views, I do not see the same slowness to redraw the tab area. It may be that some events are being sent before the paint occurs. I will look at this case in a profiler.
This could lead down other paths of where we are inefficient when updating editors as well.
Just as a note, the time to redisplay the tabs becomes untolerable with the default theme too as the number of opened editors increases... I just had 22 editors opened and the time to see the tabs displayed after an editor maximization was around 1 second...
When many editors are open and active, a StyledText widget for each one is visible but obscured by other windows. During maximization, all of them are receiving paint events on Linux/Gtk+, instead of just the topmost one. Even though the paint events don't do anything visible, they seem to cause a lot of work to happen. This is not reproducable on Windows or Motif. The paint events are from gdk, which seems to aggressively invalidate newly exposed portions of windows when their size or clip rectangle changes. This happens not only during maximization, but also on layout changes or resizes of the main eclipse window. However, only the maximization case seems to reproduce this reliably: in some cases when resizing or changing the layout I only get expose events for the topmost editor. The following patch to gdk solves the maximization problem, but I do not know what side effects it has. I am reassigning this bug to SWT to get their opinion. Index: gdk/x11/gdkgeometry-x11.c =================================================================== RCS file: /cvs/gnome/gtk+/gdk/x11/gdkgeometry-x11.c,v retrieving revision 1.22 diff -p -u -r1.22 gdkgeometry-x11.c --- a/gdk/x11/gdkgeometry-x11.c 10 May 2004 20:51:19 -0000 1.22 +++ b/gdk/x11/gdkgeometry-x11.c 8 Jun 2004 18:13:31 -0000 @@ -1146,7 +1146,10 @@ gdk_window_clip_changed (GdkWindow *wind if (!gdk_region_empty (new_clip_region)) { gdk_window_tmp_unset_bg (window); - gdk_window_invalidate_region (window, new_clip_region, FALSE); + /* + * Is this invalidate unnecessary? + * gdk_window_invalidate_region (window, new_clip_region, FALSE); + */ } gdk_region_destroy (new_clip_region);
Billy to investigate. It might be that GTK is issuing internal paints (ie not X window exposes) for obscured regions. One of SWT, GTK or Eclipse could be causing the extra redraws that get thrown away on Windows. Billy, can you (quickly) confirm that the extra paints are not happening on Motif. That might help us isolate what is happening. NOTE: This is an area with a huge potential to improve performance. I am considering marking it P1.
I think the following code shows the problem. This creates two composites with the same size. The test is then to resize the window. On Motif, paint events are only sent to the composite in front. On Gtk+, they seem to be sent to both children. public class SimpleGuy { public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(display); shell.setText("Two Paints?"); final Composite child1 = new Composite(shell, SWT.NONE); final Composite child2 = new Composite(shell, SWT.NONE); child1.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { System.out.println("child1 got a paint event: " + event); } }); child2.addListener(SWT.Paint, new Listener() { public void handleEvent(Event event) { System.out.println("child2 got a paint event: " + event); } }); shell.addListener(SWT.Resize, new Listener() { public void handleEvent(Event event) { child1.setBounds(shell.getClientArea()); child2.setBounds(shell.getClientArea()); } }); shell.open(); while( !shell.isDisposed() ) { if( !display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Fixed > 20040608. Obscured widgets no longer receive exposes. This is really a problem in GTK that we are working around.
I opened this Gtk+ bug to track the issue: http://bugzilla.gnome.org/show_bug.cgi?id=144030
Nice, the performance is visibly better now... still, it's not as fast as a native app nor as a Swing app... but you're improving :-)
Andrea, please continue to file bugs when you discover areas where Eclipse is slow on your system.
The fix for this problem has been removed from RC2, because it causes too many painting problems (see bug#66293 and bug#66633). I try again after RC2.
I see the problems... then again, the slowness problem is so evident that I will be forced to stay with 2.1.3 (or to switch to Windows, or go back to Netbeans... but I don't like any of the options...)...
The fix for this bug has been released to HEAD again. The bug#66633 is also fixed in HEAD. I will attach a patch and jars that can be applied in RC2. Please run with the patch and let me know if you see any painting problems. This fix improves performance quite a bit, but it will not be released in RC3 if it causes problems that cannot be fixed easily.
Created attachment 12066 [details] Patch for RC2
Created attachment 12071 [details] SWT jar for RC2
Created attachment 12073 [details] SWT-PI jar for RC2 Note that both jars have to be replaced.
KH approve
Silenio, just tried it out, and seems to work fine except for the status bar... which does not repaint properly when resizing the window, and also the tasks/javadoc/... tabs does not repaint properly when resizing the window, but only if they are minimized (see second screenshot). For the rest, it seems it works fine :-) I hope you can solve the problem without reverting the patch ;-)
Created attachment 12076 [details] Unproperly repainted status bar
Created attachment 12077 [details] Status bar and minimized tabs missing
Oh, by the way: to reproduce this I simply have to reduce the size of the window by dragging its border. Then I can also maximize/unmaximize to get the same result. Covering Eclipse with another window and then minimizing the latter makes it repaint properly.
I've replaced both jar files provided here in my Eclipse RC2 installation and Eclipse fails to start with the following error message: An error has occurred. See the log file "/home/ijuma82/bin/eclipseRC2/configuration/1087241244224.log" I'm using Fedora Core 2 with GTK+ 2.4.1 and J2SE 1.4.2_04. Is there anything else that I have to besides replacing both files? I will also attach my log file as it might provide some useful information.
Created attachment 12078 [details] .log file created after eclipse fails to start
The patch is broken. We are working on it...
Created attachment 12093 [details] Patch to the previous patch Here is a patch which will solve the problems when used in addition to the previous patch. This patch should fix any redrawing problems, but may lose some of the speed advantage from the original. I will post a new swt.jar file for RC2 which must be used along with the previously posted swt-pi.jar file. Please post the results of using these jar files.
Created attachment 12094 [details] New swt.jar file
Ismael, I think you just had a bad download. Try using a different browser, or maybe wget, to download the jar files. Also, check the permissions on the files.
Ok, this one works but... hum... is it just me or it feels just like plain RC2?
With my new jar, the code from comment #12 seems to not exhibit the problem of getting multiple exposes, so I think there should be some difference. Can you describe what are you seeing?
What I'm seeing is that it takes visibly more time to repaint the tab bar on maximize/unmaximize than the previous patch. Yet your last one does behave well when resizing the window, so I'd say your patch provides the correct behaviour, at the cost of a lower performance (visibly lower)
From the initial testing, the new patch doesn't seem to exhibit any problems. Regarding the improved performance, it seems to be slightly faster, but then again in my system (P4M 1.9 with 640 MB RAM), I can get screenshots similar to #2 in an unpatched RC2, with the first (broken) patch, and with the latest one. Hopefully, small improvements like this will add up and by the time Eclipse is released, it will be more responsive. I'd like to point out that I do not consider its performance to be _that_ bad (in Linux) considering all the functionality it provides. Keep up the good work :) P.S. The initial problem I experienced was caused by Firefox not downloading the full files for some reason (wget worked fine).
Yes, I can confirm that even with the first patch I can take again a screenshot like the second one... it may be just my wrong guess, but it seems that considerable time is spent while re-layouting components, and that during this re-layout unnecessary erase and redraw cycles are performed.
This patch is going to be released in RC3. Fixed > 20040615. If you have many editors opened (my testcase has 40), maximazing/unmaximazing is visibilizy faster (around 2x). Resize the window is also faster. This is not so evident if only a if widgets are obscured.
Silenio, it's really nice that there is a speed improvement. But, at the same time, the report in itself is still valid, to make the redraw invisible a 10x improvement is needed. Please, don't misunderstand, I really appreciate the work, but the problem is still there (althought it's a smaller one). Maybe you can work further on this for 3.0.1 or 3.1?
To be clear: The problem is in GTK. When a control is obscured, it process paints when resized (and at other times). This is not true on Windows, X/Motif or the Mac. When there are many editors stacked on top of one another (for example, many open editors), GTK asks us to paint obscured controls. The fix/hack is to throw away paint requests from GTK. A GTK C program would have exactly the same behavior and would need to be optimized in the same way.
Changing the title to reflect what actually happened. The problem that Andrea is still happening but this fix made it a bit better. Andrea, please open a new bug report for the original problem. We were using this one to track the GTK problem for RC3 and need it to remain closed. Sorry and keep these great reports coming!
