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: Mon, 19 Jun 2023 11:46:30 -0400 Message-ID: References: <50104E0C-A861-4762-8081-55F2CF2390AD@gmail.com> <76A3A6C3-CD32-4731-927C-349471F21801@gmail.com> <2A505E20-55E2-4788-A21C-B94068299E50@gmail.com> <29949E40-D5D5-4DE1-BD81-93D1BA3D4F51@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="5140"; 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 Mon Jun 19 17:47:17 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 1qBH64-00015o-F8 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 19 Jun 2023 17:47:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qBH5r-0003lX-1W; Mon, 19 Jun 2023 11:47: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 1qBH5q-0003kx-9x for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2023 11:47: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 1qBH5q-0002Cc-0h for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2023 11:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qBH5p-0003Gf-So for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2023 11:47: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: Mon, 19 Jun 2023 15:47: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.168718961212544 (code B ref 63187); Mon, 19 Jun 2023 15:47:01 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 19 Jun 2023 15:46:52 +0000 Original-Received: from localhost ([127.0.0.1]:57071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBH5f-0003GF-F3 for submit@debbugs.gnu.org; Mon, 19 Jun 2023 11:46:51 -0400 Original-Received: from mail-ed1-f46.google.com ([209.85.208.46]:60710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qBH5c-0003Fx-Gg for 63187@debbugs.gnu.org; Mon, 19 Jun 2023 11:46:49 -0400 Original-Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-51a4088c4ebso3212625a12.1 for <63187@debbugs.gnu.org>; Mon, 19 Jun 2023 08:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687189602; x=1689781602; 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=H9P19J18FKzkSNW5r9sKO0AOigMl9jjvCFCuXmA2+PM=; b=ddDcC/0vQBImuZkV07SXSn2qS4DeFDnNQbG/34rltvepPWH5UyMc7D4qmR00jIRzBs cTAXmRtHZqxh6GhoLam3buUTBmr5s89sbpnOIPiKWau0ARaQf/rdahfN6Wmc1IDvHwiw IcK4Zd2e6XDDILIj0bjVmX01ra+JYbGs2cZGq0VnHWVW+IhZECU9mZzYh+yTjw/ZKUoE /8KVabX8bm8KZ+dSulvENTBXFpiSK+3bKfYWtQSMaxK/qQmwaoeUCO0dNm6YL44X+7dV K31ZzhaYM7Clo+/yDq6dFUJ+UxR8almFNExmV+vXmLP3AB3gXqhsZZh1rEtN4ipg/fxc RM6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687189602; x=1689781602; 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=H9P19J18FKzkSNW5r9sKO0AOigMl9jjvCFCuXmA2+PM=; b=Yj/tvVvgf24G8t8wOg+HlHyipFnCgMaphTZLvk0DmWGEAUzYpkOqxowLfaVBV4k91K LdputWaLoLYHYudnTRHktq3Xt3YDrrQEUdweQIOxhmbFJpF1lFeNEVNBO44ag7PsntCd BkMBObgth5qVy4hbI3hGYDx/GNNQ3soOUVXvUjBC7XCZeeWfR++M2NAs4jiSu0hV4bn2 bTcCtyRYtqq1HGAGFsfXeS6D0oQPIdDBoSHwYDSij01gwH/iD7iobKLNInMJIJ4DTMuu PDG8UtEt9CJY9i+UJDwVPN14U17pUJCkx1T53Qnf8gQsEoyPicXgGnwOdsQHz0xNFLO3 ETAw== X-Gm-Message-State: AC+VfDz2cZF1RVY1AepI8pJUwtkjuKjCQ6LQmTyst7i/MS/c9BxhGEJS AD++vh6sXiXz1N6JJKEu1L4i7N4o7C10DZIPxc8= X-Google-Smtp-Source: ACHHUZ6sikQM/OmDf5A4muEy9e82efh3FUSWp51c+b3E/Ba3LuNVDE49k++lr72DCfDhX7bnVbUxZfCzAF9a9IQlJGI= X-Received: by 2002:a05:6402:21a:b0:518:7a51:7e97 with SMTP id t26-20020a056402021a00b005187a517e97mr5962208edv.36.1687189602304; Mon, 19 Jun 2023 08:46:42 -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:263689 Archived-At: On Thu, Jun 15, 2023 at 10:17=E2=80=AFPM Aaron Jensen wrote: > > On Mon, Jun 12, 2023 at 9:04=E2=80=AFAM Aaron Jensen wrote: > > > > On Fri, Jun 9, 2023 at 4:00=E2=80=AFPM Alan Third wro= te: > > > > > > On Fri, Jun 09, 2023 at 02:46:29PM -0400, Aaron Jensen wrote: > > > > On Fri, Jun 9, 2023 at 2:27=E2=80=AFPM Alan Third = wrote: > > > > > It seems to me that removing the call to performSelectorOnMainThr= ead > > > > > should be done. That may even fix Aaron's original issue too, giv= en > > > > > that I don't know why calling setNeedsDisplayInRect twice in a ro= w > > > > > should help, especially given it's not actually used anywhere els= e in > > > > > the display code. > > > > > > > > How is it called twice? Does copyRect mark for redisplay? > > > > > > Sorry, I had misunderstood your change. > > > > > > Either way, I don't see how it's made a difference. > > > setNeedsDisplayInRect is telling the system which parts it needs to > > > call drawRect on, but we don't use drawRect any more, so I would thin= k > > > all it can be doing is setting the needsDisplay boolean to true. > > > > > > copyRect definitely doesn't do anything with the rectangle. It deals > > > with the bitmap's pixel data directly, so there's no clipping or > > > anything else affecting it and it's changes don't need to be > > > committed to some backing store. > > > > > > Even when it comes to actually displaying the view on the screen, we > > > pass in the entire bitmap to the graphics subsystem and it > > > (supposedly) displays it in it's entirety. > > > > > > So as I understand it the rectangle passed into setNeedsDisplayInRect > > > doesn't do anything. I think that call in ns_scroll_run was left ther= e > > > by mistake. It's literally the only call to it in the entire nsterm.m > > > file. > > > > > > But you report that it has fixed your problem. I can't explain that > > > because it runs counter to my understanding of how macOS draws. > > > > > > But then again, none of this is documented in any in-depth way by > > > Apple, so who knows what's REALLY going on. > > > > > > Patch attached, but it's untested. It may even make things worse. I'm > > > happy to leave it up to you to decide what to do since you're in a > > > better position to tell if any given change actually helps. > > > > Thanks, I'm trying it out now. I'll report back in a bit. If it's fine > > I'll try removing the setNeedsDisplay as well and try again. > > I saw a paint issue today. The "<" to the left of the indented (and > redacted) lines 65-68 was an artifact. It kept painting there even > while scrolling until I resized the window, then they all disappeared. > They appeared one at a time while scrolling, as if the painting of one > the one on line 63 was "fixed" in the window position as I was > scrolling (likely it just didn't get cleared as necessary). Kai, could you try this patch out. It's a total guess, but let me know if it does any better for you. diff --git a/src/nsterm.h b/src/nsterm.h index b6e5a813a6d..4f6c6f7c28b 100644 --- a/src/nsterm.h +++ b/src/nsterm.h @@ -1384,3 +1384,11 @@ #define NSButtonTypeMomentaryPushIn NSMomentaryPushInButton extern void mark_nsterm (void); #endif /* HAVE_NS */ + +#define AJTRACE(...) \ + do = \ + { = \ + fprintf (stderr, __VA_ARGS__); = \ + putc ('\n', stderr); \ + } = \ + while(0) diff --git a/src/nsterm.m b/src/nsterm.m index 3e089cc1ff1..5a92f4cda0b 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -2708,9 +2708,9 @@ Hide the window (X11 semantics) EmacsView *view =3D FRAME_NS_VIEW (f); [view copyRect:srcRect to:dest]; -#ifdef NS_IMPL_COCOA - [view setNeedsDisplayInRect:destRect]; -#endif +// #ifdef NS_IMPL_COCOA +// [view setNeedsDisplayInRect:destRect]; +// #endif } unblock_input (); @@ -10636,9 +10636,9 @@ - (void) display /* Schedule a run of getContext so that if Emacs is idle it will perform the buffer copy, etc. */ - [self performSelectorOnMainThread:@selector (getContext) - withObject:nil - waitUntilDone:NO]; + // [self performSelectorOnMainThread:@selector (getContext) + // withObject:nil + // waitUntilDone:NO]; } } @@ -10651,6 +10651,7 @@ - (void) copyContentsTo: (IOSurfaceRef) destination IOReturn lockStatus; IOSurfaceRef source =3D (IOSurfaceRef)[self contents]; void *sourceData, *destinationData; + int seed1 =3D 0, seed2 =3D 1; int numBytes =3D IOSurfaceGetAllocSize (destination); NSTRACE_WHEN (NSTRACE_GROUP_FOCUS, "[EmacsLayer copyContentsTo:]"); @@ -10662,14 +10663,31 @@ - (void) copyContentsTo: (IOSurfaceRef) destinati= on if (lockStatus !=3D kIOReturnSuccess) NSLog (@"Failed to lock source surface: %x", lockStatus); + lockStatus =3D IOSurfaceLock (destination, kIOSurfaceLockAvoidSync, nil)= ; + if (lockStatus !=3D kIOReturnSuccess) + NSLog (@"Failed to lock destination surface: %x", lockStatus); + sourceData =3D IOSurfaceGetBaseAddress (source); destinationData =3D IOSurfaceGetBaseAddress (destination); - /* Since every IOSurface should have the exact same settings, a - memcpy seems like the fastest way to copy the data from one to - the other. */ - memcpy (destinationData, sourceData, numBytes); + while (seed1 !=3D seed2) + { + seed1 =3D IOSurfaceGetSeed (source); + + /* Since every IOSurface should have the exact same settings, a + memcpy seems like the fastest way to copy the data from one to + the other. */ + memcpy (destinationData, sourceData, numBytes); + seed2 =3D IOSurfaceGetSeed (source); + if (seed1 !=3D seed2) { + AJTRACE ("SEED DO NOT MATCH"); + } + } + + lockStatus =3D IOSurfaceUnlock (destination, kIOSurfaceLockAvoidSync, ni= l); + if (lockStatus !=3D kIOReturnSuccess) + NSLog (@"Failed to unlock destination surface: %x", lockStatus); lockStatus =3D IOSurfaceUnlock (source, kIOSurfaceLockReadOnly, nil); if (lockStatus !=3D kIOReturnSuccess) NSLog (@"Failed to unlock source surface: %x", lockStatus);