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

["Bruno Félix Rezende Ribeiro" <oitofelix@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

Eli Zaretskii wrote:
> You'd need to explain how Emacs succeeds in that, when it uses Xlib
> and higher-level APIs, which AFAIK are unaware of any accelerations.
> Emacs itself is certainly unaware of that, and does the same things
> regardless.

The Emacs algorithms for redrawing the frame's content could be based on
assumptions about the workings of graphical displays that fail to be
true in some corner cases.

> Moreover, the fact that running xrefresh, which is not an Emacs
> command, fixes the display is yet another argument against this
> hypothesis.  xrefresh doesn't communicate with Emacs, so the only way
> it could fix the display is if the data supplied by Emacs was correct.

Of course 'xrefresh' command doesn't communicate directly with Emacs.
It works by mapping a window, with no background, on top of the Emacs'
frames, and then unmapping it, causing the X server to send a refresh
event to Emacs, that handles it and repaints its frames.  So Emacs *do
know* how to get its frames right, when it wants to.

-- 
 ,= ,-_-. =.  Bruno Félix Rezende Ribeiro (oitofelix) [0x28D618AF]
((_/)o o(\_)) There is no system but GNU;
 `-'(. .)`-'  GNU Linux-Libre is one of its official kernels;
     \_/      All software must be free as in freedom;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]