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#37770: [PATCH] Expose scale factor through the redisplay interface Date: Thu, 24 Oct 2019 11:34:01 -0300 Message-ID: References: <838spf61ew.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000006db3b90595a8edc4" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="193755"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37770-close@debbugs.gnu.org To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Oct 24 18:14:35 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 1iNfkw-000oEp-Ut for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Oct 2019 18:14:35 +0200 Original-Received: from localhost ([::1]:46373 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNfkv-0005HI-J1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 24 Oct 2019 12:14:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40235) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iNeCg-0007TQ-Ue for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2019 10:35:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iNeCf-00039T-Gh for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2019 10:35:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56150) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iNeCf-000392-Cq for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2019 10:35:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iNeCf-00079p-9O for bug-gnu-emacs@gnu.org; Thu, 24 Oct 2019 10:35:05 -0400 Resent-From: Carlos Pita Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Thu, 24 Oct 2019 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 37770 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Mail-Followup-To: 37770@debbugs.gnu.org, carlosjosepita@gmail.com, carlosjosepita@gmail.com Original-Received: via spool by 37770-done@debbugs.gnu.org id=D37770.157192766527461 (code D ref 37770); Thu, 24 Oct 2019 14:35:02 +0000 Original-Received: (at 37770-close) by debbugs.gnu.org; 24 Oct 2019 14:34:25 +0000 Original-Received: from localhost ([127.0.0.1]:36736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iNeBz-00078o-Bc for submit@debbugs.gnu.org; Thu, 24 Oct 2019 10:34:24 -0400 Original-Received: from mail-yw1-f65.google.com ([209.85.161.65]:42452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iNeBv-00078a-Rm for 37770-close@debbugs.gnu.org; Thu, 24 Oct 2019 10:34:21 -0400 Original-Received: by mail-yw1-f65.google.com with SMTP id d5so3085442ywk.9 for <37770-close@debbugs.gnu.org>; Thu, 24 Oct 2019 07:34:19 -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=a440LBQFZx1OgljU8dpIHel1MBNEQI1zkPTYyluvpeE=; b=BfRzTLi0+t41l1oqCN6lZWBhh+6ibB1q3b3ZheykreEZvmy6q0qv1BTmY9gp4Xaw7P JrDVAuZl2/DrrU0+Z/OP3k6a08QnZyV4HuU2nphYe8rDPnMv8Uwr5O/z+2sP7zJpUYab WO9Ogd52455blS9rgC8HZS7skbA/v8ciQJzQx/GrMk7FbbecKYXZlaPtWecrGAmUgVRj xzlUq3pLkeNMhvqHrcXxJY5J6D+RbT290s4ThlPJZRmpIIolZmTd7A63866/Go0yN0KA 7uMDn67JDaedCMixbay9kPuHWBai6nv3TjBkp1f6md01U35DkmHqCU6Sged6KhURce4X 8F+A== 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=a440LBQFZx1OgljU8dpIHel1MBNEQI1zkPTYyluvpeE=; b=I6zjsjVFNWUVS1J/JKkXRZb8EW8e80qMjo3YXHRu3NlSarWVGXPX5FAyjT2qkLkZD+ /pj//HokMRN9jEgisMyYrx5xsON0tOOs9f1u7STUpkomQON6Vf26AUq0jD1tgd2GfZjS 7ffqHuJ3saFDCX7mirX+u6fPE7L27n1es5eveEBCdvebTnUcohLsJDlMGfoIaE8AzFkd byKqyFU1dnXQARLPzLGZwepfSzT3j20ItofefYd18v6BSMfz8THJzwsUD2vG4QKG5TKW FVNhB1RtmiyQsrCzwCMizaSL3nhet48Pmf2jhGWywbOu+Kg4eI+OFr1Ql9eHQwWydPfm t+Dg== X-Gm-Message-State: APjAAAXegqvafbndLXm5CkjIdX8ffrymZ9YMtl4fooXDQn3hGrFW8VdP INcewMYbMXUCahvhTaWnbTbLXh/8y+zWN1vqclC7G6G0 X-Google-Smtp-Source: APXvYqyVZOlzY9QCHNU27wuCRCEqoe19xrSunQUuF9z9GKPrkeB3WjL6GQkIaIPyiqggGimAnRny8DWq8yU3N6eR2BY= X-Received: by 2002:a0d:d281:: with SMTP id u123mr7168264ywd.297.1571927653984; Thu, 24 Oct 2019 07:34:13 -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:170134 Archived-At: --0000000000006db3b90595a8edc4 Content-Type: text/plain; charset="UTF-8" > > > If emacs used only GTK to draw things to the screen, then indeed there > would be no need for those conversions, as GTK would handle them. > Exactly. > > is attempting to implement a 'pure' > GTK backend. I have no idea how close it is to being ready to merge. > That's great. The way towards Wayland also. Sounds like a LOT of work, though. I've been working in an alternative to this patch and the one that fixes the cairo fringe. My goal is to provide a gtk+cairo solution that listen to gtk scale changes and scales everything (including fonts) accordingly. This would enable an adaptive multi-monitor multi-dpi emacs using the old scale-up-gtk then scale-down-xrandr trick, a nice implementation of which, including GUI and everything, is going to be part of the next Ubuntu LTS with high probability. I'm having a really hard time making the font engine abandon it's idea of pixel-sized fonts that is very entrenched in its caching mechanism once everything was first rendered at some initial dpi. The only way I found to circumvent this is to report a fixed 96dpi resolution and then scale all cairo rendering (fonts, images, bitmaps) using the platform scaling factor. This mostly works but I'm still unable to get rid of all previously opened fonts, even after clearing all ftcrfont caches, so I get a mix of different sized fonts. It will probably take me some time to figure out what's happening. So I'm closing this issue and will open a new one once I have an integral cairo+gtk solution working in a way that mostly resembles the nsterm backend. Best regards -- Carlos > --0000000000006db3b90595a8edc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If emacs used only GTK to draw things to the screen, then indeed there
would be no need for those conversions, as GTK would handle them.

Exactly.

<https://github.com/masm11/emacs> is = attempting to implement a 'pure'
GTK backend. I have no idea how close it is to being ready to merge.

That= 9;s great. The way towards Wayland also. Sounds like a LOT=C2=A0of work, th= ough.

I've been work= ing in an alternative to this patch and the one that fixes the cairo fringe= . My goal is to provide a gtk+cairo solution that listen to gtk scale chang= es and scales everything (including fonts) accordingly. This would enable a= n adaptive multi-monitor multi-dpi emacs using the old scale-up-gtk then sc= ale-down-xrandr trick, a nice implementation of which, including GUI and ev= erything,=C2=A0 is going to be part of the next Ubuntu LTS with high probab= ility.

I'm having a = really hard time making the font engine abandon it's idea of pixel-size= d fonts that is very entrenched in its caching mechanism once everything wa= s first rendered at some initial dpi. The only way I found to circumvent th= is is to report a fixed 96dpi resolution and then scale all cairo rendering= (fonts, images, bitmaps) using the platform scaling factor. This mostly wo= rks but I'm still unable to get rid of all previously opened fonts, eve= n after clearing all ftcrfont caches, so I get a mix of different sized fon= ts. It will probably take me some time to figure out what's happening.<= /div>

So I'm closing this = issue and will open a new one once I have an integral cairo+gtk solution wo= rking in a way that mostly resembles the nsterm backend.

Best regards
--
Carlos



--0000000000006db3b90595a8edc4--