GNU bug report logs -
#32932
27.0.50; render bugs on macOS Mojave
Previous Next
Full log
Message #74 received at 32932 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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
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.