GNU bug report logs - #32932
27.0.50; render bugs on macOS Mojave

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Thu, 4 Oct 2018 13:07:02 UTC

Severity: minor

Tags: fixed

Merged with 31904, 33891, 34127, 34710, 36302

Found in versions 26.1.90, 26.1.91, 26.2.90, 27.0.50

Fixed in version 28.1

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

Full log


Message #155 received at 32932 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: boris <at> d12frosted.io, 32932 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Sat, 3 Nov 2018 20:36:35 +0000
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 <at> idiocy.org>
> > Cc: Aaron Jensen <aaronjensen <at> gmail.com>, boris <at> d12frosted.io,
> > 	32932 <at> 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




This bug report was last modified 5 years and 94 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.