Re: NS Port drawing, again

Re: NS Port drawing, again

[Keith David Bershatsky]

With respect to cursors being left behind when scrolling, I have dealt with that in playing with feature requests #22873 (multiple fake cursors) and #17684 (crosshairs) by removing the cursors at the outset of redisplay in various locations.  For example, see the locations where I have:

  mc_remove_multiple_cursors (w);
  mc_remove_crosshairs (w);

See proof concept patch version 015 (11_10_2018__18_53_09_703.diff):

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22873#113

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

> Date: [10-12-2018 02:28:07] <12 Oct 2018 10:28:07 +0100>
> From: Alan Third <athird@googlemail.com>
> To: Keith David Bershatsky <esq@lawlist.com>
> Cc: Emacs-Devel devel <emacs-devel@gnu.org>
> Subject: NS Port drawing, again
> 
> On Fri, 12 Oct 2018, 09:54 Alan Third, <athird@googlemail.com> wrote:
> 
> * * *
> 
> I think this would solve issues with the cursor being left behind on scrolling, the flicker on resizing from lisp and probably the random blanking of frames users
> report.
> 
> * * *

Re: NS Port drawing, again

[Alan Third]

On Sat, Nov 10, 2018 at 07:47:35PM -0800, Keith David Bershatsky wrote:
> With respect to cursors being left behind when scrolling, I have dealt with that in playing with feature requests #22873 (multiple fake cursors) and #17684 (crosshairs) by removing the cursors at the outset of redisplay in various locations.  For example, see the locations where I have:
> 
>   mc_remove_multiple_cursors (w);
>   mc_remove_crosshairs (w);
> 
> See proof concept patch version 015 (11_10_2018__18_53_09_703.diff):

The problem we’re having with cursors is that when we ask for a cursor
to be removed it doesn’t actually happen on the bitmap until Cocoa
gets round to running drawRect. We can force it to run but that
invariably results in blank frames and things. On Mojave at least.

The current code works in most situations. There’s no longer any
random blanking of the screen (I think), so it’s perfectly usable, it
just has some weird issues with cursors. (I believe there are still
issues with the menus though? Nobody’s mentioned that for a while.)

I tried implementing drawing to a buffer, and that works perfectly on
High Sierra (except for some bits I know how to fix), but Aaron
reports that it doesn’t work at all on Mojave. I don’t know what I’ve
done wrong.

-- 
Alan Third

NS Port drawing, again

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

On Fri, 12 Oct 2018, 09:54 Alan Third, <athird@googlemail.com> wrote:

>
> The idea is that when running redisplay cocoa does not let you draw to the
> screen, so ns_clip_to_rect, etc., marks the area as needing to be redrawn
> later, and returns NO so you know not to try drawing to the frame.
>
> Later drawRect is called with a list of the areas that have been marked as
> needing redrawn and it calls expose on those areas and so Emacs runs the
> drawing functions again, but this time ns_clip_to_rect returns YES so you
> know you can go ahead and draw.
>

BTW, with all the unexpected little niggles this approach has introduced
that are proving hard to work round, I'm considering abandoning it and
following the Mac port's lead where we would draw to an off-screen surface
and then blit it back to the screen.

I think this would solve issues with the cursor being left behind on
scrolling, the flicker on resizing from lisp and probably the random
blanking of frames users report.

It would also avoid some concerns I have with making the NS port fully
threading compatible as drawing would be thread agnostic, and blitting to
the screen would always be handled by the main NS thread. They would be
completely separated.

I'm not sure what would be involved at this stage, though.

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]