#1604 Drawing of indicators broken in 3.4.2

Bug
closed-fixed
Neil Hodgson
5
2014-07-04
2014-05-26
Markus Nißl
No

In 3.4.1, drawing indicators was correctly done when calling SCI_SETINDICATORCURRENT and SCI_INDICATORCLEARRANGE.

After upgrading to 3.4.2, some indicators are still shown although "clear range" was called. Scrolling or displaying a tooltip makes the indicators being drawn correctly.

Discussion

  • Neil Hodgson
    Neil Hodgson
    2014-05-26

    • labels: --> scintilla, indicators
    • status: open --> open-works-for-me
    • assigned_to: Neil Hodgson
     
  • Neil Hodgson
    Neil Hodgson
    2014-05-26

    I haven't been able to reproduce the indicated problem. There are also no changes between 3.4.1 and 3.4.2 that look likely to impact this area.

    Perhaps you could narrow the problem down to a particular revision by using Mercurial to choose individual revisions then building and checking them. Perform a binary search over the revision history. There are around 70 revisions between releases so it should only take 7 tests.

     
  • Markus Nißl
    Markus Nißl
    2014-05-27

    We found out that the bug was introduced with revision 5053:31871037ed1f

     
    • Neil Hodgson
      Neil Hodgson
      2014-05-28

      The method changed in this revision, RectangleFromRange, does define the area to be redrawn when indicators change so could lead to an area not being redrawn. However, I'm having a lot of trouble seeing how this revision could change the behaviour in the way described. The change here is to clip the top and right sides of the redraw rectangle to the rectangle returned from GetClientDrawingRectangle instead of GetTextRectangle.

      GetClientDrawingRectangle differs significantly only on Cocoa where it has to handle drawing areas that are not currently visible. On Windows, it should return the same rectangle as GetTextRectangle except that the left and right sides haven't been moved in to allow for margins. Only the right side is subsequently used and it will differ from GetTextRectangle by vs.rightMarginWidth which is normally only a single pixel. Anyway, the result would be that RectangleFromRange causes a redraw for an area that is 1 pixel wider than before so any indicators redrawn before will still be redrawn after this revision.

      I still haven't managed to reproduce the problem.

       
      • Markus Nißl
        Markus Nißl
        2014-05-28

        I can follow your reasoning -- it makes sense what you say. It did introduce the bug, though.

        In order to give you a better understanding, we did a screen capture. The video is attached to this post.

        In this example, we use indicators to highlight block starts and ends. When the caret is on a block keyword (if, else, end), the corresponding keywords are highlighted. As you see, when another block is selected, the previous indicators are still visible (except the one where the caret was last on).

        When hovering over a variable, a tooltip is displayed which causes a redraw, so all indicators are correctly drawn again.

        We set/clear the indicators in SCN_UPDATEUI.

        Hope this helps!

         
        Attachments
        • Neil Hodgson
          Neil Hodgson
          2014-05-28

          In the video, fold highlighting is also changing the lines that are seeing the indicator fail to clear. There could be an interaction here and this could be checked by turning off fold highlighting.

          Another thing to check is whether the right margin change is the cause by subtracting vs.rightMarginWidth from rc.right in RectangleFromRange.

          Creating a small self-contained application that reliably demonstrates the issue would allow me to debug further.

          There is a possibility here that the problem is inverted: your highlights should not have been visible before but were fortuitously made visible by another element updating. However, the clearing of the highlights is very similar to SciTE's highlight current word function which clears the highlights inside SCN_UPDATEUI but then waits for half a second before adding the new highlights.

           
          • Markus Nißl
            Markus Nißl
            2014-05-30

            Turning off fold highlighting makes the indicators being drawn correctly.

             
  • Neil Hodgson
    Neil Hodgson
    2014-06-01

    Potential fix in [23f89a]. The change to RectangleFromRange may be increasing the size of a redraw so that its bounding rectangle covers the entire client area. This then invokes an optimization in painting that will not test new area invalidations closely. However, when fold highlighting is on, the paint area is a complex shape with holes like a sideways 'T'. When the changes to indicators are in the holes, they are not painted but also are not seen as outside the paint area so do not trigger a complete redraw.

     

    Related

    Commit: [23f89a]

    • Markus Nißl
      Markus Nißl
      2014-06-01

      I tested your fix and things are looking good again :-) We will continue to use the patch when testing our software.

      Thank you very much for your fix!

       
  • Neil Hodgson
    Neil Hodgson
    2014-06-01

    • status: open-works-for-me --> open-fixed
     
  • Neil Hodgson
    Neil Hodgson
    2014-07-04

    • status: open-fixed --> closed-fixed