From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third 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 22:18:19 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18420"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , Kai Ma , Eli Zaretskii , 63187@debbugs.gnu.org To: Aaron Jensen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 25 23:19:23 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 1qDX8k-0004YO-Vl for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Jun 2023 23:19:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDX8U-0004fn-8y; Sun, 25 Jun 2023 17:19:06 -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 1qDX8R-0004fe-73 for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 17:19:04 -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 1qDX8Q-0001Ti-Ub for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 17:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDX8Q-0004Xw-Dl for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 17:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Jun 2023 21:19:02 +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.168772791017430 (code B ref 63187); Sun, 25 Jun 2023 21:19:02 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 25 Jun 2023 21:18:30 +0000 Original-Received: from localhost ([127.0.0.1]:43784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDX7t-0004X3-US for submit@debbugs.gnu.org; Sun, 25 Jun 2023 17:18:30 -0400 Original-Received: from dane.soverin.net ([185.233.34.25]:55703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDX7r-0004Wk-5l for 63187@debbugs.gnu.org; Sun, 25 Jun 2023 17:18:28 -0400 Original-Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4Qq3jm4KnbzySh; Sun, 25 Jun 2023 21:18:20 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4Qq3jm2KW2zFX; Sun, 25 Jun 2023 21:18:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1687727900; bh=r+nOS8lVeqPNfh++yGPZZ/5jgJLyBekiwGe6JZh/DBM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Syp9q0xDWFnZiblF1BG7riIpIfGP2SwGtCr/HBQ2obr6p2Vdwz0/0GJL2rxCrE5yr CP8mP4pCklUKaDFWBv8gipfS2pnryfeGK18zN7P+Z0PjdDvtHJoPMBKbbvAkfK79B5 mfnN8gpIzHkFK1lE7aBEqKJB9gzbRPjL+Aefm7TLc25xGzwczJkcSsf5gbQ+CO48Ae sIdGV/N75K4ycq1kY+0dfPXnr2hXAcwKG9tln2370Nht4j4gOZwiG3YKCxLSpCRNT2 mxRuEhU0cH4XD2/NO7Ojcbj3ZtTpzd+cnVHiY8AYf1g/0TzMmqcgONfDEvVB5LaPqR MvywZxZ6mPsHQ== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.95) (envelope-from ) id 1qDX7j-000b2b-7y; Sun, 25 Jun 2023 22:18:19 +0100 X-Soverin-Authenticated: true Mail-Followup-To: Alan Third , Aaron Jensen , Kai Ma , 63187@debbugs.gnu.org, Eli Zaretskii , Po Lu Content-Disposition: inline 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:264071 Archived-At: On Sun, Jun 25, 2023 at 03:07:39PM -0400, Aaron Jensen wrote: > On Sun, Jun 25, 2023 at 2:17 PM Alan Third wrote: > > 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===== The GPU isn't involved in this part. We're drawing to an IOSurface, which is a buffer in system memory. So when we draw and flush the graphics it's all done by the CPU in system memory. Then we put the IOSurfaceRef in the contents variable of the layer and at that point the GPU uses DMA to copy the buffer from system memory to GPU memory. While this is happening the IOSurface is locked so we know we shouldn't use it. Once it's in GPU memory, the GPU blits it to the screenbuffer or something, but by that time the IOSurface should be unlocked and we can start (safely) working on it again. > > 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. Lots of white space. I thought that it was being caught either just before or as the image was being drawn into the buffer, so some portion of the image area was blank. -- Alan Third