#1291 Problems drawing wrapped lines

Bug
closed-fixed
Neil Hodgson
Scintilla (788)
5
2012-03-08
2012-02-04
Marko Njezic
No

During window resize (by mouse for example), wrapped lines are not painted properly. What is actually drawn on screen during resize depends on used technology. With DirectWrite enabled and double buffering disabled, only first subline of a wrapped line will be drawn, while the rest of sublines will be completely black. With GDI enabled and double buffering enabled, first subline of a wrapped line will be multiplied and drawn on every other subline instead of actual subline.

I attached two screenshots that demonstrate mentioned problems.

I'm aware that it takes some time to fully repaint window and that the problems will disappear when you stop resizing, however the problem doesn't affect all lines equally (first 10 or so lines always draw properly for me) and according to observed pattern it actually looks like the background of sublines is not properly erased during repaint. Not to mention that the effect is very noticeable when using DirectWrite and it doesn't look very nice.

Discussion

  • Marko Njezic
    Marko Njezic
    2012-02-04

     
    Attachments
  • Marko Njezic
    Marko Njezic
    2012-02-04

     
    Attachments
  • Marko Njezic
    Marko Njezic
    2012-02-04

    I tracked down the problem. Priority wrap does not take all actually displayed lines in account. This results in wrapped lines being painted using invalid line layout data, which is fixed only when idle wrapping kicks in.

    I attached a patch that should fix this problem.

    I would also like to mention that during debugging this, while using DirectWrite I managed to crash SciTE two times while I was resizing the window by mouse. Crashes are not related to my patch, they happened using vanilla Hg code. This has made me to reconsider if using DirectWrite is actually worthwhile.

     
  • Neil Hodgson
    Neil Hodgson
    2012-02-05

    The recurring bitmap for GDI and black effect for D2D look like early exits from the line drawing code. It should be possible to detect these situations and fill the line with the background colour which would be less intrusive.

    One D2D crash was fixed with change set 4009 and similar code may be needed in more places. The life cycle of the render target is quite different to a paint DC or the resources used on other platforms and this may require some more fixes.

     
  • Neil Hodgson
    Neil Hodgson
    2012-02-05

    • assigned_to: nobody --> nyamatongwe
    • milestone: --> Bug
    • status: open --> open-accepted
     
  • Marko Njezic
    Marko Njezic
    2012-02-05

    Filling background of invalid lines with STYLE_DEFAULT background color was the first thing I did. And the end result is just as ugly as black lines. Only difference is that in this case you end up with holes in document, which are fixed once background wrapping is done with invalid lines that have not been processed by Paint(). When background wrapping fixes the line layout, those lines will bounce up or down in order to fill the empty space. And this bouncing is particularly annoying, even more so if you work on a very powerful computer, which will still exhibit unnecessary delays in line re-positioning.

    Like I said in my previous message, the exact problem has been tracked down and it lies in WrapLines() method, which does not process all actually visible lines when doing priority wrap. And the fix is in my patch that is attached.

    The crashes I experienced were using the latest Hg revision (that includes change set 4009), so some other place still requires the same modification in order not to crash.

     
  • Neil Hodgson
    Neil Hodgson
    2012-02-06

    • status: open-accepted --> open-fixed
     
  • Neil Hodgson
    Neil Hodgson
    2012-02-06

    Committed.

     
  • Neil Hodgson
    Neil Hodgson
    2012-03-08

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