bug#32932: 27.0.50; render bugs on macOS Mojave

[Eli Zaretskii]

> Date: Sat, 3 Nov 2018 20:36:35 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, boris@d12frosted.io, 32932@debbugs.gnu.org
> 
> > 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.

What do you mean by "redisplay" in this context?  The function
redisplay_internal and the subroutines it calls?  If so, yes, that
doesn't draw anything, because AFAIU you've modified the functions
called from update_frame to mark portions of the frame dirty, but not
to redraw them.  (Other platforms do the redrawing inside update_frame
and update_window.)

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

No, I don't think so.  But what actually draws when expose_frame is
called is the backend-specific draw_glyph_string method, see
draw_glyphs.  What does the NS implementation of that method do when
it is handed a glyph string to draw? does it blank the entire line or
a part of it first?

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

I'm puzzled by this description, and actually by the whole larger
picture.  You see, I originally thought you had a problem of
flickering caused by redrawing the cursor, which was said to trigger
redrawing of the entire screen line where the cursor was, instead of
redrawing just the character under the cursor.  Is that still the
problem we are discussing?  If so, how does visiting the image file
come into play, and where is cursor positioned in this scenario?