Community
Participate
Working Groups
20030611 scrolling in the java editor is a couple of times slower on gtk than on windows which make the ide seem unresponsive major for me - i get annoyed by it every time (i switched to linux recently)
Steps to reproduce: In Eclipse, open a fairly large java file and scroll. If you have the SWT source in your eclipse workspace, an example of a large file is StyledText.java.
VI to confirm that this doesn't happen in a plain StyledText that has the same amount of text and then move this PR to UI.
if it were UI, then wouldn't we see the slowness everywhere, not just gtk? i couldn't get my profiler to work on linux, if you have one that works i can take some performance traces
Same here, I mean that gtk version on linux is very slow without > 512M RAM. If you look on the forum you'll see that many people are in this situation. I'm glad that somebody open a defect regarding this issue. The gtk version is very slow compared to the win32 version, not only at scrolling large files, but this I guess is the most visible aspect. From what I see there is no improvement in the latest versions.(3.0-M2)
*** Bug 46038 has been marked as a duplicate of this bug. ***
Please, retested this using the latest integration build, a lot of code has changed since this bug was opened.
This still occurs in 3.0. One way the behaviour could be improved without actually improving painting performance is to avoid a paint for each keystroke when scrolling. Currently, if you press and hold UP, the editor will go through painting at each line position instead of skipping a few. The current sequence of events (keep in mind that the key events come very quickly, 50 times a second on my setup): * Actual UP key pressed (on the keyboard) * Process key event * Scroll one line up * Paint * Process key event * Scroll one line up * Paint * ... (last 3 steps repeated many times) * Actual UP key released (SWT still has queued key events) * Process key event * Scroll one line up (bad - the component keeps scrolling with no keys pressed). * Paint * ... (last 3 steps repeated many times) * The event queue is finally empty and the scrolling stops. The desired sequence: * Actual UP key pressed (on the keyboard) * Process key event * Scroll one line up (and schedule an asynchronous repaint) * Process key event * Scroll one line up (and schedule an asynchronous repaint, coalesced with the last one) * Process key event * Scroll one line up (and schedule an asynchronous repaint, coalesced with the last one) * Paint * Process key event * Scroll one line up (and schedule an asynchronous repaint) * ... (repeating) * * Actual UP key released (Since SWT has been processing the key events very quickly, the queue is empty) * Scrolling stops.
Thanks for posting the steps, especially the part about the keyboard repeat rate. I was able to reproduce this problem by increasing the keyboard key repeat rate up, but I had to set it pretty high in order to see the effect. The default keyboard repeat rate (at least under GNOME/RH9) was too slow to exhibit the problem on my setup: scrolling never lagged behind the cursor. Comparing with other editors on Linux, gedit and kate (even with syntax highlighting) are both much faster than scrolling a large file (WorkbenchPage.java) in the text editor on Eclipse (no syntax highlighting or code folding). Furthermore, they don't seem to skip lines, so I think there may be a more fundamental problem here.
Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug.
Felipe, Can you profile this and see if there is any performance improvement that can be made for 3.1?
Felipe, did you get a chance to profile this yet?
FWIW, scrolling in *Plain-Text* editor on *Linux-GTK* is fast. I see no slowness there. I have a file of 38010477 bytes, or 67770 lines. Opening could be faster maybe, but scrolling is good (using either the wheel or pgup/pgdown or the scrollbar).
Billy is trying to improve the performace on Control.update() and/or Canvas.scroll(). These function are used when the StyledText scrolls: it updates area (make sure there is no outstanding paints), copy area, repaint the bottom (or top) line. Other areas we can look at is improve the time to initialize and paint a line, improve the time to measure and place the caret. We already did a lot of work in these areas and right now mostly of the time is spent in update/scroll area.
StyledText has frameworks to do all kinds of work, action like line down, page down, etc are all implemented using this framework. The framework calls the same call multiple times. For example, for each line down it will call getClientArea() 3 times and getTextLayout() 5 times. It also does all kinds of unnecessary work and checks that would not be required during a line down. So I reimplemented the action line down w/o using the framework (being as straightforward as possible), avoiding all unnecessary calls that the framework does. But it didn't improve the time at all (scroll line down 1800 times in a file of 2000 unstyled lines). Turns out getClientArea() and getTextLayout() are very fast, the framework doesn't really affect performance. Actually, roughly 11 sec out of 13 sec it took to run the test was used by Control#update(). I'm attempted to close this PR as duplicate of Bug 79894.
I have the same problem, on Windows, with Eclipse 3.3M6. None of the other developers I work with have the problem. When I press up, down, left or right arrow, it is slow - specifically, when I hold the key down to move to a specific line, area, etc. The CPU goes up to 100% if I move for about 10 lines up or down. My keyboard settings are at the max speed and repeat rate. This never occurred on 3.2.1 and 3.3M5.
Just wanted to signify that the problem I was having with 3.3M6 which was a very slow refresh rate when scrolling and very slow cursor movement from left to right is now resolved since I downloaded and installed 3.3M7.
closing. We have improved scrolling speed for GTK as much as we can.
