Community
Participate
Working Groups
The highlighted text selection in the Eclipse editor often lags behind my mouse on my P3-733. If I rapidly select some text in the editor, the caret seems to follow directly with my mouse movements, while the highlight block trails behind. Since the caret can keep up, the problem does not seem to be with the event propagation or mouse motion hints. The responsiveness can be improved by flushing GTK+'s outstanding repaints after processing each mouse event. StyledText handles mouse move events by calling Control.redraw() for each line of text that has changed. This uses gdk_window_invalidate_rect() to invalidate the region internally in GTK+. This will not generate an expose event until the GTK+ event loop goes idle. The following patch in StyledText.handleMouseMove() improves the situation on my machine. Note that update() also flushes any expose events from the X server, which is not necessary in this case since all of the invalidations are done internally using gdk_window_invalidate_rect(). However, since this operation is interactive, I am not sure this really matters. Index: Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/StyledText.java =================================================================== RCS file: /home/eclipse/org.eclipse.swt/Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/StyledText.java,v retrieving revision 1.235 diff -u -r1.235 StyledText.java --- Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/StyledText.java 23 Nov 2004 22:38:23 -0000 1.235 +++ Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/StyledText.java 11 Dec 2004 19:26:38 -0000 @@ -5063,6 +5063,7 @@ } event.y -= topMargin; doMouseLocationChange(event.x, event.y, true); + update(); doAutoScroll(event); } /**
Here is the test application I used to experiment with. public class StyledTextSpeed { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); shell.setLayout(new FillLayout()); StyledText s = new StyledText(shell, SWT.FULL_SELECTION | SWT.H_SCROLL |SWT.V_SCROLL); s.setFont(new Font(display, "Monospace", 10, SWT.NONE)); String mytext = new String(); int i, n = 256, rows; for(i = 0; i < n; i++) { for(int j = 0; j < 72; j++) { mytext += (j % 10); } mytext += "\n"; } s.setText(mytext); shell.setSize(800,600); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
BB to follow up with Vikki. The last I knew about this was that we couldn't see any improvement on fast machines and we were stalled finding a slow machine so that we could see the difference before introducing a dreaded call to update().
Is this still a problem? Have changes been made elsewhere that improve the situation? Does making this change actually help? (Note: I have a 933 with 512Meg of RAM in my office. It currently runs windows, but you can take it and install linux if you need this for testing.) Forcing paint for immediate update of a selection range seems like reasonable behavior from a responsiveness p.o.v. anyway. Are there hidden costs?
Fixed > 20050422 Lately there have been more arguments in favour of putting it in than keeping it out, so I have just released the change.
