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

[martin rudalics <rudalics@gmx.at>]

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