From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Cecilio Pardo Newsgroups: gmane.emacs.devel Subject: Re: Drawing UI elements behind text Date: Wed, 27 Nov 2024 19:28:58 +0100 Message-ID: References: <641230ac-2dbc-42ac-a57e-acda77fe9296@imayhem.com> <8C55E590-E586-440A-89C5-0E5153518790@gmail.com> <78d3a7e7-f5a7-476b-8a9d-27beca44a94a@imayhem.com> <86plmgg2vx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7890"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: jdtsmith@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 27 19:29:55 2024 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 1tGMnT-0001nI-Gl for ged-emacs-devel@m.gmane-mx.org; Wed, 27 Nov 2024 19:29:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tGMmj-0006Uo-4Q; Wed, 27 Nov 2024 13:29:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGMmh-0006Uf-OV for emacs-devel@gnu.org; Wed, 27 Nov 2024 13:29:07 -0500 Original-Received: from mail.imayhem.com ([82.223.54.191] helo=zealous-pike.82-223-54-191.plesk.page) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tGMmf-0001qY-9r; Wed, 27 Nov 2024 13:29:07 -0500 Original-Received: from [192.168.68.104] (111.red-88-21-7.staticip.rima-tde.net [88.21.7.111]) by zealous-pike.82-223-54-191.plesk.page (Postfix) with ESMTPSA id 926D780127; Wed, 27 Nov 2024 18:28:59 +0000 (UTC) Authentication-Results: zealous-pike.82-223-54-191.plesk.page; spf=pass (sender IP is 88.21.7.111) smtp.mailfrom=cpardo@imayhem.com smtp.helo=[192.168.68.104] Received-SPF: pass (zealous-pike.82-223-54-191.plesk.page: connection is authenticated) Content-Language: es-ES In-Reply-To: <86plmgg2vx.fsf@gnu.org> Received-SPF: pass client-ip=82.223.54.191; envelope-from=cpardo@imayhem.com; helo=zealous-pike.82-223-54-191.plesk.page X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=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.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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325783 Archived-At: On 27/11/2024 15:36, Eli Zaretskii wrote: >> Date: Wed, 27 Nov 2024 00:19:43 +0100 >> Cc: emacs-devel >> From: Cecilio Pardo >> >> I haven't found a way to draw behind the text that is not too >> complicated or affects redisplay too much. So now the idea is drawing >> over the text. For the applications I have in mind this works equally well. >> >> The starting drawing elements are going to be vertical and horizontal >> segments, with color (maybe with alpha), width and different patterns. >> They can be placed on pixel positions or character positions when using >> fixed size fonts, using floating point numbers so you can put, for >> example, indent lines in the middle of characters. >> >> They are associated with a buffer, and have a 'source' marker so the >> facility can be shared by several programs. > > How/whether are these drawing elements connected to the glyph > matrices? > > If they are completely disconnected, how does this work when the > window is scrolled several lines? They are anchored at locations on the buffer, specified by line/column. This is transformed into pixels using the size of the default char cell for the buffer. The buffer scroll position on each window is used to compute the final position on the frame/screen. For buffers that use different font sizes or images this is probably not very useful. Direct pixel positions can be used too. They are drawn after switching the back paint buffer, so that the redisplay result is left alone. At first I tried intercepting the background clearing to draw behind the text. But to allow for redisplay to reuse the output I had to redraw the glyphs affected with a clear background, and this was too costly in the worst cases. I will have a patch in a few days.