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: Sat, 24 Jun 2023 12:05:45 -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="26124"; 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 Sat Jun 24 18:07:29 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 1qD5nM-0006dc-US for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Jun 2023 18:07:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qD5n0-0006US-13; Sat, 24 Jun 2023 12:07: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 1qD5my-0006Tx-1i for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 12:07: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 1qD5mw-0000pa-30 for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 12:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qD5mv-00018M-Tn for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 12:07: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: Sat, 24 Jun 2023 16:07: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.16876227694280 (code B ref 63187); Sat, 24 Jun 2023 16:07:01 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 24 Jun 2023 16:06:09 +0000 Original-Received: from localhost ([127.0.0.1]:41385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qD5m4-00016x-CL for submit@debbugs.gnu.org; Sat, 24 Jun 2023 12:06:08 -0400 Original-Received: from mail-ed1-f44.google.com ([209.85.208.44]:51490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qD5ly-00016Q-Qr for 63187@debbugs.gnu.org; Sat, 24 Jun 2023 12:06:06 -0400 Original-Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-51bdd67a306so1866225a12.3 for <63187@debbugs.gnu.org>; Sat, 24 Jun 2023 09:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687622757; x=1690214757; 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=1bvDFGEdCRDmF2LdPt3/+47bNFAvaKwlMq80x+qc7Pk=; b=OV9tTE3GJIg3cSqFiATuRdOKH5SeoEY+Igupa3Njs7hWF+bjvyLxMdTbihN4W+5eDZ RXpS9UxLIM1xyDAbjMD9dVgKFjokanDfe8ZXbbxZExqVyG2Qx7aj5V8iwIc3GksuUQgI ZcBc3FTWI6KLrDmb7SoEk1D1/LJt486ul7/pJHx6LJAK6Jui2EOhscfWAog4VWWk+5Yo ILZgBe/SFYye8ibwgRtljWOoRhPOTgzIkMCy6lDjlo0U7Y9DTl/zZ0L4rS74IHtLQo6P SXD8Od2IYjKRiEX5HYnfUdNhE1XmcS5vwzz4GI3f5/mZuMulrt643EwVJZX2xFz+/Xdo lpBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687622757; x=1690214757; 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=1bvDFGEdCRDmF2LdPt3/+47bNFAvaKwlMq80x+qc7Pk=; b=aYpBjEWEMVEoQ5TzKua8PUjajKuEXzZfBqdrDm7nWYo8dvw4UMCg/cRtdrAUPj13u2 W+ZceYPWwJ4d5HlEQEVPHPKDFG50QSniuhOJlu4Au/RngfLJ2Dk4GEJXUojNAR43MnBF 1Gqgq5AzOsLtOjE7FmNZhsTw4eKVKmUy9YSvbC5uFqLEj2Wn2GDon6upb0OgL2YcFwIg q+RA2tt8F6NULmOz2y6hvBmn6prXktz76HyOJLyCWgWRS3/c3Dn0jJMFgEj8hnzyA/YK mFkLfg9DUkXAqTt5+ROOZHTUzLfLzBc8/PSrzQb9/Ba1nvEACB9XFtjERl0WebJyEezN /rlQ== X-Gm-Message-State: AC+VfDyb1Mj/pmgZwofsjHcDDZCntwP8ZgF+3fui9zqYDkR/rzx6Z36G I/N3ERjkKeiSINkgKAQEqL+MwdZASPc4HUKpTDI= X-Google-Smtp-Source: ACHHUZ52b41nix4qbTHgYXQ13TF9kI9abVzffZ5c8vM70JUJLdCCh1IksvyLKfrZ+WwWMWIRbVvSNd3D/QPuB9is4zU= X-Received: by 2002:aa7:d741:0:b0:51b:ed42:8ea8 with SMTP id a1-20020aa7d741000000b0051bed428ea8mr5040765eds.36.1687622756820; Sat, 24 Jun 2023 09:05:56 -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:264004 Archived-At: On Sat, Jun 24, 2023 at 11:41=E2=80=AFAM Alan Third wrote= : > > On Sat, Jun 24, 2023 at 10:52:08AM -0400, Aaron Jensen wrote: > > On Sat, Jun 24, 2023 at 10:14=E2=80=AFAM Alan Third w= rote: > > > > > > On Sat, Jun 24, 2023 at 09:34:18AM -0400, Aaron Jensen wrote: > > > > > > > > Could you try removing the destination lock as well and see if that > > > > impacts anything? From what I can tell, locking the destination may= be > > > > a good idea, but I'm curious if Alan has any thoughts as to why it'= d > > > > be a bad idea. > > > > > > copyContentsTo is only called by getContext, which has already locked > > > the destination, so there's no need to lock it again. > > > > Ah, I see. Is the kIOSurfaceLockAvoidSync flag valuable for any reason? > > I don't think so... Not in our use-case. IIRC it's possible to get the > GPU to perform actions on the buffer once it's in VRAM. We don't do > that, so we don't need to ever worry about write-backs to system RAM. > > I think. > > > If I recall correctly, there's some code in Emacs that optimizes which > > areas of the screen glyphs are drawn to. Maybe it remembers what was > > the background color already and doesn't clear it again... I don't > > remember where I saw it, but I think it was outside of nsterm. Does > > that ring a bell? I'm thinking about how this manifests. For me, it's > > always whole characters that are painted, they are always painted in > > what would otherwise be whitespace, and they tend to get "copied" to > > the next line in the whitespace as scrolling happens. In other words, > > it doesn't just seem like a fluke write during the transfer to VRAM. > > It seems like something in the engine is writing them, that the state > > is getting "stuck" somehow. Does any of that ring a bell/jog anything? > > Its quite possible. I did say before in the thread that it seems quite > possible to me that something isn't clearing the whitespace correctly. > But it's obviously rare, and I would expect that it's some piece of NS > port code rather than somewhere else. > > Unless there's something that's #ifdef'd out because at some point in > the past the NS port has behaved differently... > > But more likely if this is what's going on then it's going to be a bug > in the NS port. Unfortunately I don't really understand how the glyph > drawing side works, and never did. > > But if that's the case, why would removing the asynchronous call to > getContext fix so many problems? It's possible we have two very different problems that only appear related: 1. The one i'm seeing, which is sort of ghosting of other lines into the whitespace of nearby lines. The getContext call removal did not fix this for me, I saw it happen once. 2. The one Kai is seeing, that is exacerbated by decreasing the polling interval, but seems to be helped by removing the getContext call. > Something perhaps worth trying... Since removing the asynchronous call > to getContext fixes the problems, perhaps we need to think about the > "lazy" way we get the next buffer when the current one is displayed. > At the moment it just forgets about it until we want to draw to the > screen, at which point we call getContext and it creates the buffer if > necessary and copies the old one to the new one. > > Maybe we should get the new buffer and do the copy when we set the > current buffer for display... > > IIRC I avoided that because there isn't always time for the buffer to > have been sent to VRAM and unlocked before the *next* call to display, > so I wanted to leave it as long as possible between display and > getting the next buffer, but maybe this is just the wrong way to do > it. > > So I suppose putting a call to getContext right after "currentSurface > =3D=3D NULL" in display might be a quick and dirty way to test that. My problem is that at this point it happens so infrequently and I have no idea if that's because of the patches I'm trying or some other environmental thing or just luck. I'm going to try running without the async getContext and without the setNeedsDisplay for a while and see if it happens. Perhaps the setNeedsDisplay is somehow causing an issue and that's why changing it from source to dest seemed to help but it didn't alleviate it. If I see it again, I'll add the sync getContext call in, though I'll admit I do not understand your paragraph above starting with IIRC. Are you suspecting a potential problem with reading from the surface that is in the process of being copied to vram? Aaron