From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Carlos Pita Newsgroups: gmane.emacs.bugs Subject: bug#37689: Fringe pixmaps, widgets, etc. look ridiculously tiny in hidpi screen Date: Mon, 14 Oct 2019 11:37:03 -0300 Message-ID: References: <83v9swqz9q.fsf@gnu.org> <83k19ao21y.fsf@gnu.org> <835zkrk9q9.fsf@gnu.org> <20191014131955.GC45622@breton.holly.idiocy.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="82553"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Robert Pluim , 37689@debbugs.gnu.org To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 14 16:39:39 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iK1Va-000LNM-QO for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 16:39:38 +0200 Original-Received: from localhost ([::1]:50768 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iK1VZ-0006ed-2p for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 10:39:37 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51156) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iK1U4-0004nU-7O for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iK1U2-00056X-RB for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60840) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iK1U2-00056T-Jt for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iK1U2-0005H1-EL for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 10:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Oct 2019 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37689 X-GNU-PR-Package: emacs Original-Received: via spool by 37689-submit@debbugs.gnu.org id=B37689.157106384620214 (code B ref 37689); Mon, 14 Oct 2019 14:38:02 +0000 Original-Received: (at 37689) by debbugs.gnu.org; 14 Oct 2019 14:37:26 +0000 Original-Received: from localhost ([127.0.0.1]:41424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iK1TS-0005Fy-B8 for submit@debbugs.gnu.org; Mon, 14 Oct 2019 10:37:26 -0400 Original-Received: from mail-yw1-f68.google.com ([209.85.161.68]:39270) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iK1TO-0005Fj-Bg for 37689@debbugs.gnu.org; Mon, 14 Oct 2019 10:37:24 -0400 Original-Received: by mail-yw1-f68.google.com with SMTP id n11so6175381ywn.6 for <37689@debbugs.gnu.org>; Mon, 14 Oct 2019 07:37:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NGaDqS26v4YeBE8TX7381bXPY3O2B/nzlcCCxnhS2dU=; b=NLryj4spYD9dgpCVXI9tTPUflgFGR3Rt5IIPWwyQUvCUZDbsmB7TYJqyaOwcJ6AByq 2+Y/u/rsTLU6GMP5rg/8WECyw41SntIfSfejYIUcU7r/uGWQkVOMqDbtPJtfaG+poF7u eifBTul+FZHGQ7TLtfZJrHJz+1Zc/zltuzps+oVxLZkCxUViTR4L13c1SJJ6QscN/Vsj g4slZD+rzEk8hJbF8DV9qJ7lupIZYrG5W6DnpQ5u9GQVjGanwKarA05h8f7t70xz8RNB eVcFcUBb5DKDfNEw82Fs8S3ZAYFRHREDdTuYNY6U4u9tOVv6MZmCPsNSwZdZqgDJK8vh 3Esg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NGaDqS26v4YeBE8TX7381bXPY3O2B/nzlcCCxnhS2dU=; b=RB0Xatm+u1KENwAGDv2ItYxKlh0lEzRdDDpLq7hvIvdufH7QKcg6LKZt7MJjmRSQMR I3TJoEIrd30O98399mSZXMq+6yqClhh73yZcFLYZWngNOP4YPJDELYcBgzA6Kd+l7iNX TD+t/FRTxqbHiOFzXii8dmPyTSkkXJQg6VvNaqkoEOCI0I9lAYfgTUT7ggtUzhOKFyRH IW9d5gO6mVRdOohTOe6M/io28iam+rADYBqsDQhSi2qBf0rbjX0Y9vo5EzV/xBUEyhPv 9797C2cJRx15JlT84u7Y26CgVERAQumhA+DrihAZW6L/HjKvGP1nca1zVMYzQqESPQPd mKdg== X-Gm-Message-State: APjAAAVTUaWQFAM0/EGmC6DFKjuWyG4NdEqPKJltTHV9qpNzYZoE1Z1h J5SwbJVqalF2PAIojls3poSYTAj00j1LikLYIrA= X-Google-Smtp-Source: APXvYqxYGH6qiXEN2WPXEVKMnSTIDF7x0sCa/W7JDWKjo6ArOxyL42ROZBSJ9+sVVPk1u0/J7ZO7DmO5FR0JdI3T9cw= X-Received: by 2002:a81:996:: with SMTP id 144mr13693716ywj.57.1571063836435; Mon, 14 Oct 2019 07:37:16 -0700 (PDT) In-Reply-To: <20191014131955.GC45622@breton.holly.idiocy.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:169269 Archived-At: > Granted, I prefer the second approach. We should do as little code duplication as possible. But we might be duplicating what backends already do. > I don't think individual backends do any scaling My understanding is that nowadays everything is up-scaled by the toolkit, except for fonts that use more sophisticated algorithms to fit the larger grid of available pixels. So an application using a modern toolkit should be mostly unaware of screen resolution. In fact, I've reported some hidpi bugs here and there and, in general, they were in places where the application did make some explicit geometry computation based on actual resolution. Or see how "supporting hidpi" translates in many cases to "port from gtk2 to gtk3". Or look at my screenshots above, do they look too big? Well, that's because they're taken from a hidpi screen; now, you might be in a lowdpi one and then it's obvious that they will look twice as big there; but even if you're in a hidpi screen I bet you probably will see them doubling the real thing, because many apps are unaware or ignore the original image resolution and just let the toolkit show it at 2x. There are plenty of questions (for both Linux and MacOS) around the web asking "why my screenshots look too big?", as a cursory google search will show, although I think the problem was eventually addressed in MacOS, perhaps in core apps or perhaps in general. That might be the reason why Alan says that "The only exception is images". > I think it should be easy to make it do the right thing here. If you had one single backend this would clearly simplify matters. But when you had to support three ones, it isn't that clear. Nevertheless, I think any approach that relies on emacs doing the scaling must be *carefully* evaluated, because it would mean solving a hard problem that even toolkits have a hard time to address. Consider for example having different frames in different monitors each one with its own dpi and geometry. Are you sure that all geometry/layout computations for a frame are done by emacs on-the-fly so as they adapt when the frame is moved from a monitor to another one? Is emacs doing all geometry calculations itself from the actual device geometry and resolution or is it most of a hodgepodge, with some things taken care by the backend and other ones by emacs itself? How clear-cut is the separation between the stages you mentioned (geometry calculation by emacs and actual "delivery to the glass" by the backend)? Is it that clear-cut for *all* supported backends? Now, that said, I don't think it's a bad idea for emacs to deal with these matters regardless of its backends (assuming it can force all backends to work at 1x), since it provides its own toolkit (and its own OS ;) ). What I would like to know is how close emacs is currently to one and to the other approach. > > 2. I'm clueless regarding were widgets (I mean checkboxes and things like that) are rendered. > I'm not sure I understand how this is related to the issue at hand. Can you elaborate? By widgets I was referring to the checkboxes, arrows and stuff that you can see, for example, in a customize-face buffer. When changing the scaling parameters in x_cr_render_image in emacs 26.3, fringe bitmaps were affected but those aforementioned widgets weren't. In emacs 27 they indeed were affected by the same changes in code, but they looked weirdly distorted and clipped, as you can see in my previous screenshot. So, in brief, I couldn't locate the C code path for the rendering of this stuff, specially in emacs 26.3. And by rendering I was indistinctly referring to both stages you describe. Best regards -- Carlos