Subject: Re: bug#16621: 24.3.50; Periodic timer + overlays = flickering near point

From: "Jan D." <[email-masked]>
Date: Tue, 4 Feb 2014 23:08:13 +0100

Hi.

4 feb 2014 kl. 17:00 skrev Eli Zaretskii <[email-masked]>:

>> Date: Tue, 04 Feb 2014 08:17:38 +0200
>> From: Dmitry Gutov <[email-masked]>
>> CC: [email-masked], [email-masked]
>> 
>>> 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?
> 
> If hints are needed, we could do that.
> 
>> 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.
> 
> Avoiding the cursor redraws sounds much easier, but again, I'm not an
> expert on this.  Perhaps Jan could comment.

Avoiding the cursor redraws must be easier.  Implementing double buffering is more work.
Not rocket sience, but it would probably take a while to get it right. 

Ironically we turn off the Gtk double buffering, because it only works with Gtk drawing functions,
and Emacs uses X functions.  A more long term solution would be to use Cairo.  There is a patch
for it, but it does not work on the trunk.  Mainly because the ftfont backend is broken.

So, if there is a way to avoid cursor redraws, go for it.  All ports benefit.  Double buffering is a port specific solution, unless the display engine does double buffering by having two sets of glyphs and compares them to see what has really changed. Sounds like a big project.

       Jan D.