From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Implementing child frames on terminal Date: Thu, 14 Jul 2022 10:27:53 +0300 Message-ID: <83pmi8tapy.fsf@gnu.org> References: <87czfxu7be.fsf@disroot.org> <874k19tya1.fsf@disroot.org> <83h759lb6f.fsf@gnu.org> <87tu99s860.fsf@disroot.org> <838rqklurd.fsf@gnu.org> <87tu7n10hr.fsf@disroot.org> <87h73mykv6.fsf@yahoo.com> <87h73m20fg.fsf@disroot.org> <83o7xuxyc0.fsf@gnu.org> <874jzm1kfl.fsf@disroot.org> <8335f6xrjo.fsf@gnu.org> <87bkttytdb.fsf@disroot.org> <83y1wxuhsi.fsf@gnu.org> <877d4gzyma.fsf@disroot.org> <83leswvq5n.fsf@gnu.org> <87h73kupx1.fsf@disroot.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36300"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org, ibluefocus@outlook.com To: Akib Azmain Turja Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 14 09:37:21 2022 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 1oBtPU-0009Fu-3a for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jul 2022 09:37:20 +0200 Original-Received: from localhost ([::1]:51698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oBtPS-0001ZH-SP for ged-emacs-devel@m.gmane-mx.org; Thu, 14 Jul 2022 03:37:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46122) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBtGZ-0006KD-GJ for emacs-devel@gnu.org; Thu, 14 Jul 2022 03:28:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38934) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBtGU-0006qb-BI; Thu, 14 Jul 2022 03:28:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1BqGFvM3d8oRHHHilggWoP2aW+u2LF69rCdwuIbVFMA=; b=CTz2XnLeoA9/ cBwqzeifS5UD5MQp3Iq6b94Hr3ddmdlYXOfSRBnRkGOMfulHxyQjViJBvRkAez111MyJaQEes0+zX PSsTM3pVu6KwnWESDZc29siYzkhSTjo2bTKYKQFq2oHHyfEAEFPLFMV//QAK8BtV7b8Sc0r/aAPi9 J3tQESoxjorXYHmyPzyCEA1UuJzIcNxlKHC3rNhBMok5jr7OMrfPwGc67T/rIfb/t492XaeZg8c3U XfShgJih9QzKG/zHdwZKDlqtjT/mQXHx53wnY86MV2mP4MKzEWHJcXS5I8CJuKbMrWjIyEYs5trVC hhQtY7WpvsPdYB5bpvlxmg==; Original-Received: from [87.69.77.57] (port=2972 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oBtGS-0005Uo-V7; Thu, 14 Jul 2022 03:28:02 -0400 In-Reply-To: <87h73kupx1.fsf@disroot.org> (message from Akib Azmain Turja on Thu, 14 Jul 2022 13:14:18 +0600) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:292135 Archived-At: > From: Akib Azmain Turja > Cc: luangruo@yahoo.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org, > ibluefocus@outlook.com > Date: Thu, 14 Jul 2022 13:14:18 +0600 > > You misunderstood my question. I meant: is there any real reason to > share the glyph memory of the parent and the child frame? Yes: the last stage of TTY redisplay uses only the frame glyph matrix, it doesn't use glyph matrices of the windows. For child frames, this translates into using only the frame matrix of the topmost frame. (As I proposed at the beginning of this discussion, I would not even maintain frame matrices for child frames, only window matrices.) > We can just copy the visible part of child frame matrix to parent > frame matrix, which IMHO won't cause any noticeable slowdown > compared to X. As I explained earlier, I don't understand why would we want to incur this slowdown, however unnoticeable. Unlike on GUI displays, TTYs have a fixed number and positions of character cells, and not to use this fact sounds silly to me, especially since the existing code already does that.