cycfi
Weird caret drawing
Looking closely to the caret graphics on the text_edit example I noticed that there are actually 2 carets being drawn with different colors and with different visibility intervals. Some screenshots follow.
Both carets shown:
Only one caret shown:
Both hidden:
I failed to capture only the brighter caret on display because it is too bright to see whether or not the other one is drawn, but probably that case happens too. I actually saw the brighter caret go off, leaving only the dimmer one and after a short interval that one went off too. This proves that there are actually 2 different intervals (or maybe the same but at different phase). To reproduce, just click around a bit and look carefully to the caret.
I also noted some other (short lived) crazy caret behavior after changing caret position. Some screenshots are pretty much self explanatory.
Different caret sizes: 
This one actually shows only the brighter caret (the previously missing case) 
Caret size mismatch (between the two distinct carets simultaneously displayed) 
Some more examples:
Fragmented carets:
To reproduce just click around a bit and/or move the caret with the keyboard and look carefully.
Side note: I also noted some weird (double | triple | multi)click-selection behavior in which multi-clicks are detected even when they occur in different places. I will create a new issue about this later.
OS: Ubuntu 20.04.1 LTS - 64bit GNOME 3.36.8 on Wayland
Example built from develop branch.
Would you be interested to do some sleuthing in the code :-P ? Seems easy to track down since each element class has only one draw member function to investigate. It might also be some masking/clipping issue.
I'm taking a look at the library, but my time is somewhat limited. As for the interest, I got plenty. I really like this lib. I will try to find what happened there.
I'm taking a look at the library, but my time is somewhat limited. As for the interest, I got plenty. I really like this lib. I will try to find what happened there.
Understood. I'll see what I can do. My guess is that it is simply a masking/refresh issue and can be fixed by making the refresh rect a bit bigger.
Hmmm... Can you verify if this is also happening in the non-wayland world?
I think I found the bug. As you said, masking/refresh issue. The caret draws a little bit out of its expected bounds (maybe due to sub-pixel anti-aliasing). So, when you refresh the view to remove the caret, you miss a little edge. This can be fixed by adding a little extra to the bounds (between 0.5 - 1.0) That is half of it. When the caret is drawn, a refresh is scheduled to remove it after 500ms, or more precisely, to refresh its region. But if you move the caret to another location, you cause an immediate refresh, but the scheduled refresh is not canceled. When the old and new carets' region overlap, the old caret's scheduled refresh ends up removing a fraction of the new one.
Fixing the second part seem more complicated.
Edit: In the testing process, I added a caret-drawing logger/counter. I saw 1 drawing per caret showing when using the text box alone (without any margin or scrolling wrapper), but when wrapped as in the example, it redraws on almost any event (including just moving the cursor over the text). The caret is drawn from inside the text box draw() function, so this means that an unhealthy amount of redrawing is unnecessarily performed somewhere in the wrappers (I reached 100 within 10 secs).
Cool! OK, I'll see what I can do...
Oh and yeah, I am also considering optimizations for such things.
When the caret is drawn, a refresh is scheduled to remove it after 500ms, or more precisely, to refresh its region. But if you move the caret to another location, you cause an immediate refresh, but the scheduled refresh is not canceled. When the old and new carets' region overlap, the old caret's scheduled refresh ends up removing a fraction of the new one.
Makes sense. Thanks for investigating!