|
|
Please test with rev 49089 and close if ok. |
|
|
No, i'm really sorry but it's not fixed. - Scroll back + zoom, the caret is still sometimes partially drawn. - bad news: additonal symptom: after the scroll + zoom, i click to put the caret on another line and the previous caret persists like this: http://i.imgur.com/Wd0sirF.png (line 2891 is caret after scroll + zoom, line 2889 is caret after clicking). |
|
|
prevpersists.png (3,790 bytes) |
|
|
I temporarily reverted the change made before.I was able to get a caret that had its upper and lower half blinking out of sync. I.E. when the upper half was visible, the lower was not. And vice versa. This happens by mouse wheel scrolling / no zooming. This half/half caret is probably a separate bug, that got revealed by fixing the wrong clipping. When the clipping is reset, the OS (Windows) should delete the undersized caret. It seems it does not. This issue may also still be present (not yet tested) in trunk, if you use SynEdit outside the IDE. (In the IDE it does not use the system caret). ------------------- As for your image. The remaining caret is the same as the the half/half. Windows draws the caret by inverting pixels. So the background never gets repainted. At some point it seems it looses track, and thinks the caret is hidden, while it is not. Then when it moves, it inverts to visible. |
|
|
Please test with 49114 |
|
|
Both are fixed now. Thx very much. I have not tested the trunk so far. But if i see it again, eg during the next public 1.x beta stage, i'll won't esitate to report this time (yes, because i've noticed the bug during 1.4 RC2 but i wrongly thought it wasn't worth reporting because the problem seemed so obvious), anyway it's ok now. |
|
|
Trunk appears not to be affected after all. |
- Anonymous
