[Top][All Lists]

[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: Thu, 8 Nov 2018 23:23:49 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Thu, Nov 08, 2018 at 06:51:37PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 8 Nov 2018 16:17:15 +0000
> > From: Alan Third <alan@idiocy.org>
> > Cc: aaronjensen@gmail.com, 32932@debbugs.gnu.org, boris@d12frosted.io
> > 
> > > What exactly do you mean by WHENEVER REQUESTED?  As opposed to what
> > > alternative?
> > 
> > At the moment expose_frame doesn’t draw anything if the frame or
> > window has been marked as garbaged
> AFAIR, that's a mere optimization, so if you want expose_frame to go
> ahead and redraw on NS regardless of the frame's garbaged flag, it's
> fine with me.
> > (there may be other circumstances too).
> The only other case is when the frame's face cache is empty, in which
> case you won't be able to draw anything anyway.
> There's a no-op return in expose_window, but I think its condition
> cannot happen nowadays, it's a relic from when expose_frame could be
> entered asynchronously from a signal handler.

It may be worth keeping it for now as I’m unsure what will happen
when I finally get round to splitting the NS and lisp code into
separate threads (I had a go at it before and it was largely
successful, but there were a lot of graphical issues that caused

> > If expose_frame could draw the rectangle as it was before the
> > frame/window was marked garbaged, that would also solve the problem.
> Not sure what this means: you can only draw what's in the glyph
> matrices, what was there before the garbaged flag was set is gone for
> good.

That’s exactly what I meant. Thanks.
Alan Third

reply via email to

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