From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yiming Chen Newsgroups: gmane.emacs.devel Subject: [NS] Emacs 28 (IOSurface) renders much slower than Emacs 27 on macOS Big Sur Date: Sun, 02 May 2021 21:40:03 +0800 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21516"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.15; emacs 27.2 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 02 19:10:44 2021 Return-path: Envelope-to: ged-emacs-devel@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 1ldFcB-0005Vt-RR for ged-emacs-devel@m.gmane-mx.org; Sun, 02 May 2021 19:10:43 +0200 Original-Received: from localhost ([::1]:56986 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldFcA-00074N-Rp for ged-emacs-devel@m.gmane-mx.org; Sun, 02 May 2021 13:10:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48510) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldD0a-00059r-Fp for emacs-devel@gnu.org; Sun, 02 May 2021 10:23:44 -0400 Original-Received: from mail-pj1-f45.google.com ([209.85.216.45]:37447) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ldD0Y-0000gr-6t for emacs-devel@gnu.org; Sun, 02 May 2021 10:23:44 -0400 Original-Received: by mail-pj1-f45.google.com with SMTP id k3-20020a17090ad083b0290155b934a295so4277626pju.2 for ; Sun, 02 May 2021 07:23:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:message-id :mime-version; bh=WpNY9KGi8fzDlofONuqAOBV0XQna3LTB+usTJtbTcfA=; b=Ba9nWKgM224ZRphESPxx+T+X+NTy37/n80nG4nNHmNNro+HW9vaV2PkATl0QfzJi0S OE/hhganxw9NRyBkY7TXIkHUaJITO6yeYs2KfUDg30rJ30TuZDghH+3e5ZX1hj3DV8Ws Md5/mTILDMS642p9MtzMGwzgMAy34walBwlJUhUQcEQOGs9R8c/94uuRWhwWvrpSVW+x 3vo6DqZMnPeiWIDFDm4e4pnuEQjB+lBeDRA1ZF8SEwa1/yALFUr3T7rEaP/NpKwUfYCo Pp3WUglj3PHr+O6Wyhrea6Bdzvrt7i9V1xynLPUIflA2wwJVCPk/tgE3tG+7I3zifQ2/ oYtA== X-Gm-Message-State: AOAM530OxrlVE7TAaEmh7FWfTTpGGVBcCRvSUXgamTAIKb3ZyTsCcknn sHRZcFp57sLLFS7/wStle18n2OwRWnU= X-Google-Smtp-Source: ABdhPJwevI+CFSDTbxex2WJyM8j0MQE36dazxJRpQVZQxRCyqo7UZoi5Um+kmGGGc3THqDOSmBgq7Q== X-Received: by 2002:a17:90b:786:: with SMTP id l6mr13369157pjz.182.1619965419463; Sun, 02 May 2021 07:23:39 -0700 (PDT) Original-Received: from Yiming-Chen-MacBook-Pro ([45.138.210.41]) by smtp.gmail.com with ESMTPSA id bx12sm7766777pjb.1.2021.05.02.07.23.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 May 2021 07:23:38 -0700 (PDT) Received-SPF: pass client-ip=209.85.216.45; envelope-from=dsdshcym@gmail.com; helo=mail-pj1-f45.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 02 May 2021 13:03:47 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268777 Archived-At: --=-=-= Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Hi there!
I know that we've switched to a IOSurface based rendering for nsterm in mas= ter branch.
Now master renders more precisely than emacs-27 (i.e. less flickers or blan= k screens.)
But I feel that its rendering performance is much worse due to the new buff= ering mechanism backed by IOSurface.

Several cases that I can feel this worse performance:

  1. moving a maximized emacs frame= from a larger screen to a smaller screen (I use hammerspoon to do that) I can see the emacs-28 frame shrink to the smaller screen size, then move t= o the smaller screen

  2. scrolling
    I set scroll-conservatively to 101 in order to achieve the smooth-scro= lling effect.
    When I scroll down a large text buffer constantly (hold j in evil-mode= or C-n in emacs-mode),
    emacs-28 hangs more times than emacs-27 (emacs-27 scrolls very smoothly exc= ept it would flicker from time to time)

    See also https://www.reddi= t.com/r/emacs/comments/mhdjxb/macos_emacs_with_metal_support/guhbck4/ f= or a previous discussion.

  3. child-frame
    child-frame like company-box appears more slowly in emacs-28 than emacs-27<= br/>

Sorry I haven't found a way to measure the rendering performance except the= s= croll-up-benchmark script from Alan Third in the reddit comment ment= ioned above.

