Community
Participate
Working Groups
Using Eclipse 3.2 AnnotationPainter#computeClippingRegion is supposed to compute the document region covered by a paint event's clipping region. If the paint event's clipping region is not a valid document region, then the entire document region is returned as the clipping region. You get invalid document regions when the editor is horizontally scrolled over a little (like putting your cursor at the end of a really long line and then scrolling up and down) Instead of returning the entire document region, only the visible document region should be returned because at most, only the annotations in the visible region should be redrawn. This is what happens when paint event == null. try { int widgetClippingStartOffset= fTextWidget.getOffsetAtLocation(new Point(0, event.y)); ... } catch (IllegalArgumentException x) { // should not happen ==>// widgetOffset= 0; // use entire viewport, not entire document (no need to redraw nonvisible areas) ==> widgetOffset = getInclusiveTopIndexStartOffset(); } int widgetEndOffset; try { int widgetClippingEndOffset= fTextWidget.getOffsetAtLocation(new Point(0, event.y + event.height)); ... } catch (IllegalArgumentException x) { // happens if the editor is not "full", eg. the last line of the document is visible in the editor // in that case, simply use the last character ==>// widgetEndOffset= fTextWidget.getCharCount(); // use entire viewport, not entire document (no need to redraw nonvisible areas) widgetEndOffset = getExclusiveBottomIndexEndOffset(); } I ran into this when trying to fix slow scrolling in editor for WTP (bug 149828) There should be some slow scrolling with the Java editor as well (though maybe not as visible)
Created attachment 52277 [details] org.eclipse.jface.text.patch Patch to fix AnnotationPainter#computeClippingRegion() as illustrated above (see ==> lines)
I should note the patch is based on the jface.text code in the R3_2_maintenance branch. Also, this bug is somewhat considered one step closer to fixing bug 113241 (optimize annotation painting by taking into account horizontal scrolling)
Thanks Amy.
I did a quick manual patch of the Eclipse 3.2.1 AnnotationPainter to add computeClippingRegion/getModelRange and then updated my jface.text jar. Scrolling now has no noticeable hesitation with the patched code. Thanks for finding a fix so quickly.
*** Bug 162592 has been marked as a duplicate of this bug. ***
Fixed in HEAD. The benefit of this patch is high. I'll also released it into 3.2.2.
While the fix looks good it does not work :-( Test Case: 1. enable folding 2. open a CU 3. collapse all (Ctrl+Shift+Numpad_Divide) ==> projection annotations aren't painted. I'll have to check why that happens.
I see: the code mangles model and widget coordinates.
I've fixed this in HEAD along with a major rework on how annotations using a drawing strategy are handled in order to improve the performance. For a test case see bug 153025. Amy, please check whether this fix gives you the same performance benefit as your original patch. In 3.2.2 I will only released the fixed patch and not the other performance changes because they are pretty radical.
Actually I prefer to leave the 3.2.2 stream code like it was in the 3.2.1 to reduce any risk of breaking a client at this point.
Scrolling looks good to me.
Verified using I20061212-0010.
There was another report of pretty poor performance due to this. I crafted a minimal patch for 3.2.2 similar to Amy's patch but using correct coordinates. This new patch was already tested by the reporter of bug 166035 (see that bug for the patch) and showed good results. I will therefore release it into R3_2_maintenance.
Committed and released into R3_2_maintenance.
Verified in M20070112-1200 by code inspection and by setting an empty spelling dictionary and trying to scroll AbstractTextEditor horizontally.
