From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Rethinking the design of xwidgets Date: Wed, 14 Oct 2020 12:53:17 -0400 Message-ID: References: <864kmzupp0.fsf@akirakyle.com> <835z7e2ouj.fsf@gnu.org> <86v9fet5sg.fsf@akirakyle.com> <83imbe1040.fsf@gnu.org> <86pn5luak4.fsf@akirakyle.com> <83362g27y6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31545"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , Akira Kyle , emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Oct 14 18:54:51 2020 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 1kSk38-00087O-Of for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 18:54:50 +0200 Original-Received: from localhost ([::1]:34298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSk37-0000Qp-RA for ged-emacs-devel@m.gmane-mx.org; Wed, 14 Oct 2020 12:54:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40836) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSk1k-0008FB-NG for emacs-devel@gnu.org; Wed, 14 Oct 2020 12:53:24 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26810) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSk1h-0007vn-U0; Wed, 14 Oct 2020 12:53:23 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B32301004B3; Wed, 14 Oct 2020 12:53:19 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2B3DB100019; Wed, 14 Oct 2020 12:53:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1602694398; bh=lcMaGyuQVHlrVYWkcLhlG9iXgPliEgOGjEN93z6wLrQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=U0L8360ilsqNwiE0UktkLtpSB5lSLEJkkr1EjGMELKHM4OMvqb5Mww29VnGk6b08c 3PyaWGJmBUPPM58kgsf0Q45mDVFuSLPRjlFm2rdFnoEFiDUHh8E4dmFa3G1cIw+VLB +FiW9NMdNcjHzKdyhdxOOf98FuByKpprtU0j1eH/UnDPlMZ1C982nq5zJv/6k/Gzmk K8EPQXjl263xEHSVkEGlyP3LwcOj61pAhh2FYWBnwp0aItEoDBa2byRY68B4VRIZjF AIOnOhY/CL4MIOohYOs0qrUxd50uUHJ2sGJC+vlBrLPptYehAIqjRkgm4VE741wDya kyn5A8898dCbg== Original-Received: from alfajor (unknown [157.52.9.240]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C7A9F120124; Wed, 14 Oct 2020 12:53:17 -0400 (EDT) In-Reply-To: (Arthur Miller's message of "Wed, 14 Oct 2020 17:04:07 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/14 12:53:19 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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.23 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:257660 Archived-At: >> I don't think that algorithm is less optimal nowadays than it was back >> then; the really interesting question is how much it saves us when >> compared to simply redisplaying all those lines. Right. The relative performance of different kinds of code has probably changed significantly, so it's possible that it's faster to just redraw the whole window than to try and figure out which part to redraw (and even try and find some scrolling opportunities in there). Then again, it's also quite possible that those optimizations are still very much worthwhile. > In case where there is a discret gfx card (i.e. Nvidia/AMD) it is > probably faster to send everything to GPU and ask it to render a > giant texture and then use it as XWindow pixmap, or something similar > then to figure out on CPU all the stuff that should not be displayed. I think it's much harder than it sounds: most of the work needs access to data structures that aren't friendly to GPUs, so the work of providing data to a GPU in an appropriate form would probably not be much more less in most cases than the drawing itself. (talking-about-things-one-does-not-understand-mode 1) But indeed, maybe we could split the "drawing" from the glyph matrices to the glass into a first step that draws into a "pixmap matrix" and a second step that draws from it onto the glass. This should make it unnecessary to try and "scroll" (parts of) the display since it should be "just as fast" to copy from the pixmap matrix as it is to copy from the current glass's content. (talking-about-things-one-does-not-understand-mode -1) I think the performance of the redisplay is by and large poorly understood. While there are known cases where people experience "slow redisplay" it's usually very unclear what that means concretely. In many cases this can be completely unrelated to the actual redisplay code (e.g. the time is spent running some expensive code off of `post-command-hook` or font-lock or younameit). Stefan