I think this poor rendering performance obscures the improvements brought b= y native-compile.
So I want to fix this performance issue and make Emacs runs on macOS as fas= t as on Linux.

I've spent the last several days trying to understand how nsterm works and = if we can use a more efficient rendering API.
But I failed completely, mostly because I have no Cocoa development experie= nce before.
Here are the 3 steps I want to take to improve the rendering performance:

  1. Try to restore the nsterm behavior from Emacs27 (which is much simpler than= master IMHO), and start again from there

    I've reverted the code and made it compile (see https://github.com/emacs-mirror/emacs/compare/mast= er...dsdshcym:revert-to-emacs-27-nsterm)
    But Emacs failed to start and raised an error Font =E2=80=98Menlo=E2=80=99 is= not defined

  2. Use layer-based view for rendering

    I found that macvim also faced the similar issue when macOS 10.14 came out = (https://github.com/macvim-dev/macvim/issues/751).
    They used NSImage to implement a double rendering solution (h= ttps://github.com/macvim-dev/macvim/pull/757/files), which was also slo= wer than before.
    Then they switched from NSImage to layer-based view in https://github.com/macvim-dev/macvim/commit/dba6= 293677e0633917e3054cfddec1293e5ab3fb.
    So I wonder if we can do the same.

  3. Switch to CALayer (Core Animation) to use GPU (Metal) rendering for even be= tter performance than before

    If 2 (layer-based view) is possible, then I hope we can leverage CALayer to= make nsterm renders even faster.

I was so desperate about this issue, so I also tried other window systems o= n macOS:

  1. emacs-pgtk (https://github= .com/masm11/emacs/issues/95):
    technically emacs-pgtk should work on macOS with gtk3, but the performance = was even worse
  2. emacs-ng + webrender (https://= github.com/emacs-ng/emacs-ng/issues/207)
    webrender hasn't been working on macOS neither

If anyone can point a direction for me so I can investigate more, that woul= d be the best.
Thanks in advance!

Cheers,
Yiming

--=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi there! I know that we've switched to a IOSurface based rendering for nsterm in master branch. Now master renders more precisely than emacs-27 (i.e. less flickers or blank screens.) But I feel that its rendering performance is much worse due to the new buffering mechanism backed by IOSurface. Several cases that I can feel this worse performance: 1. moving a maximized emacs frame from a larger screen to a smaller screen (I use hammerspoon to do that) I can see the emacs-28 frame shrink to the smaller screen size, then move to the smaller screen 2. scrolling I set `scroll-conservatively' to 101 in order to achieve the smooth-scrolling effect. When I scroll down a large text buffer constantly (hold `j' in evil-mode or `C-n' in emacs-mode), emacs-28 hangs more times than emacs-27 (emacs-27 scrolls very smoothly except it would flicker from time to time) See also for a previous discussion. 3. child-frame child-frame like company-box appears more slowly in emacs-28 than emacs-27 Sorry I haven't found a way to measure the rendering performance except the `scroll-up-benchmark' script from Alan Third in the reddit comment mentioned above. I think this poor rendering performance obscures the improvements brought by native-compile. So I want to fix this performance issue and make Emacs runs on macOS as fast as on Linux. I've spent the last several days trying to understand how nsterm works and if we can use a more efficient rendering API. But I failed completely, mostly because I have no Cocoa development experience before. Here are the 3 steps I want to take to improve the rendering performance: 1. Try to restore the nsterm behavior from Emacs27 (which is much simpler than master IMHO), and start again from there I've reverted the code and made it compile (see ) But Emacs failed to start and raised an error `Font =E2=80=98Menlo=E2=80= =99 is not defined' 2. Use layer-based view for rendering I found that macvim also faced the similar issue when macOS 10.14 came out (). They used NSImage to implement a double rendering solution (), which was also slower than before. Then they switched from NSImage to layer-based view in . So I wonder if we can do the same. 3. Switch to CALayer (Core Animation) to use GPU (Metal) rendering for even better performance than before If 2 (layer-based view) is possible, then I hope we can leverage CALayer to make nsterm renders even faster. I was so desperate about this issue, so I also tried other window systems on macOS: 1. emacs-pgtk (): technically emacs-pgtk should work on macOS with gtk3, but the performance was even worse 2. emacs-ng + webrender () webrender hasn't been working on macOS neither If anyone can point a direction for me so I can investigate more, that would be the best. Thanks in advance! Cheers, Yiming --=-=-=--