bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#32932: 27.0.50; render bugs on macOS Mojave


From: Alan Third
Subject: bug#32932: 27.0.50; render bugs on macOS Mojave
Date: Sat, 20 Oct 2018 21:04:44 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

On Fri, Oct 19, 2018 at 12:24:33PM -0700, Aaron Jensen wrote:
> On Fri, Oct 19, 2018 at 11:48 AM Alan Third <alan@idiocy.org> wrote:
> > > https://cl.ly/9065281385cf/Image%202018-10-19%20at%209.20.34%20AM.png
> >
> > Does it actually look like that? With the strange blocks? It looks
> > like there’s some weird resizing/resampling thing going on...
> 
> No, that's me anonymizing source I can't share :)

Oh, thank goodness! :)

> > That makes sense because of how the cursor code marks entire lines as
> > dirty. If it was drawing correctly then I’d fix it, but there’s no
> > point just now.
> 
> Sorry, fix which, and what drawing correctly? I didn't think it
> repainting the cursor line is a problem (especially since I use
> global-hl-line-mode). But maybe you meant something else.

Sorry, I’m just confusing things. We’re redrawing more than we need to
at the moment. It’s not really a problem.

Can you try removing

    ns_clear_frame_area (emacsframe, x, y, width, height);

from drawRect: in nsterm.m? It may result in the background not being
redrawn correctly in some places, but I *think* it’s redundant, and
it’s possible for it to clear a section of screen and then
expose_frame to decide not to redraw anything.

This shouldn’t happen as the only reason I know for expose_frame to
not redraw is if there’s a redisplay coming up, in which case
redisplay should mark the whole frame as needing redrawn anyway. But
perhaps there’s some situation where it doesn’t draw and there’s no
immediate redisplay.
-- 
Alan Third





reply via email to

[Prev in Thread] Current Thread [Next in Thread]