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: Mon, 24 May 2021 10:01:47 +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="18299"; 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 Mon May 24 12:37:05 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 1ll7xJ-0004au-OZ for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 12:37:05 +0200 Original-Received: from localhost ([::1]:55412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll7xI-0004Db-Qi for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 06:37:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46182) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ll7wo-0003Yh-Kw for emacs-devel@gnu.org; Mon, 24 May 2021 06:36:34 -0400 Original-Received: from [217.169.17.33] (port=58270 helo=breton.holly.idiocy.org) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ll7wm-00076v-N5 for emacs-devel@gnu.org; Mon, 24 May 2021 06:36:34 -0400 Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id CC943202C22A93; Mon, 24 May 2021 10:01:47 +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:269746 Archived-At: On Sun, May 23, 2021 at 03:37:11PM -0700, Aaron Jensen wrote: > On Sun, May 23, 2021 at 2:08 PM Alan Third wrote: > > > > > Interesting. And generally speaking, are there licensing issues > > > preventing a merge/collaboration w/ the mac port? > > > > We already use the Mac port font backend (although I suspect they may > > have diverged a little over time). Other than that I don't know how > > much "collaboration" would be practical, and anything else would be simply > > throwing the NS port out altogether and replacing it with the Mac > > port, although then it would be subject to the same rules as the NS > > port which may or may not be to Yamamoto Mitsuharu's taste. > > I see, is that the rules about how nothing can be done in a Non-free > OS port that a free OS cannot do? I think so. A lot of what people like (smooth scrolling, etc.) would have to be removed. > > I've made surface-stuff as much like the (non-metal) mac port as I > > possibly can. I'm not seeing any difference. I've put an NSLog at the > > start of keyDown and another at the end of updateLayer, and the time > > difference is pretty consistently about 3ms, so I don't think the NS > > port's IO is slow. That leaves the time between the key being hit and > > the NS port registering it, which I don't think we can do anything > > about, or the time between us passing the IOSurface to the system and > > it actually displaying, which should be identical to the Mac port, > > unless it's using some sneaky setting I've yet to discover. > > > > If it's still laggy, I've got absolutely no idea. > > Interesting. Well I know that my config is adding some latency. Likely > company, flyspell, flycheck, etc. I'll keep digging on my end too. One more thing to try... modified src/nsterm.m @@ -8376,7 +8376,13 @@ - (void)unfocusDrawingBuffer NSTRACE ("[EmacsView unfocusDrawingBuffer]"); [NSGraphicsContext setCurrentContext:nil]; - [self setNeedsDisplay:YES]; + [surface releaseContext]; + [[self layer] setContents:(id)[surface getSurface]]; + [surface performSelectorOnMainThread:@selector (getContext) + withObject:nil + waitUntilDone:NO]; + + //[self setNeedsDisplay:YES]; } @@ -8513,11 +8519,11 @@ - (void)updateLayer There's a private method, -[CALayer setContentsChanged], that we could use to force it, but we shouldn't often get the same surface twice in a row. */ - [surface releaseContext]; - [[self layer] setContents:(id)[surface getSurface]]; - [surface performSelectorOnMainThread:@selector (getContext) - withObject:nil - waitUntilDone:NO]; + // [surface releaseContext]; + // [[self layer] setContents:(id)[surface getSurface]]; + // [surface performSelectorOnMainThread:@selector (getContext) + // withObject:nil + // waitUntilDone:NO]; } #endif All this does is reduce the time between us deciding we're done with drawing and sending it off to VRAM (although it might not, I'm not entirely sure when updateLayer gets called). I expect this to reduce frame rate, but perhaps it will improve input lag a little. What's the overall situation just now with the various branches? I don't actually care too much about frame rate, I think it's probably fast enough in all cases, but I'm interested in input lag. Has anything I've done improved it? -- Alan Third