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: Stipples and scroll optimizations Date: Sun, 08 May 2022 13:46:56 +0300 Message-ID: <838rrcwbbz.fsf@gnu.org> References: <87a6bs5w05.fsf.ref@yahoo.com> <87a6bs5w05.fsf@yahoo.com> <83ilqgwkfw.fsf@gnu.org> <875ymg5vgm.fsf@yahoo.com> <83h760wjyt.fsf@gnu.org> <871qx45ud0.fsf@yahoo.com> <83ee14wfzc.fsf@gnu.org> <87sfpk4bzl.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17342"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun May 08 12:54:59 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 1nneZ1-0004OI-2T for ged-emacs-devel@m.gmane-mx.org; Sun, 08 May 2022 12:54:59 +0200 Original-Received: from localhost ([::1]:58960 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nneZ0-0002Mi-01 for ged-emacs-devel@m.gmane-mx.org; Sun, 08 May 2022 06:54:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nneRO-0000O9-9u for emacs-devel@gnu.org; Sun, 08 May 2022 06:47:07 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:53694) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nneRN-0002OC-Ho; Sun, 08 May 2022 06:47:05 -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=21ojUVGvohwQlczncC0CXaxgWvvKDrpycr+SFWIFmEI=; b=N8DhQqRIqoVd sLcNlkaU22p0Ib59LjQ7XRUsiOP8QgZ6qKZ72db3GIlqa/WAPGuutV565m1TAAaQPvSkK8WHeMDUp 9f0lGqO7TlwOCVg4Ew0zWzEog+of7ap9B7K3wlxQYMLo1P2W8qr+6URflFghUJS4qTyJkdlmi+faQ aAzJSOJ7sEkU/tcTfjJzs8PdcTQk3qNmaWuuEH5Wu7Wj7rVscMWpOS4xDOz6zJuz2BKSczftmXz8o TnVNKz9UmlmVZccBs9ZZ320jnVRE1XTD7FQWEqhDNrzo881RGatkGxYTXxey6B7WdIe7s7wHMK23z ehL2teoxCEch3MNIxcARaw==; Original-Received: from [87.69.77.57] (port=3911 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 1nneRL-000789-O9; Sun, 08 May 2022 06:47:05 -0400 In-Reply-To: <87sfpk4bzl.fsf@yahoo.com> (message from Po Lu on Sun, 08 May 2022 17:20:14 +0800) 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:289468 Archived-At: > From: Po Lu > Cc: emacs-devel@gnu.org > Date: Sun, 08 May 2022 17:20:14 +0800 > > Eli Zaretskii writes: > > > Sorry, I don't understand: what is the "previous" glyph matrix, and > > how can you use it for this test? > > I mean the glyph matrix representing what is currently on the glass, the > "current matrix". But that can be different (even VERY different) from what _should_ be on the glass. We cannot rely on the current matrix for making such decisions. > > Really? I see that 'struct face' has a 'stipple' member, which is set > > in realize_gui_face, and that happens when we realize the face, long > > before x_draw_glyph_string is called. And each glyph in a glyph_row > > has a face_id member, which allows you to get at the corresponding > > face structure. Why cannot you use this to detect glyph_row's that > > use stipples? The only type of glyph whose stipple is ignored is the > > cursor glyph, and that hardly matters for your purposes here, no? > > Whether or not a stipple is present usually depends on the `stippled_p' > flag, which is set in `x_set_glyph_string_gc'. But for starters, > drawing an image glyph might change that flag, and an image might also > obscure the stipple entirely, in which case we don't want to inhibit the > scrolling optimization. The logic is very simple (see x_set_glyph_string_gc) and depends only the kind of "highlight" with which a glyph string should be displayed. All types of highlight except DRAW_CURSOR do the same when the set the stippled_p flag of a glyph string: they all set it if the face's 'stipple' member is non-zero. Why cannot update_window do the same? If drawing the image glyph can change the flag (though I cannot see where it does), then the same logic that depends on seeing image glyphs in a glyph-row can be added to update_window. So I still don't see what difficulties could there be in the method I suggested, and what would be the advantages of doing what you wanted after the first call to x_draw_glyph_string. Please also note that update_window, and with it scrolling_window, work _per_glyph_row_, whereas x_draw_glyph_string works _per_glyph_string_, which is part of a glyph row. So theoretically, it could be that the first calls to x_draw_glyph_string don't see any stippled face, and thus don't set the flag you want, so by the time you realize that scrolling_window cannot be used it's too late. (And in general, scrolling_window is called _before_ we call update_window_line, which is where x_draw_glyph_string is called.