GNU bug report logs - #16621
24.3.50; Periodic timer + overlays = flickering near point

Previous Next

Full log

Message #41 received at 16621 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 16621 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
Subject: Re: bug#16621: 24.3.50; Periodic timer + overlays = flickering near
 point
Date: Tue, 04 Feb 2014 08:17:38 +0200

On 04.02.2014 05:48, Eli Zaretskii wrote:
>> Some relatively low-hanging fruit has already been mentioned in the
>> comments
>
> Like 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.