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: Tue, 2 May 2023 11:14:56 +0100 Message-ID: References: <87ilddec31.fsf@yahoo.com> <87edo0exct.fsf@yahoo.com> <83wn1sns1n.fsf@gnu.org> <87pm7kchqw.fsf@yahoo.com> <83pm7knpzi.fsf@gnu.org> 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="2666"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Po Lu , 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 Tue May 02 12:16: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 1ptn3Y-0000VX-Hn for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 02 May 2023 12:16:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ptn3J-0002tf-Sn; Tue, 02 May 2023 06:16:09 -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 1ptn3C-0002t2-HV for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 06:16:05 -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 1ptn3B-0007Ux-Vy for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 06:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ptn3B-0003sM-Qi for bug-gnu-emacs@gnu.org; Tue, 02 May 2023 06:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 May 2023 10:16: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.168302250814801 (code B ref 63187); Tue, 02 May 2023 10:16:01 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 2 May 2023 10:15:08 +0000 Original-Received: from localhost ([127.0.0.1]:41796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ptn2J-0003qf-TQ for submit@debbugs.gnu.org; Tue, 02 May 2023 06:15:08 -0400 Original-Received: from dane.soverin.net ([185.233.34.24]:43561) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ptn2H-0003pn-Pn for 63187@debbugs.gnu.org; Tue, 02 May 2023 06:15:06 -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 4Q9bYJ1Jgvz10f1; Tue, 2 May 2023 10:15:00 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4Q9bYG4vHdzF3; Tue, 2 May 2023 10:14:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1683022500; bh=t/OYtyqI9IrwvznHRga1Gh3gaXVj9bY6KLkxxH3JOcw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=My82ihgu4ra1v1qiMLeXIghhyGfl34B0DiZhoYwHYren5MmHroerTxmoCV2UctlrJ H5HiZLCJkZMguiTVErhTmpUOf+xXKJ30Oyr/X0O3rX7bGUL8tqGxW4aHtoINes4ArO je8xWrbPKc8ljr4OVVFdxChkxKJmOp9PRbfsYu3j9Lk/DZsVns95VFmFZr+4mQKqW7 wHG0CUXavfNAL5WN1UM3traEF0EZgmuq6vhA9AOYXs3yTdc0gS3nubpNIP7PtAWwCk ocq5P93aHpywl92KcoN2nMbzz8NEi6whke4hiwOixh3xBtIv+ka+OgM3Yj6iM6SXM2 Nf6ED6tMo22JA== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.95) (envelope-from ) id 1ptn29-000CrZ-1Z; Tue, 02 May 2023 11:14:57 +0100 X-Soverin-Authenticated: true Mail-Followup-To: Alan Third , Aaron Jensen , Eli Zaretskii , Po Lu , 63187@debbugs.gnu.org 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:260909 Archived-At: On Mon, May 01, 2023 at 06:40:15PM -0400, Aaron Jensen wrote: > On Mon, May 1, 2023 at 1:26 PM Alan Third wrote: > > > > My memory of Aaron's previous bug report about this was that it looked > > like, in some cases at least, the rectangle being copied was too wide > > and copyRect, not being very smart, was just wrapping off the edge of > > the buffer onto the next row of pixels, but I couldn't find any reason > > for that to happen since afaik all the callers check the Emacs window > > size so should never ask to copy a too-wide rectangle. > > This one seems to be more about longer lines ghosting onto the tail > end of shorter lines. You could imagine that if you had a long line > and a short line, then scrolled such that the short line was where the > long line was but only repainted the area there were glyphs, the new > short line would include the tail end of the long line: > > window line 2: xxxxxxxxxxxxxx > window line 3: yyyyyyyyyy > -> > window 1: xxxxxxxxxxxxxx > window 2: yyyyyyyyyyxxxx Yeah, that's why I'm wondering if there's a timing thing where the toolkit hasn't completed it's drawing before we copy the pixels. Emacs might ask to clear the end of a line, then copy those "cleared" pixels using copyRect before the initial clear has actually been completed. This is just conjecture, though. The other option is that it is copying too much and grabbing things it shouldn't, but even though I think we've seen that before, I don't know how it would happen. Although, on reflection, your description sounds more like it's just not clearing the end of lines correctly, which wouldn't necessarily have anything to do with scrolling as such... > What do you think about what I mentioned later in the thread about: > > [view setNeedsDisplayInRect:srcRect]; > > Why would that be srcRect and not destRect? Could that cause this somehow? I suspect that's a hang-over from the old rendering scheme where we would have had to flag up that the source would need redrawn later. scrollRect already marks the destination as needing updated on screen, but iirc for whatever reason the source was never flagged as needing redrawn, which it almost always did when scrolling. The 10.14+ drawing scheme doesn't really require individual areas to be marked as needing redrawn since the entire back buffer is sent to the screen on update anyway. It could be worth replacing that with a call to [NSView setNeedsDisplay:], or getting rid of it and making copyRect do it instead. I don't know if it's even necessary since I think Emacs will always do other drawing actions as part of a scroll which will mark the view as needing sent to the screen. -- Alan Third