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 10:52:08 -0400 Message-ID: References: <29949E40-D5D5-4DE1-BD81-93D1BA3D4F51@gmail.com> <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="4987"; 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 16:53: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 1qD4dk-00013o-C3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 24 Jun 2023 16:53:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qD4dL-0003yY-BH; Sat, 24 Jun 2023 10:53: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 1qD4dK-0003yL-SB for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 10:53: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 1qD4dK-0000ld-Je for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 10:53:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qD4dK-0004tX-2N for bug-gnu-emacs@gnu.org; Sat, 24 Jun 2023 10:53: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 14:53: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.168761835118775 (code B ref 63187); Sat, 24 Jun 2023 14:53:02 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 24 Jun 2023 14:52:31 +0000 Original-Received: from localhost ([127.0.0.1]:41233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qD4co-0004sl-R6 for submit@debbugs.gnu.org; Sat, 24 Jun 2023 10:52:31 -0400 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:54591) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qD4ck-0004sW-FG for 63187@debbugs.gnu.org; Sat, 24 Jun 2023 10:52:29 -0400 Original-Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-51bece5d935so2022285a12.1 for <63187@debbugs.gnu.org>; Sat, 24 Jun 2023 07:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687618340; x=1690210340; 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=niu+awRhswq9gblf3GXSlyjNpIPLsKMGFkSI5bq6ZEo=; b=ZV3nSt0iWovyL+1MF9WYTPcQRk73LXb2pja2Gg6SDZvfLi57cyzLH9sFAZUIYet6yn aFeHBUDaxfP2P9YwXOeG4MkfQZc8EdQfaGZij9dXxMMo1Dsd1ZhHqpzXoXxiWupz9acs 2chqyiGGZ6edz7ASHCxCRrsGp4rHBgOLGRYyRRMg8Gybdf1nDOMO2beGLN1MB97pAKkt pJLA+g6RogozTcQmqBZSvcwwz4w8jzbNoZoctjONw5TuvSkaCCqOvMQYric8sBaQbYXf SfX7FWkeS8I4bLbWlBkQOWN+s5iOsjMNyiULtiJBxBembfJG9RDsswMoN6+X0Q4m9ukT mkAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687618340; x=1690210340; 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=niu+awRhswq9gblf3GXSlyjNpIPLsKMGFkSI5bq6ZEo=; b=XWwEvaSXXeK5Sqs2+uqnzQ+2lrghCBBQwAMnYbCfFsYRZC8nSURqMlA9iw+DYAuIg1 5p0vvx1A8X1B9b2mcXnyvmV15X/zPvHEUKrtbXfTp2qMuWzUCpUq8y2YiQBX0qIcMagJ PDFOp+yOJAg6k4mrFDXUTGLONQuiXFXgYtPfpA7nmPZu9JmG6V3kqqH/22hAknLMiLdM QtTD7NvAK9mizRf5/DHq0vU9BkVbAAhnkgfyNjWG0IBRdNoJiw5XQSQwHuNE28mOTvwy gJypVZel9o/l4HDkSebnJ+JER4GIsmzAOiWYIA0qXa+IVSpRNX/h8IekWsKFVEZUWf+0 Lauw== X-Gm-Message-State: AC+VfDwGu5MJu/NuOA6hM9Q4BdHXR8pughm0GgAuIQMPpf1ZqI2p+DiU H/AwKKwJtaxmIUFi4OfXSkc/c9pmd3Rnlusm6y8= X-Google-Smtp-Source: ACHHUZ7wovtQ6KDRFrsrY/tuIYJpAiazLGHScHXaMz9d6mrLM8YdSWWcg8to6JWtw03xl4RwrW3g2VBIMXXbDKaNmrA= X-Received: by 2002:aa7:dad2:0:b0:51a:597e:c3f2 with SMTP id x18-20020aa7dad2000000b0051a597ec3f2mr13508973eds.5.1687618340267; Sat, 24 Jun 2023 07:52:20 -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:263995 Archived-At: On Sat, Jun 24, 2023 at 10:14=E2=80=AFAM Alan Third wrote= : > > 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? > As I recall locking is really just setting a flag saying it's > currently being used so nobody else should touch it, it doesn't stop > you from doing things with it. > > I know, for example, that it's possible to write to a surface that's > been locked by the transfer to VRAM, and that results in tearing > effects where the copy in VRAM is half updated. The VRAM copy isn't > ever copied back down to system RAM, though, so it doesn't have any > permanent consequences beyond a tearing effect at that particular > moment. 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? Aaron