|
From: | Dmitry Gutov |
Subject: | bug#16621: 24.3.50; Periodic timer + overlays = flickering near point |
Date: | Tue, 04 Feb 2014 08:17:38 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
On 04.02.2014 05:48, Eli Zaretskii wrote:
Some relatively low-hanging fruit has already been mentioned in the commentsLike what? If you mean the fact that we redraw the cursor when perhaps that could be avoided, someone else will have to suggest a better algorithm than doing it on every frame update.
No suggestions from me here. It should still be easier than double buffering, though.
but would it be too much to expect some sort of double-buffering used for Emacs display, eventually?You mean, outside Emacs? Yes, probably, but then this isn't an Emacs issue, and I know absolutely nothing about it.
Would a windowing system know which Emacs display states are "consistent", and which aren't?
Or is the related overhead considered too much of a cost?If you mean double buffering inside Emacs, you will have to explain why you think it will solve the problem.
AFAIU, flickering happens when the screen refreshes while Emacs display is in an inconsistent state. Like, you've cleared a rectangle to paint a character in it, but haven't yet painted it
If you copied the rendered state into a buffer, then cleared and painted the character there, then rendered the buffer into the window as a whole, the windowing system won't get a chance to see and display the intermediate state.
[Prev in Thread] | Current Thread | [Next in Thread] |