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: Sun, 25 Jun 2023 18:33:09 -0400 Message-ID: References: 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="37744"; 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 26 00:34:16 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 1qDYJE-0009ZX-Ab for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 26 Jun 2023 00:34:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qDYJ1-0001Le-I9; Sun, 25 Jun 2023 18:34: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 1qDYJ0-0001LT-3O for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 18:34: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 1qDYIz-0003dV-Qo for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 18:34:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qDYIz-0000c2-M0 for bug-gnu-emacs@gnu.org; Sun, 25 Jun 2023 18:34: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: Sun, 25 Jun 2023 22:34: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.16877324092304 (code B ref 63187); Sun, 25 Jun 2023 22:34:01 +0000 Original-Received: (at 63187) by debbugs.gnu.org; 25 Jun 2023 22:33:29 +0000 Original-Received: from localhost ([127.0.0.1]:43936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDYIT-0000b5-8T for submit@debbugs.gnu.org; Sun, 25 Jun 2023 18:33:29 -0400 Original-Received: from mail-ed1-f54.google.com ([209.85.208.54]:58652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qDYIR-0000at-OS for 63187@debbugs.gnu.org; Sun, 25 Jun 2023 18:33:28 -0400 Original-Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-51d89664272so2086909a12.1 for <63187@debbugs.gnu.org>; Sun, 25 Jun 2023 15:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687732402; x=1690324402; 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=+uqQw1+FzO4L3h47B9dUmgXLFsxme4atEGIanVgOovk=; b=GQnjZscYgy076zUD9V4LugzlwfLCCG/oKK/ObdkjBggtwSVsUlvRvMq0JxlA9bqD1T +KcUJsz8FGYQGCWXFK/SeH8CLP43YPTusq0YbYa3SCLMjSQoqovEcvHvjpvf3VVaGVu5 j/V+gsfV0h2MuC31LN5G1UaR5vmVBLNAgdVI1Q0LMOZSXy1fJL/rTfZbOl9r79YeWrnz +Jv+dbsl2JtOEda6O9hQBMlrm994gax3ppRtDIRtI0lX2tpOgSf5S/RyX5AJMSxkupU8 qwh6SScUhBfFylSq+nvVFD0YOtOcM8Ic+Qm4va8p2YH2j43cj7iug+SSUfTDTHX7TS2+ AD8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687732402; x=1690324402; 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=+uqQw1+FzO4L3h47B9dUmgXLFsxme4atEGIanVgOovk=; b=V6cMvyapzjD/62EU8kngDkekzzLteO5ANOzrs/joBJ+C0jfos0Iq+aE3MbffrM5DtA 9EnBP9sWGXeBfvw0sJbJ/XGC40w99dtxT1VDvBOdZyD0J5L28Duc9oCxVd6A+jdWZxhd W0726YlsTblVWrGCb3LPynum6pBUR/kHxAyY+nfumW1cmopA0LBqzICRtTeRC2EJ7U+K ciAoFvHMpJGkQiDWiSVrt4eM+/oT56qCyRIiGOMLlcp5kLB+4XEjUp48ieLSV6c8ddJx 22TMpxWUyufEBwFuyHOdiN0HBhYgFWe9Zp8jQbnd3oMEd4NFfXT48HfI1Dvi8aZRw2H8 cRrg== X-Gm-Message-State: AC+VfDw6wXJXZvn1Mz0zeJBbY7uAvPemC6Dun969bRMIZHiKUcbX4Tf3 TSdnpxRj8mmOSI9xwKsmaGPzeMCXnKTLOCqx98M= X-Google-Smtp-Source: ACHHUZ6spw9AT6E4zO0altBOYXaBIgnoy8lT/L5UGshDScHvtUBsiLRKvw3eUp5SPyBrE17bhV4jMNVwjYxSz/mRXXA= X-Received: by 2002:aa7:d784:0:b0:51b:d49c:8c36 with SMTP id s4-20020aa7d784000000b0051bd49c8c36mr12316531edq.16.1687732401470; Sun, 25 Jun 2023 15:33:21 -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:264073 Archived-At: On Sun, Jun 25, 2023 at 5:18=E2=80=AFPM Alan Third wrote: > > On Sun, Jun 25, 2023 at 03:07:39PM -0400, Aaron Jensen wrote: > > On Sun, Jun 25, 2023 at 2:17=E2=80=AFPM Alan Third wr= ote: > > > No, you can use [NSGraphicsContext flushGraphics] and CGContextFlush > > > to force it. > > > > OK, that makes sense, but it's hard to find definitive documentation > > of that (and ChatGPT seems to think that it's not true, but that's > > likely a hallucination): > > > > =3D=3D=3D=3D=3DSTART GPT=3D=3D=3D=3D=3D > > [NSGraphicsContext flushGraphics] (in Cocoa) and CGContextFlush (in > > Core Graphics) are used to bypass this batching process and force any > > pending drawing commands to be executed immediately. After calling > > these methods, you can be sure that all your previously issued drawing > > commands have been sent to the GPU. > > > > However, it's important to understand that while these functions > > ensure that the commands are sent to the GPU, they don't guarantee > > that the GPU has finished executing them. The actual rendering work is > > still done asynchronously by the GPU. > > > > So if you need to read back the results of your rendering (e.g., from > > an IOSurface), there might still be a brief period where the rendering > > hasn't completed yet, even after calling flushGraphics or > > CGContextFlush. If you need to ensure that all GPU rendering work is > > complete before you proceed, you would typically need to use a more > > low-level API (like Metal or OpenGL) that provides explicit > > synchronization capabilities. > > > > ... > > > > Regarding your question about the [NSGraphicsContext flushGraphics] > > and CGContextFlush, here are the descriptions directly from Apple's > > documentation: > > > > [NSGraphicsContext flushGraphics]: "Forces any buffered drawing > > commands to be sent to the destination." > > > > CGContextFlush: "Forces all drawing operations to be completed in the > > specified context." > > > > It's important to understand these function calls ensure that drawing > > commands are dispatched, not that they are completed. This is an > > inference based on understanding of how graphics pipelines generally > > work. For more detailed behavior and how these calls interact with > > your specific use-case, you should refer to Apple's documentation and > > guides, or consider reaching out to Apple's developer support. > > =3D=3D=3D=3D=3DEND GPT=3D=3D=3D=3D=3D > > The GPU isn't involved in this part. We're drawing to an IOSurface, > which is a buffer in system memory. So when we draw and flush the > graphics it's all done by the CPU in system memory. > > Then we put the IOSurfaceRef in the contents variable of the layer and > at that point the GPU uses DMA to copy the buffer from system memory > to GPU memory. While this is happening the IOSurface is locked so we > know we shouldn't use it. > > Once it's in GPU memory, the GPU blits it to the screenbuffer or > something, but by that time the IOSurface should be unlocked and we > can start (safely) working on it again. OK, that's clarifying, thank you. > > > Set CACHE_MAX_SIZE to 1. > > > > > > But on my machine this resulted in unacceptable rendering flaws on > > > almost all animated gifs as partially drawn buffers were sent to VRAM= . > > > > What did you see? > > I tried with this: > > > > https://share.cleanshot.com/vJTClHW9 > > > > And I didn't notice anything drawing related, but I have an M1 with > > integrated memory. > > Lots of white space. I thought that it was being caught either just > before or as the image was being drawn into the buffer, so some > portion of the image area was blank. Interesting. Would: + if (context && context !=3D [NSGraphicsContext currentContext]) have impacted that in any way? Aaron