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

Previous Next

Full log

View this message in rfc822 format

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

> Date: Tue, 04 Feb 2014 04:34:58 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> CC: 16621 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> 
> Isn't the fact that flickering is at all possible in this scenario, a 
> problem?

Yes, but it is currently an unavoidable one, because this is how the
code was designed and implemented to work.

> Doesn't it mean that occasional flickers can still happen under 
> normal conditions (timers with much longer intervals, for example),just 
> that the probability of occurrence is smaller. If I understand you 
> right, all it takes is for timer to fire at just the right moment before 
> the screen updates.

Indeed, that's true.

> 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.  Nothing else
discussed here was easy, either.

> 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.

> 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.

Previous Next

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