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

[Jan D.]

Hi.

4 feb 2014 kl. 17:00 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Tue, 04 Feb 2014 08:17:38 +0200
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> CC: 16621@debbugs.gnu.org, monnier@IRO.UMontreal.CA
>> 
>>> 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.