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 20:42:59 -0300 Message-ID: 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> 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="226559"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Alan Third , Robert Pluim , 37689@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 15 01:44:34 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 1iKA0w-000wpE-D1 for geb-bug-gnu-emacs@m.gmane.org; Tue, 15 Oct 2019 01:44:34 +0200 Original-Received: from localhost ([::1]:58680 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKA0v-0001sB-91 for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Oct 2019 19:44:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51005) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iKA0c-0001qB-SZ for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 19:44:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iKA0V-0007kv-1C for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 19:44:14 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33583) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iKA0R-0007dh-Ge for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 19:44:06 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iKA0Q-0006DS-95 for bug-gnu-emacs@gnu.org; Mon, 14 Oct 2019 19:44: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 23:44: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.157109659823806 (code B ref 37689); Mon, 14 Oct 2019 23:44:02 +0000 Original-Received: (at 37689) by debbugs.gnu.org; 14 Oct 2019 23:43:18 +0000 Original-Received: from localhost ([127.0.0.1]:42404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iK9zi-0006Bt-AC for submit@debbugs.gnu.org; Mon, 14 Oct 2019 19:43:18 -0400 Original-Received: from mail-yb1-f194.google.com ([209.85.219.194]:36011) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iK9zg-0006Bb-KP for 37689@debbugs.gnu.org; Mon, 14 Oct 2019 19:43:17 -0400 Original-Received: by mail-yb1-f194.google.com with SMTP id t4so3303117ybk.3 for <37689@debbugs.gnu.org>; Mon, 14 Oct 2019 16:43:16 -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=ZVufiGlZCX9HgS2o838s7wPFRJLygcBiDbpoBaIw2ro=; b=cWr/E2sI4Br4/YME4YvEw/pgq6ymNpzBaO8pHIeRi+MDpxNDONJMTrRXMQB8TWh6nB CXhV9C6KU7vRi/hIrYcQcTWpdRO/m5EBXnHWIK6b5X1zdVDgKAUMZ5M0x6zePt6GEgZG MUjYB6F8KSy9QbreQhWom86I6NZt2l6n0m02m7cFkBei04vLbD1WejavdC1aXyOIJ1PI 1FywfXH2rc7Hm9zgIvr8ZVjwQEIGia/L5Ew+8KZ3QWzm7AdfYbj39JXdlMleb9XufNMN pcGzY8WIbwc6MwRQAKTAgCExXgDsMry4ZxQrovFvg70jrxijBmS5zK0JbBPFhBNu2MRy ko+g== 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=ZVufiGlZCX9HgS2o838s7wPFRJLygcBiDbpoBaIw2ro=; b=EHte+x+fDK91WL4wM6clsXUJSyCA0+I47x+sd4f8NNpbByM7Hj0lY2zYdpRP1eIk6C VmoiCfQKJwgi6hQpsKlLRPYKndzibSzERi4Bpx+nr9H0t4eKXpnibNE7BPoIT7ZjC2lt RqPaUk7g5Ye1AFgL3ZJ+v7fEa1Z3a97bcGQnlCKYXNe5CFIVAaKM8ERsiZjJpifGSB7X CfKn2YyddcrF87fXa0n60SyTMWs2GFUrToSDqCeIeM9xwQxbwPRtnHgDHl8BtaW3Fm4E mDBKCG8JGKz8C1Ruigkmiqmgzop8E8Myf5UewbxxzhRvMqohCXLJHkpKu+I10CGgjzTo dWJA== X-Gm-Message-State: APjAAAXZgoIxR116TEBNInP8mN6KDsM+59I1Df6vEF6YBRBt29KB2luB bZS6hos6YXG4AGO0MjkbgFNjLJjAFrutKsUJFvE= X-Google-Smtp-Source: APXvYqyum7KXVNCnG2sA9SOZnQ0NjawGINvSxlq29PLADxy858EXOmpIl3nOumaxy0CO12GKUxg1J1EgzK3aJ6YMbrA= X-Received: by 2002:a25:4d87:: with SMTP id a129mr21331989ybb.82.1571096590769; Mon, 14 Oct 2019 16:43:10 -0700 (PDT) In-Reply-To: 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:169332 Archived-At: 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. Also: 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. 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. Given those considerable difficulties, I propose to scale bitmaps in two stages instead: 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?