From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: [NS] Emacs 28 (IOSurface) renders much slower than Emacs 27 on macOS Big Sur Date: Sun, 2 May 2021 23:50:28 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15327"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Yiming Chen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 03 00:51:39 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 1ldKw7-0003sr-Kn for ged-emacs-devel@m.gmane-mx.org; Mon, 03 May 2021 00:51:39 +0200 Original-Received: from localhost ([::1]:54196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldKw6-0004mj-LW for ged-emacs-devel@m.gmane-mx.org; Sun, 02 May 2021 18:51:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldKvF-0004DH-AF for emacs-devel@gnu.org; Sun, 02 May 2021 18:50:45 -0400 Original-Received: from outbound.soverin.net ([116.202.65.218]:37367) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldKvC-0002BA-En for emacs-devel@gnu.org; Sun, 02 May 2021 18:50:44 -0400 Original-Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 7AB7060109; Sun, 2 May 2021 22:50:32 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1619995831; bh=tWVHX3rcYggHP3eFZcKceHxLRgg+I1WwLRBcVtyTad8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lyMLy4/f7lkCPSRbSk73OX2fsYsjwzh4TUXrnV4GsJ5ub/zNAry7QGcYi++3Ep+tB myN8CW1qJCyMl1IXSQzgjmDRH5tU88y0NQeQ9I3fXqDA7Gqh1K37WMlhIi0f+iGqLs CJr4NFDlC/F7jlKOWlXsw7KZO4mqQBWRa5lfRTagtd1gLHnkDnQzqROBxP2zTSdU9t fhPu44or+OVPye1ttbFWu+YUZ9Yqij9uGC3M/5cSoRRvi5BCzIXAaxoUtt1EkDwYku f1yKIqXZDnH4VAzWUDTU9j+rrSBwwCC3AJdC7aCv84XmMm7MQaWKixJb/Svtx748RF zEuPbCkqUK6sw== Original-Received: from alan by faroe.holly.idiocy.org with local (Exim 4.94) (envelope-from ) id 1ldKuz-0005Q9-0L; Sun, 02 May 2021 23:50:29 +0100 Mail-Followup-To: Alan Third , Yiming Chen , emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=116.202.65.218; envelope-from=alan@idiocy.org; helo=outbound.soverin.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:268787 Archived-At: On Sun, May 02, 2021 at 09:40:03PM +0800, Yiming Chen wrote: > 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. Yup. That's the trade-off. > 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 over a year on-and-off on this. Good luck. > 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 ‘Menlo’ is not > defined' That error must be something unrelated, as the drawing buffer changes didn't touch the font code... I've got no suggestions on where to start, though. My knowledge of font handling is non-existent. Actually, a quick look shows that you've enabled the nsfont backend which just doesn't work in macOS, so I'd bet that's something to investigate. I notice quite a few other problems... If I'm being honest, master has diverged so much from emacs-27 that if I were to do this I'd probably do it manually rather than try reverting commits. And I disagree that master is more complex than emacs-27. The endless little work-arounds to try and get the emacs-27 rendering working made it a much more brittle setup. > 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. So... yes. The IOSurface system is already using layer-based drawing. Have a look at updateLayer, for example. I'm not sure that CALayer really gives you anything in terms of performance for this sort of thing. CoreAnimation is all about moving different layers about efficiently, afaict, which isn't something we need to do in Emacs. And bear in mind that in order to send an image to the Metal renderer you still need to transfer it to the GPU, and Apple recommend using IOSurface as it's the most efficient way to do that. AND Yamamoto Mitsuharu disabled Metal rendering in the Mac port as he found the simple IOSurface based layer backing was faster. AND the Chromium developers decided to go with the simple IOSurface based layer backing for performance reasons too. One place that a big improvement could be found is in disabling double buffering and only drawing to one IOSurface, as you don't need to copy the contents of the different IOSurfaces to each other. But I found that produced unacceptable tearing effects. But all that said, it could be that copying viewWillDraw from master to emacs-27 could solve some of the flickering. In my experimentation I don't believe it does, but I've never been very good at inducing the "flickering". -- Alan Third