Display glitch when drawing a resizable window

[magiblot 1]

Hi,

I'm working on a terminal application where you can move and resize windows 
with the mouse. This has led me to face the glitch shown in this video:

https://drive.google.com/open?id=1w08Yb8ORwSxiMIDH73Sn6qb66DbN7O2q

This is how the application interacts with ncurses:

1. stdscr is the only ncurses window used.
2. The application stores a sorted list (first by row, then by column) of 
characters changed since the last refresh. When it decides it's time to update 
the display, it sends ncurses those characters in order.
3. Characters are represented with UTF-8 strings (not wide chars). Thus they 
are printed with mvprintw(y, x, "%s", ...).
4. attron is called before printw, and attroff after it.
5. The mouse pointer is drawn by GPM, rather than ncurses.

>From my experience I can confirm points 2, 4 and 5 are unrelated to the 
>glitch, as well as the counter in the top-right corner which gets updated 
>every often. I can also confirm that the glitch doesn't occur if the window is 
>being resized or moved horizontally -- only vertical movements cause the 
>glitch. It seems that the glitch rarely happens when there are windows at the 
>left of the one being resized, as can be seen in the linked video. Using GPM 
>for mouse events instead of ncurses --and vice-versa-- doesn't change the 
>result.

The only way I could find to overcome the glitch is by refreshing the screen 
after printing all the characters that belong to the same row. But I understand 
this may harm performance.

So, in order to be sure this is caused by ncurses, I wrote an alternative 
display backend that simply prints characters to standard output and uses 
CSI_;_H to move the cursor around, without any kind of text attributes. Indeed, 
the glitch doesn't occur with this display backend. I disabled attributes on 
ncurses as well, and then ran a very similar test with both, where I resized 
vertically a small window placed in the middle of the screen.

You can find the dumps of these tests here:

Simple ansi display: https://pastebin.com/dHRkKyHf
Ncurses display: https://pastebin.com/ADdpuwhM

Note that the first one is quite easy to read and helps understand how I send 
ncurses the chars.

>From all the things I tried, ncurses usually produced a slightly smaller 
>output than the simple backend. But that has not been the case for the test 
>above: ncurses prints more than three times the amout of characters than the 
>simple backend. So this can be considered not only a display glitch but also a 
>performance regression.

Thank you very much.