bug#18912: 24.4; mode-line corruption on graphical frames in dual-headed display

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 05 Nov 2014 19:38:52 -0200
> From: Bruno Félix Rezende Ribeiro <oitofelix@gnu.org>
> CC: 18912@debbugs.gnu.org
> 
> > Finally, type inside Emacs:
> > 
> > M-: (set-window-vscroll nil 5 t) RET
> > 
> > How many mode lines did that corrupt?
> 
> Immediately after the command, completely the lower one, and only
> slightly the upper one.

The "slightly" part depends on the value of vscroll, which was 5 in
this experiment.  You can play with the 2nd argument of
set-window-vscroll to see the effect.

> > If both mode lines become corrupted, does xrefresh succeed in fixing 
> > that?
> 
> It *does* succeed in fixing the lower mode-line (the current one).
> The upper one continues slightly corrupted until it becomes the
> current one (eg. by 'C-x o'), in which case it becomes fine until next
> scrolling.

Which means, as I hope you understand, that to do what you want, Emacs
needs to have a very clever global strategy for refreshing the mode
lines, which considers all the windows that were updated, instead of
treating each window separately, which is what it does now.

> > Bonus points for repeating the above after setting mode-line-format
> > to nil.  I expect you to see that the 2 windows corrupt each other
> > in that case.
> 
> Indeed.  The upper one is corrupting the first line of the lower one.
> However, scrolling the lower one redraws that line and it doesn't get
> corrupted again until scrolling the upper window.

In this case, there are no mode lines to refresh, so this directly
affects the order in which redisplay redraws lines in each window.

I think we have spent enough time on this, and we understand well
enough that this problem cannot be possibly solved by Emacs in any
reasonably simple way.  So I'm closing this bug, as this is not an
Emacs problem.  My suggestion to you is to upgrade your video firmware
and device driver, or disable acceleration.