bug#32932: 27.0.50; render bugs on macOS Mojave

[Alan Third <alan@idiocy.org>]

On Sun, Feb 02, 2020 at 04:14:51PM -0800, Aaron Jensen wrote:
> On Sun, Feb 2, 2020 at 2:30 PM Alan Third <alan@idiocy.org> wrote:
> >
> > I know exactly what’s causing the glitching, but I’ll come back to
> > this tomorrow.
> 
> Looking forward to hearing more.

How Cocoa is supposed to work:

When a part of the view must be updated you mark it as dirty. You can
also mark the entire view.

At some point in the NS run loop the graphics context for the window
is set up and drawing is clipped to the areas that were marked as
dirty.

Starting with the first opaque view drawRect is called on each view
that intersects the dirty rectangles. drawRect redraws the contents of
those rectangles.

The dirty rectangles are reset and the process begins again.

The application may not draw to the view outwith drawRect, the only
exception being scrollRect, which appears to require being called
outwith drawRect.

Emacs 27:

Redisplay thinks it’s drawing to the view as it runs, however on NS it
just marks areas as dirty and calling scrollRect.

Once redisplay is completed the run loop starts the process that calls
drawRect.

In the normal case the first opaque view is the NSWindow, which is
blank. It’s just set to the background colour. This immediately clears
anything that was in the dirty rectangles.

Sometimes the NSWindow may be transparent as well in which case the
first opaque view will be the root window. The end result is the same,
the dirty rectangles are now ‘clear’.

EmacsView’s drawRect is called. This calls expose_frame which
draws the contents of the dirty rectangles for real this time.

All is well.

But not always.

Sometimes when expose_frame is called the frame has been marked as
garbaged, so expose_frame refuses to do any drawing. Since the dirty
rectangles have already been cleared by the NSWindow we now have blank
spaces displayed to the user.

Even worse the dirty rectangles are now reset and Emacs has no idea
that those areas are blank so it makes no further attempts to redraw
them.

(IIRC just forcing a display at the end of redisplay, before anything
else has had a chance to garbage the frame, doesn’t work.)

Scrolling is a problem too. scrollRect (which is deprecated and will
be removed) copies the contents of the screen. Sometimes the parts of
the screen it copies contain the cursor. Normally Emacs clears the
cursor before copying parts of the screen, however Cocoa doesn’t let
us draw to the screen outwith drawRect, so we can’t clear the cursor
before calling scrollRect.

The work‐around in use here is to copy the dirty rectangles with the
part of the screen we’re copying. There’s a reasonable chance that we
end up redrawing most of the area that was copied in an attempt to
clear the cursor(s).

Conclusion:

Drawing to a bitmap is just much easier than trying to fix these
issues, although they probably are fixable.

We need a replacement for scrollRect. My hope is that we can save up
the copy commands and replay them within drawRect, that way we can
remove the cursor before copying.

If we make the EmacsView opaque the dirty rectangles aren’t cleared,
however we need to be much more careful about drawing to the whole
view as blank areas aren’t magically cleared for us. And we can never
have a transparent background, which I don’t see as much of a loss,
but some might.

IMO the best solution would be if expose_frame was able to always
redraw the last matrix created by redisplay, however this isn’t
possible, and I’ve never managed to understand enough of redisplay to
know why.

If expose_frame does nothing we could save the dirty rectangles and
re‐mark them sometime after. Probably at the end of the next
redisplay.

I think there were some other problems that I’ve forgotten, but those
were the main issues. I hope this helps explain the issues.
-- 
Alan Third