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 19:17:04 +0100 Message-ID: References: <335C856F-41F7-48B8-AF42-B2406065C7A9@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18876"; 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 20:18:24 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 1qDUJa-0004cJ-H4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 25 Jun 2023 20:18:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDUJH-0008WP-OL; Sun, 25 Jun 2023 14:18: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 1qDUJG-0008WG-Nf for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 14:18: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 1qDUJG-0001Ll-FT for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 14:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDUJG-0008Fp-B9 for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 14:18: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 18:18: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.168771703431670 (code B ref 63187); Sun, 25 Jun 2023 18:18:02 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 25 Jun 2023 18:17:14 +0000 Original-Received: from localhost ([127.0.0.1]:43665 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDUIU-0008Ek-04 for submit@debbugs.gnu.org; Sun, 25 Jun 2023 14:17:14 -0400 Original-Received: from dane.soverin.net ([185.233.34.149]:44325) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDUIR-0008EX-SV for 63187@debbugs.gnu.org; Sun, 25 Jun 2023 14:17:12 -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 4Qpzhf2qYQzyRm; Sun, 25 Jun 2023 18:17:06 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.100]) by soverin.net (Postfix) with ESMTPSA id 4Qpzhd5m9Zz9j; Sun, 25 Jun 2023 18:17:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1687717026; bh=7W/LyUCoNHhOORJStggQt9gfFcdUIJOY7Z/jM+PD5Ic=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JfeGiF9fQnAzg1OiLv50pEOAa4OHMDRssMel3La8n3q4fU5P1YqT9DGLI+fMpMllb +cYyD7zBFYu65hM0bsfPUFWlq+LWcZIyqImytkrKnZA9kJL5GkRS+BUbbWB15jaF8V 9OmRZzScMvo5/rYV3Zd3sbRMdG3ba7klELeKugRdfHbyJQcETFlcXyPAT/027PICdm uwzFo88NBE3hm9z0WY3J46+8GbwTSfcEgNp/9YFZUG3zX4VE0jd3bW9cQgcxPAW2Vp s9RXL2okctZENdBjA8NGZrbboWb4pUPZMntRWm/LpocyIRKrub15BODpucI5QIe2o0 e5w6Oq2j8WSgA== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.95) (envelope-from ) id 1qDUIK-000adf-HX; Sun, 25 Jun 2023 19:17:04 +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:264066 Archived-At: 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. 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. 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