Community
Participate
Working Groups
I wonder if the fix to bug 44915 introduced a performance regression. I'm using I20040513 GTK and the UI is sluggish in a number of places. The most apparent is when using the "Open Editor Drop Down" command to bring up the list of open editors. 1. Open 5 or so files. 2. Open Editor Drop Down. 3. Move the mouse cursor up and down over the list of editors quickly a few times. Notice that the highlighting of the list elements trails behind the mouse movement significantly. That is, if I move the mouse over the first, then second, then third, etc. editor in the list and then reverse the direction back up to the first editor in the list, the highlight moves from the first to the second to the third, etc., but it lags behind the mouse. This kind of behavior seems suspiciously likely to be a result of queuing UI events, as I understand the fix for 44915 does.
Yes, it does seem very suspicious. Vikki to investigate.
The case listed here is not related to the clipboard fix - gtk_clipboard_wait_for_contents is not running at this time. When the shell with the list of editors is first opened, Shell.setVisible is called which uses the "dispatchEvents" mechanism. However, this completes fairly quickly and the mouse movement response is still sluggish. No "deferredEvents" behaviour is going on while the mouse is moving around and the response is still sluggish.
AbstractTableInformationControl$3mouseMove is the place where the work is being done. It is calling Table.getItem(Point) and Table.setSelection([] TableItem). I think the performance of Table.setSelection(TableItem[]) is slowing this down.
FH changed Table and Tree in this area this recently. Is the new code really slow?
I changed only Tree.getItem(Point) and TreeItem.getBounds(), didn't touch Table.
*** Bug 62290 has been marked as a duplicate of this bug. ***
If we do not use the ON_TOP style for the editor drop down then the selection events seem to be processed speedily. I believe the bug has to do with ON_TOP somehow.
OK, I can reproduce it in cases where the window is not ON_TOP, sorry.
I think Billy is onto something with the ON_TOP. The following code in Display.eventProc is causing the problem: if (control != null ) { shell = control.getShell (); if ((shell.style & SWT.ON_TOP) != 0) { OS.gtk_grab_add (shell.shellHandle); } } Silenio, what problem was the gtk_grab_add addressing? Is there another solution?
SSQ, why did we do this silly grab thing (yes, I do remember that it was my hack)?
If the code is removed, you will not be able to click on ON_TOP shell that is a child of a modal dialog. Window->Preferences->Java->Editor->Templates->New Button->Pattern text-><invoke code assist>
I can still reproduce this problem after removing the call gtk_grab_add()/gtk_grab_remove() in Display.eventProc().
Ok, I don't think the problem has anything to do if the code in Display.eventProc(). Here are two scenarios (both are not affected by the code in eventProc()). 1) As soon as you click the button, start moving the mouse in circles and never stop. The selection will not catch up if the mouse ever. If you stop and let all the outstanding events happen, when you move the mouse again, the selection will follow the mouse properly. 2) Click the button and do not move the mouse, let the popup appear fully (1 or 2 seconds). Move the mouse, the selection willl follow it properly.
More info, if you move the mouse outsize of the popup window and then back, selection will start to follow the mouse properly.
Bug 67458 should be marked as a duplicate of this bug. Silenio and I discovered that mouse move hints are not being correctly handled: the hints slow down mouse events, but report the original positions when it started grabbing events, not the most recent position. The fix is to query the pointer's actual position on a mouse move event if the motion hints are turned on and the Gdk motion event has its hint flag set to true. Using this fix in the Sash code solves bug 54517 about fast view resizing being slow. Using the same logic for mouse motion events in Control.sendMouseEvent fixes this bug about the editor drop down being slow.
We released changes that will fix the slowness resizing fast views. GtkTreeView does not set the pointer motion hint, so it gets all motion events and that is way it is slow. I don't think we should set the motion hint for this widget though, because GTK might not handle that properly, since they do not expect it.
I opened this bug against GtkTreeView: http://bugzilla.gnome.org/show_bug.cgi?id=144729
We should probably just work around this bug in the UI code for now by disabling the selection code on GTK+, since there are no plans to add the motion hint on the tree view upstream (and it would be too dangerous for SWT to set the hint).
I was able to come up with a small GTK+ test case which exhibits the same weird performance problem. Unfortunately, the cause seems to be a complex interaction with the idle handlers for resizing and validating rows in GtkTreeView: http://bugzilla.gnome.org/show_bug.cgi?id=170600 The fix is to run the row validator, but there is no public API to do this and I cannot find any suitable workaround in SWT. While the easier workaround is simply to set the motion hint, which means we don't have to deal with so many mouse events in the first place, this is dangerous, was rejected upstream, and the newly reported bug is really what seems to be causing setting the cursor to be slow in the first place. Even worse, this bug is also machine and GTK+ version dependent. It doesn't happen on Doug's machine (GTK+ 2.6), nor on jrb's machine (also GTK+ 2.6), and for me it happens more easily on GTK+ 2.6 than GTK+ 2.4. Furthermore, the selection is slow in general for me under RHEL3/BlueCurve (GTK+ 2.2), but generally snappy on FC3/BlueCurve (GTK+ 2.4). Given that there is a clear bug in GTK+, this problem is not reproducable everywhere, and there is no good workaround in SWT, I think it is best to close this as WONTFIX. I still think it may be worth changing the UI behaviour, but I will file a new bug for this.
I've had a change of heart and I think I will reopen this bug. It would be nice to figure out why it's slow in general on some machines: under RHEL3 and on my machine at home, it's a lot slower than it should be. Furthermore, the fix in GTK+ is strange, so maybe after it's fixed there we could figure out a stable workaround. Best to leave this open.
Finding out what is really wrong, does not preclude putting in a workaround to fix the appearance in this particular instance. Can something be done about that? Is this a UI problem or an SWT problem?
As a rule we never want to have platform code in UI, but I'm afraid this problem will not get tracked and we will never bring back the feature when GTK does improve. I'm going to remove the feature for GTK only in the UI, and leave this bug open with a reference to it from the code.
That is fine with me.
MVM, did you ever get to this? It makes a big difference on GTK.
Created attachment 20651 [details] attaching some code that I'm experimenting with
I've put a workaround in the UI in HEAD that optimizes the current code to do a lot less work during the mouse moves, and secondly for GTK tries to call setSelection() about %75 less. This seems to work quite well on my Linux machine (which WAS exhibiting the slowness). I'd like to here from Billy if this makes his test machines usable.
As of I20050510-0010, the code in head isn't fixing the problem (I just tried it). Can I give you a demonstration?
yes please
*** Bug 104926 has been marked as a duplicate of this bug. ***
Sigh, I am doomed, never to get this worked around in Eclipse, even though the work around is trivial and the failure makes Eclipse look horrible.
*** Bug 148293 has been marked as a duplicate of this bug. ***
Doomed I tell you, doomed ... R2?
bleep brrrrrrrrr bee-doop.
I've tried for a while to get this worked around in Eclipse and now I'm giving up. Since it has already fixed in newer versions of GTK, I'm going to have to close it as WONTFIX (really, already fixed in GTK).
