Bugzilla – Full Text Bug Listing
|
Description
Michael Arnold
Adding Alexander in c/c as he might be interested. This problem also exists in Fedora 25, that uses wayland by default. I see this too with Eclipse Neon running with Wayland but not Xserver; I can add that the actual text insertion point (line:column) indicator at the bottom of the Eclipse window updates correctly with each press of the <Left-arrow> or <Right-arrow> keys, but the -displayed- position of the cursor does not. For example if you position the cursor somewhere in the text with a click of the trackpad button, then press <Right-arrow> twice, the cursor does not move on screen but the column indicator correctly increments by 2. If you then type some character keys, the characters will be inserted into the text at the correct position according to the insertion location indicator - but not according to the displayed position of the cursor which is still two character widths to the left. This looks more like an SWT issue as this is reproducable in Snippet 222. Moving to SWT. New Gerrit change created: https://git.eclipse.org/r/89546 Ian, if adding redraw() into ShowCaret() is not a good way to fix this issue, is there a preferred solution vector? (In reply to Michael Arnold from comment #6) > Ian, if adding redraw() into ShowCaret() is not a good way to fix this > issue, is there a preferred solution vector? Hey Michael, Im currently still investigating the issue now. It looks like the reason behind this is that we are drawing the caret through a Cairo call that grabs the context outside of a draw signal. This is actually not supported in GTK for wayland so I am seeing if i can do a low invasive fix before I fall back to the redraw. New Gerrit change created: https://git.eclipse.org/r/90975 Created attachment 266797 [details]
Modified snippet222 to display time mesaurements old vs new
Attached is a modified snippet222 that will display how long it takes to run a setCaretOffset about 10000 times. Testing both prior and post patch (on both wayland and X11), it seems to average around ~700 milliseconds to finish the process. There is no big difference in timing moving to the new patch, as I believe the only margin of error causing the timing differences is the priority of the process for the OS.
Gerrit change https://git.eclipse.org/r/90975 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=34e1c1ed3a200da94dc833627f60ed56dc75b362 Also fixes a nasty issue on X11 where stale cursor stays drawn while the new one moves. Thanks for the patch. In master now. New Gerrit change created: https://git.eclipse.org/r/91117 Gerrit change https://git.eclipse.org/r/91117 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3ead1bbd14e89294aeaba6f0e1b7ce8f0e2b1522 Ian, please test with Snippet43. With your patch the caret no longer blink. New Gerrit change created: https://git.eclipse.org/r/91218 Gerrit change https://git.eclipse.org/r/91218 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=b3374a13114f858a723270acab708020b66f5103 In master now. It even draws better with the snippet than the old code where there were leftovers when the caret should have been hidden. New Gerrit change created: https://git.eclipse.org/r/91413 Was running the integration build and found a race condition where if you held down an arrow key, isDrawing is being fought over by the blinking procedure and the drawCaret call. Removed it and is now fixed as it was not necessary to have in the first place. Gerrit change https://git.eclipse.org/r/91413 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=a6faa38b93f4cb00168ac8f1755dfe0662f7e03c Awesome - thank-you! *** Bug 422969 has been marked as a duplicate of this bug. *** |