bug#10304: 24.0.92: display bug

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  10304@debbugs.gnu.org
> Date: Tue, 08 Jan 2013 06:11:34 +0100
> 
> Here's what the window looks like first, when everything is OK:
> 
> -----------------------------
> | bla bla bla               |
> | bla bla bla               |
> |                           |
> | --------                  |
> | |** ***|                  |
> | |*image|                  |
> | |** ***|                  |
> | |** ***|                  |
> | --------                  |
> |                           |
> | bla bla                   |
> | bla bla                   |
> -----------------------------
> 
> Then I scroll.
> 
> -----------------------------
> | foo                       |
> | zot                       |
> | more foo                  |
> | this is the end of the    |
> | buffer                    |
> |                           |
> | |** ***|                  |
> | |** ***|                  |
> | --------                  |
> |                           |
> | bla bla                   |
> | bla bla                   |
> -----------------------------
> 
> And the buffer ends where it says.  :-)
> 
> So I get the bottom half of the image, and then whatever was after the
> image.
> 
> So it's like it decides that it doesn't have to blank the window after
> end-of-buffer if end-of-buffer happens in the middle of the image that
> was displayed there.  If you understand what I mean.  :-)

I think I do understand.  My suspicion is that we somehow fail to
realize that the screen estate formerly occupied by the image, and
everything that follows it, needs to be cleared in its entirety.  On
the display engine level, the image takes just one "line" (called
"glyph row"), and perhaps we somehow don't realize that the height of
that "line" is large, and all of that needs to be cleared, not just
the number of text lines of "normal" height that will replace the
image on display.

Thanks for the details, they confirm my suspicions.  I now need to
find whodunit in the code...