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: Drawing UI elements behind text Date: Thu, 28 Nov 2024 08:53:30 +0200 Message-ID: <86v7w7etn9.fsf@gnu.org> 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> <86bjy0fqqu.fsf@gnu.org> <943ad61e-9823-4dff-b8c0-d9d1b74ef676@imayhem.com> <861pywfnb2.fsf@gnu.org> <005e93b1-4b5b-4d59-9fc3-9bf9b9c29bdc@imayhem.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30804"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Cecilio Pardo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Nov 28 07:54:17 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 1tGYPo-0007qT-0J for ged-emacs-devel@m.gmane-mx.org; Thu, 28 Nov 2024 07:54:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tGYP7-0005a7-3A; Thu, 28 Nov 2024 01:53:33 -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 1tGYP5-0005Zy-NA for emacs-devel@gnu.org; Thu, 28 Nov 2024 01:53:31 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tGYP5-0005W4-8G; Thu, 28 Nov 2024 01:53:31 -0500 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=+xIaGl029ZwgE91WqBGr0lHRlaLmQksIlqzEdr60JhY=; b=gHZHMIkk6+DT xraiJ8KJ4Gn1IdCgLHZwhtppUCgbpfIYgKGTg56YDvHwKiO0YjdvjFcCBC0us7cnCJtA3Y+mqE5vv 8NTzYeJX0EhRo1K/NGpl45SJk+gZrCbIV3r837rAtuw01HA5gjLD6AOkwF0buI5XYnvi0F7gcyucO E4jI+/mLK2v8TbRi9wutNy7TIAT7uBn8IrQoGLu+GWW50kZNDXBMmI2zPpKa6IjK3+tOoiIEhka/0 bXoGOVB4lk0Hs55Ccu61CdHDmN6wFGy0DnevndiC2BHiTUJ4E3K3qPmlXk0E4pi8igNvWAf4tYEU2 VRKT2ccBXnypD0w26VrKcw==; In-Reply-To: <005e93b1-4b5b-4d59-9fc3-9bf9b9c29bdc@imayhem.com> (message from Cecilio Pardo on Wed, 27 Nov 2024 21:30:54 +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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:325796 Archived-At: > Date: Wed, 27 Nov 2024 21:30:54 +0100 > Cc: emacs-devel@gnu.org > From: Cecilio Pardo > > >> The very naive implementation I have now adds something like 5ms to each > >> redisplay on a 1900px frame, and I hope to bring it down a lot from there. > > > > What takes 5ms, exactly? what kind of redisplay did you trigger, and > > how did you trigger it? > > A minimal redisplay, just moving the cursor around. This takes less than > 1ms, including the time to copy the back buffer to the window. > > When the segment drawing is activated (with tens of thousands of them, > though only tens of them visible in some window) the process takes > around 5ms. > > This process includes: > > - Making a new bitmap, and copy the result of redisplay to it. > - Iterate trough lisp objects to prepare the segments, clip them and > draw them to this bitmap. > > There is a lot of room here to make it faster. OK, but I was more interested in more complex redisplay-related scenarios. For example, what happens if you add a few lines of text to the bottom of the window (by yanking several lines at once)? This should cause Emacs to scroll the window, so that the text previously shown at the top of the window will scroll out of the viewport, and the yanked lines will be scrolled in. How long does this take, with and without these segments? Similarly, what are the timings (again, with and without these segments) when you just move the cursor, but in a way that it goes out of the window, or ends up in a display margin at the top of the window, or in a partially-visible line at the bottom of the window? Those (and other similar ones) are the scenarios where the display engine activates its non-trivial optimization methods, and the questions of interest related to that are: . do we need to disable some of the optimizations when these segments are on display (because their assumptions are incompatible with how these segments are drawn)? . how do these segments affect redisplay times in each such case, after we disable the optimizations, if any, that are incompatible with them? These questions are prerequisites for deciding whether we need to make this particular case faster by some special measures. Thanks.