From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#37689: Fringe pixmaps, widgets, etc. look ridiculously tiny in hidpi screen Date: Tue, 15 Oct 2019 12:27:38 +0300 Message-ID: <83eezegxyt.fsf@gnu.org> References: <83v9swqz9q.fsf@gnu.org> <83k19ao21y.fsf@gnu.org> <835zkrk9q9.fsf@gnu.org> <20191014131955.GC45622@breton.holly.idiocy.org> <83pnizidi3.fsf@gnu.org> <83mue3icjm.fsf@gnu.org> <83lftni815.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="20050"; mail-complaints-to="usenet@blaine.gmane.org" Cc: alan@idiocy.org, rpluim@gmail.com, 37689@debbugs.gnu.org To: Carlos Pita Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 15 11:28:11 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 1iKJ7j-00056o-Mr for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Oct 2019 11:28:11 +0200 Original-Received: from localhost ([::1]:38546 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKJ7i-0001rO-GH for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Oct 2019 05:28:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37488) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKJ7a-0001om-WE for bug-gnu-emacs@gnu.org; Tue, 15 Oct 2019 05:28:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iKJ7Z-0002te-TI for bug-gnu-emacs@gnu.org; Tue, 15 Oct 2019 05:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33924) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iKJ7Z-0002tZ-QJ for bug-gnu-emacs@gnu.org; Tue, 15 Oct 2019 05:28:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iKJ7Z-000213-MY for bug-gnu-emacs@gnu.org; Tue, 15 Oct 2019 05:28:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Oct 2019 09:28:01 +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.15711316757726 (code B ref 37689); Tue, 15 Oct 2019 09:28:01 +0000 Original-Received: (at 37689) by debbugs.gnu.org; 15 Oct 2019 09:27:55 +0000 Original-Received: from localhost ([127.0.0.1]:42741 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iKJ7T-00020X-3J for submit@debbugs.gnu.org; Tue, 15 Oct 2019 05:27:55 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iKJ7Q-00020K-SF for 37689@debbugs.gnu.org; Tue, 15 Oct 2019 05:27:53 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iKJ7L-0002q0-2O; Tue, 15 Oct 2019 05:27:47 -0400 Original-Received: from [176.228.60.248] (port=4952 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iKJ7J-0006CT-7b; Tue, 15 Oct 2019 05:27:46 -0400 In-reply-to: (message from Carlos Pita on Mon, 14 Oct 2019 20:42:59 -0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:169370 Archived-At: > From: Carlos Pita > Date: Mon, 14 Oct 2019 20:42:59 -0300 > Cc: Alan Third , Robert Pluim , 37689@debbugs.gnu.org > > I'm finding non-trivial difficulties that make me think this is not > the best approach. > > I've already mentioned one above: > > 1. I need the scaling factor in fringe.c yet it's not part of the > redisplay_interface. Functions that compute scaling factor are backend > specific and static. Adding them to frame redisplay interface would solve this. > 2. init_fringe_bitmap does non-trivial manipulations to the original > bit sequence (nibble swapping, shifting, casting) to produce a > platform/backend-specific representation. redisplay_interface is > ill-defined in this regard, bitmap representation is not part of the > interface. For some backends init_fringe_bitmap even compresses shorts > to chars if width < 8, so I can't reliably detect row limits in a > platform/backend-agnostic way, which I need in order to scale the > bitmap. The code in init_fringe_bitmap obviously need some refactoring to rely on redisplay interface. You could make such refactoring part of the job, or you could leave the current code intact and use its results. I don't think I understand the difficulty of detecting row limits, but you could begin by doing that for one platform, and then asking others to do the same for other platforms. > 3. The unsigned short representation is unfortunate. For 3x we need at > least int64_t. Then we need to modify all that backend-dependent > nibble swapping, shifting and casting that gives me the creeps. > Finally backends would have to be adapted to take an int64_t array as > input. Couldn't we use the existing image-scaling code for that? It is implemented in each backend already. > a. At the level of fringe.c we only modify the geometry (width, > height) of the image, so that calculations that are independent of the > bitmap itself are correctly done. This way we can keep the unsigned > short representation, we don't need to touch that complex > platform/backend-dependent bit and we don't need to query the scaling > factor, thus solving points 1, 2 and 3 above. > > b. Then each backend should set a transformation matrix or something > like that so that the bitmap is scaled to the appropriate resolution. > I already know how to do that for Cairo, it's trivial. > > Eli, what do you think? I don't think I understand what will stage (a) do under this proposal. Stage (b) is already implemented, you just need to use it, and you need to tell the transformation code the correct scale factor.