From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <335C856F-41F7-48B8-AF42-B2406065C7A9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="921"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Aaron Jensen , Kai Ma , 63187@debbugs.gnu.org, Eli Zaretskii , Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 25 21:09:26 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qDV70-000AZd-FK for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Jun 2023 21:09:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDV6d-00088F-Kb; Sun, 25 Jun 2023 15:09:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qDV6c-00087n-88 for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 15:09:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qDV6b-0003KU-W0 for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 15:09:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDV6b-00016x-HO for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 15:09:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Jun 2023 19:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63187 X-GNU-PR-Package: emacs Original-Received: via spool by 63187-submit@debbugs.gnu.org id=B63187.16877200824198 (code B ref 63187); Sun, 25 Jun 2023 19:09:01 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 25 Jun 2023 19:08:02 +0000 Original-Received: from localhost ([127.0.0.1]:43680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDV5e-00015d-8H for submit@debbugs.gnu.org; Sun, 25 Jun 2023 15:08:02 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:45504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDV5Z-000155-1F for 63187@debbugs.gnu.org; Sun, 25 Jun 2023 15:08:00 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-51d946d2634so834648a12.3 for <63187@debbugs.gnu.org>; Sun, 25 Jun 2023 12:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687720071; x=1690312071; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BbjsTZ7waEEGV4Izmm+5QP3rvWIe/bdEOGKFckhdmPo=; b=dcnCWshOskkfxGPDLpXWtDeq1TObefznTiDX4/aWiDSuwVWMslYaL2oW88NaaMdUIr /KzdmCkBmGuiJF5GJvwzhQNHavU+RUCZjrhM0FhZ37dFl6centVrKXiccE4TKmFtjs/h pyJHHym6AkNqk9yjyLipCbWYctt9h8QASESHlnBfHDuNF0aRWppEbXaeJ5CVT62P5vub fwgoto54RhJoHj9sC8EEMD4yIVEIH87EQuWxaltC667tZ8t//69BoaLFEzYu9k/SUeeC 7p8wTo4p8E0zaW0HbEcDTvx7wD/OPKLIbZsvyr3OlXSfAg/UWErjk6FOdciZfsNefK2U NqOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687720071; x=1690312071; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BbjsTZ7waEEGV4Izmm+5QP3rvWIe/bdEOGKFckhdmPo=; b=WJWtVM7sQGeuAkUDmI70Etrof1QyigKW1iagNWoqo28jGl2fFkQgDbVFtTXh+frogi eWzBhK68WubgLLTdpkjMVA5g7WcFZJB1cnPNbW2BI7VHscP8UcqYMt9eq7Y9ytTtkjXB BYnGWZr3KaZLZeL2CFZ5ZfjtdSBU0/1/3ije3Gw8W7BIy9dB/bA6/avi57MifCfsuQ7O 41CrvPBHjSwzT6epgiBk4/9lwbiv9JCxXQ6rqkSbtgnvO2PH13o+DFkV7JXbVMpOHMkq eaOaVTdJsEN4XH7DiFAUIZ3PKa6VkQYI8nRLHdksGH3Hdg3VSgsqsbg6G9mHtZNcSGt0 QGKg== X-Gm-Message-State: AC+VfDwuEuaI5rD97iAP7l/unJ8M12FDt6XlNtmC2k7V7DMW6hxZMmkN PL5ggeClwVDgxF2CKlAUOWqqT49/Fz1gE6HFjuc= X-Google-Smtp-Source: ACHHUZ7lqbv3QZmGJh3pZwjmhv40sdZAO0lFvguTqTnAUpD1FPYH2V8uRYJQ0S6OW6z/f5RN7PBI8AOXXPR4quPoTcY= X-Received: by 2002:a05:6402:502:b0:51b:ebd3:69a2 with SMTP id m2-20020a056402050200b0051bebd369a2mr6798985edv.38.1687720070735; Sun, 25 Jun 2023 12:07:50 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264068 Archived-At: On Sun, Jun 25, 2023 at 2:17=E2=80=AFPM Alan Third 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): =3D=3D=3D=3D=3DSTART GPT=3D=3D=3D=3D=3D [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. =3D=3D=3D=3D=3DEND GPT=3D=3D=3D=3D=3D > 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