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: macOS metal rendering engine in mac port Date: Fri, 21 May 2021 18:39:08 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27558"; mail-complaints-to="usenet@ciao.gmane.io" Cc: YAMAMOTO Mitsuharu , emacs-devel@gnu.org To: Aaron Jensen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 21 19:42:52 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 1lk9Ai-0006xI-GZ for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 19:42:52 +0200 Original-Received: from localhost ([::1]:35990 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lk9Ag-0003xq-Jq for ged-emacs-devel@m.gmane-mx.org; Fri, 21 May 2021 13:42:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lk98A-0001GF-9Z for emacs-devel@gnu.org; Fri, 21 May 2021 13:40:15 -0400 Original-Received: from [217.169.17.33] (port=56382 helo=breton.holly.idiocy.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lk988-0004eS-3k for emacs-devel@gnu.org; Fri, 21 May 2021 13:40:14 -0400 Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id CDFD3202C16D9A; Fri, 21 May 2021 18:39:08 +0100 (BST) Mail-Followup-To: Alan Third , Aaron Jensen , emacs-devel@gnu.org, YAMAMOTO Mitsuharu Content-Disposition: inline In-Reply-To: X-Host-Lookup-Failed: Reverse DNS lookup failed for 217.169.17.33 (failed) Received-SPF: none client-ip=217.169.17.33; envelope-from=alan@breton.holly.idiocy.org; helo=breton.holly.idiocy.org X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no 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:269573 Archived-At: On Fri, May 21, 2021 at 08:27:14AM -0700, Aaron Jensen wrote: > On Fri, May 21, 2021 at 12:35 AM Alan Third wrote: > > > > Out of interest, is it the metal renderer making the difference, or is > > the Mac port just better anyway? > > > > I only ask because on my Mac enabling metal rendering results in a > > *much* lower frame rate (although whether that equates to higher input > > lag I don't know). Thanks for this. > Pressing and holding a key for 10s with a high key repeat rate: > > Large frame: > > NS: 300 letters input > Macport: 530 letters input > Macport with metal: 515 letters input That is quite a dramatic difference! > So yes, it appears that the macport without metal is actually faster > on my machine which is surprising. I believe this is why it's no longer the default. All the shouting was when it was disabled and people didn't read the note and thought it was new. > How do you typically measure framerate? With this code that I nabbed from in here: (defun scroll-up-benchmark () (interactive) (let ((oldgc gcs-done) (oldtime (float-time))) (condition-case nil (while t (scroll-up) (redisplay)) (error (message "GCs: %d Elapsed time: %f seconds" (- gcs-done oldgc) (- (float-time) oldtime)))))) > That said, I have an app on my phone called "Is it snappy" that uses > the high speed camera to attempt to measure input latency. With my > full config measuring the input latency I get: > > Large frame: > > NS: 95.8 100.0 107.9 (101.2 ms avg) > Macport: 100.0 95.4 95.8 (97.1 ms avg) > Macport with Metal: 78.7 87.5 99.6 (88.6 ms avg) This is quite interesting! It looks like metal reduces the total throughput, but speeds up the time it take to actually get the image to the screen. I wonder why that is...? > > What might be helpful is to profile to find out what's slowing the NS > > port down. > > Can I profile with XCode? What debug optimization level do I have to > use to make it useful? Yes, and I don't think you need to do anything special with optimisation levels. Load instruments.app, choose "time profiler", then at the top select emacs and hit the record button. Do whatever you do, then hit the stop button, and the window below should give some indication of where it is spending the most time. I was thinking that it would be in the copy from one surface to the other, but I profiled my own build and it appears to be negligible. OTOH, since your surfaces are much bigger that might be it. I've tried reducing the amount of times the NS port updates the screen, although I don't think I've really been very successful, but you may as well give it a go and see if it makes any difference. Please try the scratch/ns/surface-stuff branch. And for a laugh try this patch on top of that branch. It's not suitable for general use, but it seems a bit faster here. modified src/nsterm.m @@ -8516,6 +8516,7 @@ - (void)updateLayer could use to force it, but we shouldn't often get the same surface twice in a row. */ [[self layer] setContents:(id)[surface getSurface]]; + [[self layer] setContentsChanged]; } #endif @@ -9716,7 +9717,7 @@ @implementation EmacsSurface probably be some sort of pruning job that removes excess surfaces. */ -#define CACHE_MAX_SIZE 2 +#define CACHE_MAX_SIZE 1 - (id) initWithSize: (NSSize)s ColorSpace: (CGColorSpaceRef)cs If that doesn't help with the lag then I think I've only got one other thing to try before trying to implement 3D rendering. ;) -- Alan Third