Community
Participate
Working Groups
N20050623-0010-gtk Not sure whether this is my particular install or a new problem. With the above build, cursor navigation in any text field is extremely slow. Steps: - open the Find dialog (alternatively: open the preference dialog, or the Team>Create Patch wizard) - in a text field, enter some text, at least 20 characters - press and hold the ARROW_LEFT / _RIGHT keys Expected: I see the caret move through the entered text Actual: The cursor does not visibly change its position until after releasing the key plug some delay. Notes: - keyboard repeat rate is at the default - the same works fine (+/- at least nowhere near the slowness of Text fields) in text editors - other applications do not show this behavior This is quite bad as the caret cannot be placed reliably this way. Will try to reproduce with an SWT-only example.
Hm - probably not SWT related. I only see the behavior in my development workbench, not the target.
Has nothing to do with SWT - I can only reproduce while either a file is open in a Java editor or while in the Java perspective. When in the resource perspective and only text editors open, cursor navigation is fast as expected. I assume there is a listener somehwhere that causes this.
Tom, if this has nothing to do with SWT, is this bug report mis-filed?
I profiled the following scenario: - Java editor - press Ctrl+F to open the find dialog - enter "foo bar foo" - put caret to the end of the text - press and hold ARROW_LEFT Profiling reveals the following: - Of ~1526ms spent in Display.readAndDispatch, 1486ms are burnt in ContextAuthority.sourceChanged. I suspect that either: - SWT does not filter events as it should, or - UI registers a listener where it should not
(In reply to comment #3) > Tom, if this has nothing to do with SWT, is this bug report mis-filed? It might be - see comment 2. Will move as soon as I have traced the cause, ok?
I have reason to believe, perhaps prematurely, that this is the result of a change made about a month ago to how contexts work.
(In reply to comment #4) > - Of ~1526ms spent in Display.readAndDispatch, 1486ms are burnt in > ContextAuthority.sourceChanged. ... which is called by the GTK-only ContextService.updateShellKludge (see bug 95792). This explains why this is not reprducable on the other platforms.
Created attachment 23850 [details] updateShellKludge.zip Html yourkit trace of the children of ContextServie.updateShellKludge. The context seems to be reloaded and the all menus rebuilt on every keystroke.
Verified that this appeared between M7, which still worked as expected, and RC1.
Created attachment 23868 [details] Patch to "org.eclipse.ui.workbench" This problem traces its history back to Bug 56231, and its reincarnation as Bug 95222. Unfortunately, when porting the kludge for 56231, I seem to have missed a key point: the forced update should only happen if the shell has really changed. This fix simply does a test to see if the shell has really changed.
Created attachment 23869 [details] Patch to "org.eclipse.ui.workbench" This extends the fix to include the handlers as well. I would like to recommend this fix for 3.1.1. Changing it at this point is too risky for the 3.1. It has the possibility of making key bindings stop working on GTK+. If key bindings stop working due to some side effect of this bug, then I would expect that they can be made to work again by switching to another application and back again. Leaving this problem in causes a performance hit for typing on GTK+.
Since typing in the editor itself and working with code assist is not affected I agree with Doug's assessment to defer this to 3.1.1.
I've seen the bug and I think it is a P2, doug if you disagree let me know
MVM: Approval for 3.1.1?
Patch applied to head in the 3.2 stream. Waiting for approval to commit a fix to the 3.1.1 stream....
approve for 3.1.1
Fixed in CVS on the maintenance stream. org.eclipse.ui.workbench branched, and plug-in version number updated.
*** Bug 104205 has been marked as a duplicate of this bug. ***
Verified in M20050727-1200-gtk
Verified in 3.1.1 RC2 and 3.2. GTK+ 2.6.8.
