Community
Participate
Working Groups
build R2.1 Every time I type a character all visible squiggly line annotations are rendered. Since the AnnotationPainter already checks whether an annotation is visible it seems reasonable to check whether it is affected by a redraw request. Noticed this while researching bug 32571.
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.
Is this still happening? If so, it sounds like it's worth looking at as a potential source for typing performance problems on platforms with slower painting behavior (e.g. GTK, Mac). If not, PR should be closed.
I agree that this should be fixed. My observations are the following: - On editor activation, for each annotation in the model a single repaint is issued - On every keystroke, for each annotation in the model there are 2 repaints - If the mouse hovers over the annotation and a text hover is displayed, the annotation is repainted even if the hover did not intersect with the annotation at all The situation is even worse after a reconcile pass. The entire set of annotations is exchanged, which issues a second repaint pass. The fix would be to pass not only the GC, but the entire paint event to the AnnotationPainter#handleDrawRequest(GC) method in order to filter annotation repaints which are not inside the repaint region of the event. These observations can be made by instrumenting the handleDrawRequest method
I think this is still happening. Using 3.1. In our HTML editor, there have been bug reports of slow performance for some files, such as bug 71994 (where the person reporting said even basic text editor does not handle his "test file" well). While investigating that, one cause (and frequent "use case") is for HTML files that have no, or few line seperators, so we end up with few lines, but some lines can be 10's of 1000's of characters long. There is an enormous amount of repaints being requested, which for short lines is done quidkly enough its not noticed, but for these very long lines really drags down performance. We have some workarounds in our linestyleevent listener (and quickly handle repeated requests for the exact same info) but not all of the "paint process" is so fast so is still unworkable.
This has been fixed right after M2 - AnnotationPainter now does the following: - the paint region affected by the redraw request is translated into the document region that needs repainting. - any annotations with positions outside that region are not painted. The performance improvements to line-based scrolling (Ctrl+UP/DOWN) is quite obvious on my machine. There are more optimization opportunities remaining: - reconciling in the Java editor exchanges the entire set of annotations, resulting in a huge annotation model change and redrawing all annotations (see comment 3). I filed bug 113238 to track this issue. - we don't use the horizontal clipping information yet. If a line intersects with the clipping region, still all annotations on that (possibly long) line are drawn (comment 4). I filed bug 113241 for this issue. - when pruning annotations, still all annotations have to be iterated to find out their offsets. We should investigate whether the benefits of having a range index on annotations outweighs the cost of maintaining it (bug 113247).
Verified using I20051031-2000
