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 image support for kitty terminal Date: Thu, 08 Sep 2022 09:51:56 +0300 Message-ID: <83o7vqfjeb.fsf@gnu.org> References: <87v8pz18wf.fsf@mail.jao.io> <83o7vrgimc.fsf@gnu.org> <87fsh3yq81.fsf@mail.jao.io> <837d2fgef0.fsf@gnu.org> <875yhzymij.fsf@mail.jao.io> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16058"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Jose A Ortega Ruiz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 08 08:53:18 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 1oWBPZ-00043F-Ki for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Sep 2022 08:53:17 +0200 Original-Received: from localhost ([::1]:46434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oWBPY-0006FC-KE for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Sep 2022 02:53:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57750) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWBOW-0005Y6-4X for emacs-devel@gnu.org; Thu, 08 Sep 2022 02:52:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37660) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWBOV-0003XW-CG; Thu, 08 Sep 2022 02:52:11 -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=ap+Y2/VF/ueLHt9ExUZMale5JIdnH9Shnhc0zQNUbIA=; b=bmvZAsqM0RX6 UfoH0OBj3rO5psNarzf7ni1+utVvEcbIENa0NHfWGVZQl+fEhvsZXsBslA5IVJCYBk6wCykIGCHM4 /73JASqTvX+XpwUOFdd+aYSMmZuq0AXdjLPCfwIwX0JEzPtsAq7E/C+PYgJ7U6m72FGJ2qu1yL5CP egxWqOoAObamhfmdAumy9CdeKoDOenvHjz2rRm6Z2f/BQf6QFIjM0wBHQ1nB2oHQZ/Q+nSZICjSvV IIOyYoYohSGRZ/HytVHi9e2Vsadle20dWkI614sRmmh93JS+WYhFtjaSVgzw5z0xRggsuKMydgSTj NXoHcA+kd+jLI5+5qQOJYg==; Original-Received: from [87.69.77.57] (port=3137 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 1oWBOU-0008L1-LC; Thu, 08 Sep 2022 02:52:10 -0400 In-Reply-To: <875yhzymij.fsf@mail.jao.io> (message from Jose A Ortega Ruiz on Wed, 07 Sep 2022 21:09:40 +0100) 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:294904 Archived-At: > From: Jose A Ortega Ruiz > Cc: emacs-devel@gnu.org > Date: Wed, 07 Sep 2022 21:09:40 +0100 > > > This is a different level: the level of actually delivering the stuff > > to the glass. I think it's much easier than what was bothering me. I > > was talking about the level of layout: the one that knows how much > > space each "display element" (character, image, stretch of white > > space, etc.) takes on display. On TTY frames, there's a built-in > > assumption that every display element takes just one pixel in the > > vertical direction, and each screen line takes one pixel on display. > > That will have to change for image support, I presume. > > in x terminal emulators, by "pixel" here you mean one terminal "cell" > (the extend of a displayed ascii char), right? Yes. > >> I am assuming here that the display engine (for a tty) knows somehow > >> that it's printing a very lage "character" that is going to spawn > >> several rows and columns, and also that we can always tell how wide and > >> tall the window around point is when we display this "character". > > > > That's exactly the problem: it currently assumes that no display > > element takes more than one row, and that each row is exactly one > > pixel (= one character height) tall. > > aha, i see. so what's needed, for instance, is a way of managing blocks > of such display elements, that are always rendered all at once... Something like that would be a significant change in the current design, which handles each screen line separately. > or are there better ways of accomplishing the same? That's exactly the question: how to do better?