bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third]

On Sat, Nov 03, 2018 at 11:31:07AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 1 Nov 2018 22:55:19 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: Aaron Jensen <aaronjensen@gmail.com>, boris@d12frosted.io,
> >     32932@debbugs.gnu.org
> > 
> > ns_get_glyph_string_clip_rect is a simple wrapper round
> > get_glyph_string_clip_rects, so when asked for the clipping rectangle
> > for a single glyph, it returns a rectangle covering the entire row.
> > 
> > Because we just mark it as dirty and come back to draw it later we do
> > end up redrawing the entire row.
> 
> I think if you are basing the redisplay on marking portions dirty, you
> need to include the same logic as in display_and_set_cursor and its
> callers.

What I don’t understand is how we’re getting a blanking of the line.
When redisplay runs it’s incapable of drawing to the screen, and even
if we mark too large an area as dirty it won’t draw anything at that
point.

Later drawRect runs which calls expose_frame on the area we’ve marked
as dirty. NOW it can draw to the screen, but for it to leave a line
blank it would have to actually call clear_frame or clear_frame_area,
then not call anything to draw over the blanked area.

Is it possible for expose_frame to stop drawing part‐way through?

Or perhaps expose_frame actually thinks it should be blank at that
moment, but for some reason we’ve not marked the whole window or
whatever as dirty?

So we’re to display an image but it’s not loaded yet, so redisplay
blanks the window for the time being, but we fail to mark it dirty or
garbaged. Expose_frame comes along and draws the bit we’ve previously
asked it to draw. Finally the image loads and redisplay marks the
whole window as dirty leading to everything catching up at the next
expose_frame.

-- 
Alan Third