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

[martin rudalics]

> 'xwininfo' tool reports the frame had 697 pixels of height before the
> move, but 696 afterwards.

A frame move should never resize the frame.  Apparently the size hints
are working here.  Does it resize when you set `frame-resize-pixelwise'
permanently to nil too?  As an aside: IIRC trusting the values reported
by xwininfo is just like trusting any values reported by Emacs - they
are partially based on what is written into the size hints.

> Yes, I do.  However, the frame 696 pixels tall doesn't corrupt the
> mode-line, as shown by previous experiments.  A full-screen frame
> corrupts it, though.

And all other sizes that are not an integral multiple of the default
character size, I presume.  But when you split a window via C-x 2 and
mouse-drag the mode line of the upper window by very small (pixel)
increments do you see any corruption too?

> After getting the mode-line right by refreshing the frame, only
> scrolling can possibly corrupt the mode-line again.
>
>> Do you have to scroll the window in order to show the corruption?
>
> If the frame was refreshed, yes.

But you get the corruption only in a fullsized frame?

>> Maybe you could give us a step-by-step scenario of what you do to the
>> show the corruption, how to remove it afterwards, and how to show it
>> again after it was temporarily removed.
>
> After creating the frame with 'emacs -Q',

Don't you have to make the frame fullsize here?

> typing 'C-x d /dev RET'
> takes me to a Dired buffer with a corrupted mode-line as shown in the
> picture attached to the original bug report.  There, typing 'M-!
> xrefresh RET' repaints the whole frame and the mode-line is shown
> normally as one would expect.  Scrolling the text up with 'C-v'
> corrupts the mode-line again.

How does scrolling an upper window in a split frame work in this case?

martin