all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Aaron Jensen <aaronjensen@gmail.com>
To: Alan Third <alan@idiocy.org>,
	Aaron Jensen <aaronjensen@gmail.com>,
	Kai Ma <justksqsf@gmail.com>,
	63187@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
	Po Lu <luangruo@yahoo.com>
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Sun, 25 Jun 2023 15:07:39 -0400	[thread overview]
Message-ID: <CAHyO48xkdS5TSKkEZZ7=7SQpFVJ1pDbHk6Wgd8w_TnhFO3szaQ@mail.gmail.com> (raw)
In-Reply-To: <ZJiEoKPcImL8qShf@idiocy.org>

On Sun, Jun 25, 2023 at 2:17 PM Alan Third <alan@idiocy.org> wrote:
>
> On Sun, Jun 25, 2023 at 01:07:19PM -0400, Aaron Jensen wrote:
> >
> > Thank you for the continued explanation. I'm doing some additional
> > digging and it's making me wonder if what we are doing is even
> > possible reliably with Cocoa drawing and without any synchronization
> > primitives like MTLCommandBuffer's waitUntilCompleted. If I understand
> > correctly, we do something like this:
> >
> > 1. Draw to Surface 1 (buffer commands)
> > 2. Assign Surface 1 to the view as its layer
> > 3. Copy from Surface 1 to Surface 2
> > 4. Copy rects on Surface 2 to other parts of Surface 2
>
> Yep.
>
> > As I understand, there's no way to ensure that all commands have been
> > flushed all the way to the point that we know that Surface 1 is
> > actually representative of the commands we have sent it.
>
> No, you can use [NSGraphicsContext flushGraphics] and CGContextFlush
> to force it.

OK, that makes sense, but it's hard to find definitive documentation
of that (and ChatGPT seems to think that it's not true, but that's
likely a hallucination):

=====START GPT=====
[NSGraphicsContext flushGraphics] (in Cocoa) and CGContextFlush (in
Core Graphics) are used to bypass this batching process and force any
pending drawing commands to be executed immediately. After calling
these methods, you can be sure that all your previously issued drawing
commands have been sent to the GPU.

However, it's important to understand that while these functions
ensure that the commands are sent to the GPU, they don't guarantee
that the GPU has finished executing them. The actual rendering work is
still done asynchronously by the GPU.

So if you need to read back the results of your rendering (e.g., from
an IOSurface), there might still be a brief period where the rendering
hasn't completed yet, even after calling flushGraphics or
CGContextFlush. If you need to ensure that all GPU rendering work is
complete before you proceed, you would typically need to use a more
low-level API (like Metal or OpenGL) that provides explicit
synchronization capabilities.

...

Regarding your question about the [NSGraphicsContext flushGraphics]
and CGContextFlush, here are the descriptions directly from Apple's
documentation:

[NSGraphicsContext flushGraphics]: "Forces any buffered drawing
commands to be sent to the destination."

CGContextFlush: "Forces all drawing operations to be completed in the
specified context."

It's important to understand these function calls ensure that drawing
commands are dispatched, not that they are completed. This is an
inference based on understanding of how graphics pipelines generally
work. For more detailed behavior and how these calls interact with
your specific use-case, you should refer to Apple's documentation and
guides, or consider reaching out to Apple's developer support.
=====END GPT=====

> As I recall we've tried that in both copyRect and display.
>
> Ultimately releasing the context will have to flush any buffered
> writes, if it didn't then this would be a widely known problem as
> practically nothing graphical could be relied upon.
>
> This is my point about why I can't see this being the issue. Although
> it looks like it explains what we're seeing, we would have to be
> hitting some extreme edge-case.
>
> > I came across some notes from the Chromium team:
> > https://www.chromium.org/developers/design-documents/iosurface-meeting-notes/
> >
> > They (as of the notes) decided not to double buffer and just write
> > directly to the one surface. I don't know if that's reasonable/viable
> > for Emacs or not.
>
> Set CACHE_MAX_SIZE to 1.
>
> But on my machine this resulted in unacceptable rendering flaws on
> almost all animated gifs as partially drawn buffers were sent to VRAM.

What did you see?
I tried with this:

https://share.cleanshot.com/vJTClHW9

And I didn't notice anything drawing related, but I have an M1 with
integrated memory.

Aaron

