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 17:43:04 -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="3522"; 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 23:44:28 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 1qDB3U-0000hp-GE for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Jun 2023 23:44:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDB37-0003hC-GO; Sat, 24 Jun 2023 17:44:05 -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 1qDB35-0003fi-9F for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 17:44:03 -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 1qDB34-0007Ou-7V for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 17:44:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDB34-0007bU-3n for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 17:44:02 -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 21:44: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.168764300529131 (code B ref 63187); Sat, 24 Jun 2023 21:44:02 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 24 Jun 2023 21:43:25 +0000 Original-Received: from localhost ([127.0.0.1]:41606 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDB2S-0007Zm-QR for submit@debbugs.gnu.org; Sat, 24 Jun 2023 17:43:25 -0400 Original-Received: from mail-ed1-f52.google.com ([209.85.208.52]:54447) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDB2Q-0007ZP-D4 for 63187@debbugs.gnu.org; Sat, 24 Jun 2023 17:43:23 -0400 Original-Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-510d6b939bfso2432474a12.0 for <63187@debbugs.gnu.org>; Sat, 24 Jun 2023 14:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687642996; x=1690234996; 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=QS/xtYm38iN+QZrv6bXX2LUEEUSzJWDlbmHs7+9pXQA=; b=ki43ETekaE+dL8uCFGX3FOT9PDgfWYU/2VGGjYWdBmfLKR45GFkMI8TD1cuZTVzveT a5iKrEWFVBYPQLoAcaojReibaElKYWRHEj6uUnmbJ4G+YYhpPiU5DRWb0cmop4BamO7K H0LTOvBsjPLvMr3sp5E6B6GtbAD+6m4BlEfVr8wsgLhKexJZ1E4HDcam4u4zL9aqMr+/ cA0nirDSw9xmIPQoLvGlEVftDNT77PONpYzWsR8q3yYu4aFMPoB4nlVkg+XGk4/S3gR8 9J0XjH8meGqgK0BKOBPuSOVicfysbNDMHPFL0euk5yT9zZKMSV2QWMXMFZGnSwsPQF2c umsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687642996; x=1690234996; 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=QS/xtYm38iN+QZrv6bXX2LUEEUSzJWDlbmHs7+9pXQA=; b=ANKc/owjptkBZpu95lrHfRXVVnuY6NG1kLZy7+y2vd9QiEjzWiypEWE+FTLKgZDk3D 1Sallo8XzSyonR6UvAUTVzUY7O+oZ8xm+T5WhJcusgPHArNeFbXcowasu5ECexC1dFu8 IrwvmcZd8iTZdb90ed2w+0apI8aIvAQuc504ripEfQQfj1SjhTOLqKbQcGCtTA4Gg0Vi P0oQlO/bp7mvfRyfIgYMPdiKAXo1T2X5svFvBQqcuuhGJPl6y6KXeKHU5kfP039OcRY4 tGcLLMxAC8gTNyY2sHY5VOkYrKJVnP5pshoL2l6HZjEZlNjM3bjhKJ3qMg6BwfmJgWvX Ynlg== X-Gm-Message-State: AC+VfDyhuDrDV3BIcIib+TZvSH/8MPVUmsww3Xa21AVddNgjalyozPcc URvKZINf9Cr+2gy2YZqxpZBJzOva/NLl0T2rdMA= X-Google-Smtp-Source: ACHHUZ7Ot1/DjGxgorjGYNBtxmQvfA9CIwLmHPYTYTFXYhUbjPsOq/gc/ivH5Ae/4rxdLM7Ovd0QSXILINa9OO4Rksk= X-Received: by 2002:a05:6402:b0a:b0:51d:9339:1cd0 with SMTP id bm10-20020a0564020b0a00b0051d93391cd0mr219320edb.20.1687642995997; Sat, 24 Jun 2023 14:43:15 -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:264017 Archived-At: On Sat, Jun 24, 2023 at 5:29=E2=80=AFPM Alan Third wrote: > > On Sat, Jun 24, 2023 at 12:05:45PM -0400, Aaron Jensen wrote: > > > 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 rela= ted: > > 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. > > Yes, it might be two different things. > > > > Something perhaps worth trying... Since removing the asynchronous cal= l > > > 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 i= f > > > 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. > > OK > > > 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? > > Maybe... I'm really not sure what might be going on. > > My suspicion is that if we try to swap between the buffers too fast, > something is going wrong between the process of flushing the drawing > to the pixel buffer and copying the pixel buffer to the next one. Do we have any way to know when the flush is done? In other words, can we only return the surface to the pool after that? Or is that already done? > So, we have two buffers, A and B. We draw to A, but before we're done > the system calls display. We send off the incomplete buffer A to VRAM, > and then take a copy of that incomplete buffer for B. At some point > the system decides to flush the graphics context to the buffer, but > it's flushing to A, and we've *already* copied A to B. Can we avoid sending incomplete buffers? What is "done"? I don't know much about graphics programming but I imagine we don't want to send incomplete buffers ever, we want to finish painting the whole buffer, then send it. I think I'm also missing understanding on what it means to flush the graphics context to the buffer. Is that the drawing that we're doing (like rendering text/etc?) I feel like I may need a whiteboard session or something to get my head around this so that I can be of any assistance other than asking dumb questions :) > This would possibly explain why Kai lowering the polling interval > induces the issue, as it may increase the frequency at which the > screen is updated beyond the point where we're able to keep up. > > To be honest though, I feel it should all be pretty linear and this > idea implies things are happening out-of-order. So I'm not convinced > I'm right. > > > Who knows. Maybe all we need to do is make sure we don't try to draw > to the screen while emacs is drawing to the buffer... Something like > this: > > modified src/nsterm.m @@ -10622,7 +10622,7 @@ - (void) display > { > NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "[EmacsLayer display]"); > > - if (context) > + if (context && context !=3D [NSGraphicsContext currentContext]) > { > [self releaseContext]; > > > ... > > Actually... > > That change should probably be made anyway. If the NS run loop kicks > in between an ns_focus call and an ns_unfocus call, it could call > display and our display function will happily destroy the existing > context without creating a new one, so any *subsequent* drawing > operations, up until ns_unfocus, will be lost. OK, I'm adding this to my current build. Is this in line with the type of issue I'm seeing where scrolling works but the ghosting either replicates (or scrolls with it?) In other words, what would you expect to see in this scenario? Would it just stop painting entirely? > > I'm not sure if that's a legitimate concern... =F0=9F=98=95 > > > I've got too many ideas about how to fix it and no way to actually try > them out, never mind the difficulty of inducing the issue if I did. I'm happy to try things if you don't mind a 1-2 week feedback cycle (since lately that's about how long it takes for me to see an issue...