Summary: | Interactive text selection lags on Linux-GTK+ | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Billy Biggs <billy.biggs> |
Component: | SWT | Assignee: | Billy Biggs <billy.biggs> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | ben, Mike_Wilson, mlists, veronika_irvine |
Version: | 3.1 | Keywords: | performance |
Target Milestone: | 3.1 M7 | ||
Hardware: | PC | ||
OS: | Linux-GTK | ||
Whiteboard: |
Description
Billy Biggs
2004-12-11 14:30:45 EST
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. |