> And adding more open frames just made it worse, as I recall. I never
> really understood why.
>
> It wasn't just gifs, but they were an easy test.
>
> But then, I'll bet performance is incredible. ;)
>
> > Lastly, as an aside, if we *could* synchronize, would it be more
> > efficient to not copy the entire surface just to then copy rects again
> > to handle scrolling? I can imagine this would add more complexity than
> > is worth it, I'm mainly asking for my own edification.
>
> I'm not sure if I'm following your question correctly, but yes, not
> copying is usually going to be faster, but it depends how long it
> takes the buffer to copy to VRAM, you might well find that you're
> waiting for it to finish when you may have already been in the
> position to start drawing to a second buffer.
>
> In theory, if you set CACHE_MAX_SIZE > 1, and change
>
>     [cache addObject:(id)currentSurface];
>
> to
>
>     [cache insertObject:(id)currentSurface
>                 atIndex:0]
>
> It should try to pick up the most recent surface first, then
> copyContentsTo will recognise that it's the same surface as last time,
> and not bother with the copy. I think you'd have to enable
>
>     [self setContents:nil];
>
> to work all the time too, as you might be wanting to "replace" the
> contents layer with itself.
>
> I've no idea if that would really work. IIRC on my machine the surface
> that was "in flight" to VRAM was never done fast enough that it would
> be picked up by the next getContext call so I felt it was a waste to
> check it every time. (And in fast-scrolling situations I could have as
> many as three surfaces in-flight at once if I let the cache grow that
> big.)
> --
> Alan Third





  reply	other threads:[~2023-06-25 19:07 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <m2fs8histt.fsf@gmail.com>
2023-04-30 10:33 ` bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS Eli Zaretskii
2023-04-30 10:46   ` Aaron Jensen
2023-04-30 13:25 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-04-30 14:25   ` Aaron Jensen
2023-04-30 14:42     ` Eli Zaretskii
2023-04-30 14:57       ` Aaron Jensen
2023-04-30 15:26         ` Eli Zaretskii
2023-04-30 16:48           ` Aaron Jensen
2023-04-30 19:04             ` Eli Zaretskii
2023-04-30 23:58     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-01 12:40       ` Eli Zaretskii
2023-05-01 13:18         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-01 13:25           ` Eli Zaretskii
2023-05-01 13:47             ` Aaron Jensen
2023-05-01 13:52               ` Eli Zaretskii
2023-05-01 13:55                 ` Aaron Jensen
2023-05-01 14:06                   ` Aaron Jensen
2023-05-09  3:07               ` Aaron Jensen
2023-05-09  5:39                 ` Eli Zaretskii
2023-05-13 13:54                   ` Eli Zaretskii
2023-05-13 14:23                     ` Aaron Jensen
2023-05-18 11:21                       ` Eli Zaretskii
2023-05-18 15:59                         ` Aaron Jensen
2023-06-08  5:40                           ` Kai Ma
2023-06-08  7:33                             ` Kai Ma
2023-06-08 12:51                               ` Alan Third
2023-06-08 13:42                                 ` Kai Ma
2023-06-08 14:57                                   ` Kai Ma
2023-06-08 17:22                                     ` Alan Third
2023-06-09  2:42                                       ` Kai Ma
2023-06-09  2:47                                         ` Aaron Jensen
2023-06-09  3:12                                           ` Kai Ma
2023-06-09 18:27                                             ` Alan Third
2023-06-09 18:46                                               ` Aaron Jensen
2023-06-09 20:00                                                 ` Alan Third
2023-06-12 13:04                                                   ` Aaron Jensen
2023-06-16  2:17                                                     ` Aaron Jensen
2023-06-19 15:46                                                       ` Aaron Jensen
2023-06-24  4:17                                                         ` Kai Ma
2023-06-24 13:34                                                           ` Aaron Jensen
2023-06-24 14:14                                                             ` Alan Third
2023-06-24 14:52                                                               ` Aaron Jensen
2023-06-24 15:08                                                                 ` Eli Zaretskii
2023-06-24 15:41                                                                 ` Alan Third
2023-06-24 16:05                                                                   ` Aaron Jensen
2023-06-24 21:29                                                                     ` Alan Third
2023-06-24 21:43                                                                       ` Aaron Jensen
2023-06-25 12:46                                                                         ` Alan Third
2023-06-25 17:07                                                                           ` Aaron Jensen
2023-06-25 18:17                                                                             ` Alan Third
2023-06-25 19:07                                                                               ` Aaron Jensen [this message]
2023-06-25 21:18                                                                                 ` Alan Third
2023-06-25 22:33                                                                                   ` Aaron Jensen
2023-06-26  7:27                                                                           ` Kai Ma
2023-06-28 19:53                                                                             ` Alan Third
2023-07-21  2:02                                                                               ` Aaron Jensen
2023-07-23 11:20                                                                                 ` Alan Third
2023-07-23 13:01                                                                                   ` Aaron Jensen
2023-07-25 14:47                                                                                     ` Aaron Jensen
2023-07-25 15:45                                                                                       ` Eli Zaretskii
2023-06-23  8:48                                                       ` Alan Third
2023-06-23 11:54                                                         ` Aaron Jensen
2023-05-01 17:26             ` Alan Third
2023-05-01 22:40               ` Aaron Jensen
2023-05-02 10:14                 ` Alan Third
2023-05-02 12:21                   ` Eli Zaretskii
2023-05-02 22:36                     ` Alan Third
2023-05-03  8:11                       ` Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-03 13:08                       ` Eli Zaretskii
2023-05-02  0:07               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-05-02  0:32                 ` Aaron Jensen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHyO48xkdS5TSKkEZZ7=7SQpFVJ1pDbHk6Wgd8w_TnhFO3szaQ@mail.gmail.com' \
    --to=aaronjensen@gmail.com \
    --cc=63187@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    --cc=eliz@gnu.org \
    --cc=justksqsf@gmail.com \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.