Community
Participate
Working Groups
Eclipse 20021113 Platforms: linux gtk & motif Open any class, WelcomeEditorCopyAction, only 31 lines, yet larger than my editor area. Now comment out the public method run(). Notice the quick flash to the top of the file. Repeat the same test with a larger class, WelomeEditor (860 lines). Comment out the last method, same flash.
Grant to investigate and advise (Grant: since you've been keeping an eye on performance issue on Motif and Linux in general, can you comment on this?)
The problem is that Control.setRedraw(boolean) is not implemented, because X does not support this. Therefore redrawing of the editor is not successfully turned off. Perhaps we can fake it somehow.
*** Bug 44691 has been marked as a duplicate of this bug. ***
This bug was not visible for me until the 3.0M4 release, see my duplicate Bug 44691. 3.0M3 worked brilliantly. This is a major showstopper for me on Linux to work with the 3.0Mx builds. You should post an epilepsia warning on the Linux builds until this is fixed!! Please give this bug some attention!
*** Bug 46627 has been marked as a duplicate of this bug. ***
*** Bug 18955 has been marked as a duplicate of this bug. ***
Created attachment 7571 [details] Patch providing redraw request queue in Control I'm not sure if this is what people are looking for, but it provides a noticeable effect on my machine. A particular test case is to open a menu, and then move the mouse left and right quickly. Before the patch, you should be able to see redraw flickers as the menu disappears and reappears. After the patch, the flickering is gone. What this does is create a queue of redraw requests in Control when redraw=false. This means that all redrawWidget() invocations just add to the queue. Eventually, when redraw is set back to true, the redraw requests are replayed in order. A further optimization would be to merge the pending redraws into one dirty region before posting the redraw request to X/GTK. This would probably give a performance benefit, but it depends how X-intensive GdkRectangle queries are. Again, I'm not sure if this is what people are looking for, but I hope it helps.
Following up bug 52899, Steve has fixed StyledText to not flash any longer upon calling setText. This works fine so far (N20040308): the editor area (canvas) does not flash any more at all - the (native) scrollbar thumb still jumps to the top and back quickly, though barely noticeable on a fast machine.
Tom, The scrollbar behaviour may have something to do with this issue we were looking at: http://bugzilla.gnome.org/show_bug.cgi?id=137713 I don't think it's right that the function does that, but I'm also unconvinced that SWT needs to call gtk_adjustment_value_changed() so much.
With M8, the flash fixed by bug 52899 is back!
*** This bug has been marked as a duplicate of 53791 ***
*** Bug 121140 has been marked as a duplicate of this bug. ***
