Community
Participate
Working Groups
3.1 stream See bug 92209. Filling the clipboard with the current selection upon every selection change *really* hurts one test case: selecting big editor areas and changing the selection with the arrow keys and holding shift (or selecting large areas with the mouse). Note that this happens on Windows as well as GTK. IMO, copying the entire (almost) document content upon every selection change is way too expensive. Is there a way to avoid this?
I have changed it so that the selection is not calculated for the clipboard unless you are on GTK or MOTIF. This will speed up Windows and Carbon. I am investigating ways to reduce the number of times the selection clipboard is updated on GTK and Motif without losing functionality.
Changed GTK and Motif so that updating the selection clipboard works as follows: Update on MouseUp - that means if the user selects a large amount of text by dragging the mouse, the selection clipboard will only be updated when the mouse is released. Previously, the selection clipboard was updated every time the selection changed which was every time the mouse selected a new bunch of text. Update on KeyUp if the selection has changed since key down, If the user holds the arrow key down and selects a large amount of text, repeated key down events will be sent but only one key up (this is true on most platforms - the only known exception is Linux Motif - the Xserver there sends repeated KeyDown/KeyUp events). This is not the most ideal solution for keyboard selection. However there is no reliable way to know when the user is finished selecting - the Shift Key is one possibility but it is not completely reliable.
Ideally, the Clipboard would provide a lazy mechanism such that ownership of the clipboard would be cheap (and could be done every time the sleection changed) and the data would only be provided at the time when someone pasted the data (or when the application closed). This is not currently supported by SWT and will not make it in for 3.1. It is described in Bug 92404. When such a mechanism is in place, SytledText could be changed to use it.
Cool, though - what you described in comment 2 will get us the largest part of the way (except Motif). I have just added scrolling performance tests that test the scenario you described (KeyDown until scrolling is over, then KeyUp) as opposed to our previous test which would send out zillions of KeyDown/KeyUp pairs. In the new test, you can literally watch the CPU-usage go up as the selection grows bigger - your change will show up immediately as performance improvement once it is in...
Actually it is only Motif on Linux that is a problem. The XServer on most other Unix operating systems only sends the final KeyUp.
Oh yeah, there is one other optimization I added. Other applications only place plain text on the selection clipboard. They do not put RTF text. So I changed StyledText to only put plain text for the selection clipboard and plain text plus RTF text for the regular clipboard. This should save a bunch of conversion work.
Downgrading to normal but leaving open to track using a lazy data collection mechanism.
The original problem is fixed and lazy clipboard is tracked elsewhere. Closing.
