From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs's set-frame-size can not work well with gnome-shell? Date: Fri, 31 Jan 2020 04:22:11 +0300 Message-ID: References: <2056a194.3971.16f8d4dd4c5.Coremail.tumashu@163.com> <39d47d8c.4bad.16fcd672191.Coremail.tumashu@163.com> <729d39eb-d0b4-2cc5-cac3-e129a3effa87@yandex.ru> <06c6b6fb-ce6f-456b-6a22-c5a26a0ab297@gmx.at> <50912835-37d2-f15b-8fd1-b6619893d1ce@yandex.ru> <4a424bf3-ee08-b114-73ef-287bde14003b@gmx.at> <5dd35cdd-2914-0b91-a6fd-e8764feecfb0@gmx.at> <9839e101-a25d-8875-4eee-2e6772249afe@yandex.ru> <728856fd-dab1-eade-54f5-6ba2c299373a@gmx.at> <6c775e15-1113-8406-5583-97c259305a7d@yandex.ru> <0fe2d245-9ac1-3528-e710-38462441f8aa@gmx.at> <9bac54df-8cd3-303d-910e-07e161ff1f3e@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="101832"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: "emacs-devel@gnu.org" To: martin rudalics , tumashu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 31 02:37:29 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 1ixLFR-000QQT-32 for ged-emacs-devel@m.gmane-mx.org; Fri, 31 Jan 2020 02:37:29 +0100 Original-Received: from localhost ([::1]:47310 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixLFQ-0003Yt-57 for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Jan 2020 20:37:28 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40401) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ixLEG-0001t3-O7 for emacs-devel@gnu.org; Thu, 30 Jan 2020 20:36:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ixL0h-0001im-HV for emacs-devel@gnu.org; Thu, 30 Jan 2020 20:22:20 -0500 Original-Received: from mail-lf1-x131.google.com ([2a00:1450:4864:20::131]:35786) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ixL0h-0001gz-9d for emacs-devel@gnu.org; Thu, 30 Jan 2020 20:22:15 -0500 Original-Received: by mail-lf1-x131.google.com with SMTP id z18so3669330lfe.2 for ; Thu, 30 Jan 2020 17:22:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z5Bon9rT6ZuzlkcMfi3LwLv63iCMc+tC1PTmDNzRvAI=; b=IbEpKrjXmombR1aS4F7rFsYzCl1fkD9/kpR6Ca4KNk1BNKHfgRtF9oKLdRi4+pn2kJ IINM41VWeAbTMKxzHOZwjjTdtW8wGZsDjwWJSTFhGuN6dBD14xYAUgP5FPjVoiHUNzv1 Mi6sKIFZZdTMD8KzM7ikyL4+dXZtC68wtiAHe1atISZv4MJep19ZSuOJw0fpQ/nbXR1U 3xMYxHueE9Lh5XpFzKSJYZwgwIG8xVAUnKcEPunNEWAFzCoamI8+NhJE/A/x5xCwA78l Y2TbY7griAbQxCPUxVHDEUuRa7u50JUItnTrIRnLeHYFtRbxJjFAcQcq5mxO8dKTHvVu svLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z5Bon9rT6ZuzlkcMfi3LwLv63iCMc+tC1PTmDNzRvAI=; b=OMqhgOOKYdpOqVUB+tkppHJ4f4CqjBJuFZ/A5F9VUdp+/Y2BVdS75K9JrVpC1Z8cmt I/60/YidunDq+rSxATY0PGV7tPydKxLk3MPnsUa/S1Ph8u6r6xp2HF/JA139IYAXJptb gPyMN84DvGETXirl6NKrBcJyBBEuS/ZFhZPemwr4g5xPhhwm/bOILYEf5Jq4QrkDRmhA A9SVifh7714B6WiQoJPt5za65imaPN2qh4H9aOrQNVoKAXzDAMcpGxAG4VBDXHRolgXg 2ZzlBLJ7YJkQKAbJZgUvrLj4pIDPtX8n4nf2zo2NRNcxR7VVcNhewONd7JOzahMw1Z/k 0xTw== X-Gm-Message-State: APjAAAVMN8fO2PeBMVnGVEiXWziEdnW3DaxkPHBcdWeYbx1u24TPjqyM Unw/cpWBd0f3wDFsbZnczg0CpXl+JO4= X-Google-Smtp-Source: APXvYqzBBdg7zvlsd1r4p99XXiMgCC0NnstxgJk1tJaJKddl06s76qKrkl9cJCE6esbgi22mvUgRcA== X-Received: by 2002:ac2:599c:: with SMTP id w28mr4073311lfn.78.1580433733089; Thu, 30 Jan 2020 17:22:13 -0800 (PST) Original-Received: from [192.168.1.142] ([178.252.127.239]) by smtp.googlemail.com with ESMTPSA id r15sm3789467ljh.11.2020.01.30.17.22.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jan 2020 17:22:12 -0800 (PST) In-Reply-To: <9bac54df-8cd3-303d-910e-07e161ff1f3e@gmx.at> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::131 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:244784 Archived-At: On 30.01.2020 21:41, martin rudalics wrote: > > mouse.el.diff seems to solve the undecorated frame resizing > > problem. No drift anymore, both with and without > > frame-resize-pixelwise. So brief testing showed that it's okay now. > > OK.  With an undecorated top-level frame, I presume. Yup. > > mouse+xfns.diff, on the other hand, is more broken. First of all, it > > didn't help resizing child frames (not discernible > > difference). > > With GTK you mean. Yes. > > Second, it's very broken with desktop scaling (my 200% > > makes dragging the frame behave very wildly). Without scaling it > > almost works as well as the other patch, but not quite. For instance, > > when mouse dragging by the bottom-right corner, at first the corner > > jumps a little away from the cursor in the top-left direction, and > > then follows it, more or less correctly, from that distance. > > I didn't care about the scaling factors.  The most important aspect of > the second patch is that it should solve the X issue with slow child > frame resizing and moving (at least it does so here).  So you would have > to try it with a Lucid child frame, unscaled first.  I'll try to fix the > scaling issues later. Okay, but actually the Lucid build doesn't have that problem with the scaled desktop. It "just works", or seems to. So I'm testing it with 200% scaling. So, Lucid build, under Mutter: - Resizing works, more or less. Moving a frame by its mode-line works as well without stutters. - The right-bottom corner still jumps away. When I drag the frame by the mode-line, it (the corner) also jumps at first, the same distance. - Same with moving or resizing a child frame. - tumashu's child frame moving test scenario is still slow. E.g. (benchmark 1 `(set-frame-position ,test-frame 50 50)) => 0.5s