Summary: | StyledText should not fill the clipboard on every selection change | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Tom Hofmann <eclipse> |
Component: | SWT | Assignee: | Veronika Irvine <veronika_irvine> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | billy.biggs, daniel_megert |
Version: | 3.1 | Keywords: | performance |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | 92404 | ||
Bug Blocks: | 92209 |
Description
Tom Hofmann
2005-04-21 11:23:41 EDT
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. |