From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: Questions regarding PGTK, high-dpi font-rendering, new X11-Warning Date: Wed, 30 Nov 2022 21:37:52 +0800 Message-ID: <878rjsv9zj.fsf@yahoo.com> References: <87cz99l4td.fsf@thaodan.de> <87v8n1w7cf.fsf@yahoo.com> <87wn7gc53k.fsf@thaodan.de> <87r0xnx4fs.fsf@yahoo.com> <87edtncvss.fsf@thaodan.de> <87ilizwbkw.fsf@yahoo.com> <87cz94vjgl.fsf@yahoo.com-NI70zP3----9> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24191"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: =?utf-8?Q?Bj=C3=B6rn?= Bidar , emacs-devel@gnu.org To: xenodasein@tutanota.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 30 14:38: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 1p0NIg-00062J-MB for ged-emacs-devel@m.gmane-mx.org; Wed, 30 Nov 2022 14:38:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0NIC-0001Jq-LY; Wed, 30 Nov 2022 08:38:30 -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 1p0NHw-0001HE-Fc for emacs-devel@gnu.org; Wed, 30 Nov 2022 08:38:19 -0500 Original-Received: from sonic304-21.consmr.mail.ne1.yahoo.com ([66.163.191.147]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p0NHs-00008V-D6 for emacs-devel@gnu.org; Wed, 30 Nov 2022 08:38:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669815483; bh=UsL1yhwQIihUUfNvZFe0PxAYe/1p6HirB5cCtpcQf3k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=Woz10z7uu4GXCR+BJfbeWcu6gUHZA9na0jaDo1H50KA8f7WffDP96eOsyusYi/mWp2xOoyP0RYXO2O6chJ1EKIhzQeYRFfQZPRSL/Z9niR1tYs7OkbGb2aQFaQkOvnB3pNqbPVjzwJ635R2cod8Bm/AjpJ9Ou63WnDGgt9fddNT6onqp29jiFyOLWBYTRiKBd/6EUzQXeJEIHqI2QHh7Mfj3sjjaNmW0G8N6f4F86jsa7fAzMenfEwYsducjtbzE6WbtiPKNpSzuYtKdFYgCXQs8uqCrJqhu5LlrT9bL6eED6Um/uiSnLksylW8dP0dVw9qva9S/qmuhPM190ShwUw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1669815483; bh=PHBSN5zaSN5dd6Dp58N9tl+a6O4vD2ioLrkgkzZY0l0=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=np6yeggykBO+ohmc3DbE+abVgcn5ypCAIWXJCit1lx5NPRsfHz7+vrLvA1en19gc+oDahn6aTKgFksLQaJc5aEkTkO6aYs4WtOodNegx8xlPKF1SVx3pj0IhOs0Ghqmn0P53BKYX3Nvt+vItqQmoFxGOzt08hLTTJXx6R4P1YOBRwCHRrGsWI5nagbYgS2bpGBTusyUdpbowY2CJIQAuWWm+RyIFmjojbaLy+Fow1bLze3A/8NXspFetA9pI1BjVmSups2Afh/JJQ7fLxeVIGdHQIiT+Z0ZCK1NsG5SYsNRmpZt0brlq33vyxLay0hAZ8GjprHrlG6E4msy5eT9teA== X-YMail-OSG: bFb6srMVM1kfDclG8dl56sGKCAkQ73sQUWOwVFw_zlAS_f3Q7fCLJVh3zaDG0Dp EKy2snomxCViPYO_jHkg8EnLvL0f5WoE_RjsZbtS65DguWGGp2HSG7bL3N1alEuwxt5XHxGSO3R5 .udemryzqay0.wukRJQMZ.lQIPnNWpW5SqOUXekCpQq5MUm8W6PqZe7QVPE3ymyytz52kY1Y_mH2 1iElqArrISoCuGGOCdgMzRkCz2VEv9jCPKd67Yvmi81mCTtfYyib0QJFNX0fVihej0JwyxeN9S4R AQ3HlEKblUGnsFWxu0Qn6Ms9jSpV0lkoQImrIfUQsClVl7tHyAx.S1xCWy._vb0ZYSbnuCz1Gvp3 cjH9PlBdJqKrg7b6oZrRobTNjOAS.yjNpz5FMPL9bk7vgJvd.oYpdsx5Dz9SgH0FucY9w4m7hiZt NnfHdft6MQ7en1FZ0ZYPMWPQ_fvylernEc27nQr0tiaMqqe06TceBwsseePhtVDcw1PKKHsQ9nGi ZBCffigQqZ_SS4EjzpR9KfviSyH_HHpTygEi.Yyy2YTRtoWaqBravjQZm798ymi63JpXVZ0Xz7x4 RTl3LHLSFTRCC8F3JpYloUeqG2lzK5dDEV9DMGQv4hmjRJPBLfpayHa26uaF9mvV7gQkWnhDkV2k 3uXu482CHamCqOVkjYMbYInWz7UJs2Oyd6vVxEld97299sFeFuuHN0AM3NzOyXDiez8mFJJVww_W n_jDT2OMstCf_bTUlvDQrfU4M5oV7el1NKD1PcOf1J3ZZ5LD16.WPHexlscZF6FLWmTiwphWx_Mk aBNlJiWkLzUt9LCKIahJoj0GoOQvq_eMzSOg5JdA.7 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.ne1.yahoo.com with HTTP; Wed, 30 Nov 2022 13:38:03 +0000 Original-Received: by hermes--production-sg3-6c8895b545-mnqst (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e34926092771f930e1401bf869bc791a; Wed, 30 Nov 2022 13:37:59 +0000 (UTC) In-Reply-To: (xenodasein@tutanota.de's message of "Wed, 30 Nov 2022 12:51:07 +0100 (CET)") X-Mailer: WebService/1.1.20863 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.191.147; envelope-from=luangruo@yahoo.com; helo=sonic304-21.consmr.mail.ne1.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:300762 Archived-At: xenodasein@tutanota.de writes: > First of all thank you for not going straight for it's not possible / > no one would want that / it's the wrong way / etc. I only say that when it really is impossible, or wrong. I see nothing wrong in principle with making the PGTK build work well on X, but whoever tries is in for a lot of pain, so I'm not volunteering. > I tried to suggest last year a way to draw your own window content > without GTK, Lars said great you can start from vanilla X build, > you and Eli on the other hand gave the impression that you found it > extremely undesirable. Which brings me to the point that this seems > like a question of what do you want done instead of how to. I am > myself not at the point where I could pull this off alone, but I'm > getting there. Others would attempt at things like that if they found > any enthusiasm about I'm sure. I've already explained why doing all graphics in Emacs will be a major step backwards. But let me reiterate: - it will not work well with X, especially not over slow network connections, because the only way to do that without special-casing X is to fedex the local back buffer contents to the X server every time something changes. - we will end up having to write a huge amount of code. At least one set of code for each kind of graphics device: pseudo-color, static-color, and true-color. And probably different sets of code every combination of pixmap format and visual. Each set of code will at least have to include, aside from trapezoid, line and arc rasterization, the ability to apply more or less arbitrary transformations to images, and alpha blending. All the code will need to be fast, which will be impossible to do portably: the best case on X is that the shared memory extension is usable, which will let Emacs avoid uploading huge amounts of image data to the X server upon each change. The X server will still have to upload the shared memory to graphics memory every time Emacs tries to copy from the shared memory to the window, as it cannot know which parts of the shared memory has changed since the last upload. - it will not make Emacs more portable, because the vast majority of the complicated window system code involves interactions with the window system itself, and not computer graphics. How do you propose to make, for example, xselect.c, portable, when the X selection API is fundamentally different from the clipboards or pasteboards found on different systems and exposed by toolkits, and Emacs has always exposed a very low level interface to Lisp via `selection-converter-alist', `x-get-selection', and related functions and variables? > You must keep in mind that big contributions like this must have a > foundation if there will be any hope of them even happening. ``this'' being? > For example I can almost imagine the answers if I suggested separating > some translation units instead of using #ifdef's every five lines, so > I won't don't worry. [...] > Or take as example the recent discussion on macros. It won't make > much of a difference indeed if some line is a function or a macro, > issue is the resistance to even simple changes like that; it implies > the impossibility of something not as simple. No, it does not. What you're saying is that every time someone suggests a change to Emacs, we should agree to it, even if the change is absolutely pointless or even wrong. The problem with that theory is self evident. > I remember Eli requesting not to change the location of some function > on the grounds that it will now be harder to find where it is. Which is bad because..? > So what is my point, when some person asks why do I need to binaries, > instead of saying things like "why not" say we need more people to > work with C parts, that's all. What's the verb ``binaries''?