From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third Newsgroups: gmane.emacs.devel Subject: Re: "Fix" sag scaling for hidpi Date: Sat, 13 Feb 2021 15:59:38 +0000 Message-ID: References: <9C04F72C-1BB6-4308-AD8E-4A2B471CAC4E@gmail.com> <871rdkte4f.fsf@gnus.org> <87h7mgqj60.fsf@gnus.org> <87h7mgovil.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22128"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Yuan Fu , Robert Pluim , Eli Zaretskii , monnier@iro.umontreal.ca, emacs-devel To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Feb 13 17:01:41 2021 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 1lAxMb-0005gt-13 for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Feb 2021 17:01:41 +0100 Original-Received: from localhost ([::1]:34798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lAxMa-0003Pb-2d for ged-emacs-devel@m.gmane-mx.org; Sat, 13 Feb 2021 11:01:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48432) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAxKn-0002hC-Pb for emacs-devel@gnu.org; Sat, 13 Feb 2021 10:59:49 -0500 Original-Received: from outbound.soverin.net ([2a01:4f8:fff0:2d:8::218]:33485) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lAxKk-0005Wz-Qr; Sat, 13 Feb 2021 10:59:49 -0500 Original-Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 6C00D600D0; Sat, 13 Feb 2021 15:59:42 +0000 (UTC) Original-Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=idiocy.org; s=soverin; t=1613231981; bh=oKnVoeZHkV8PrQAQPWj7QrYcAHJWS8465bxnOz0eGqA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=TLYHcxFlCcLf0srt28bZTQi36omtYeUgn3uIv05YdxO2yJKnk64wbX0PR/7lP6HlI ODdKexFnwNAKp7mV4fXsTH+79RQot7WhtkyW/CAbKmjFiGHTZJYDpHtO4TBJ+3iymd qB5THRWI+TVGzC6LJ96N1kZ69NHK3KVzsTbvhtctfQRjDOaKXYrh7aFIJ+FYG+yKJR b8jBYJHoK7hIfRMiD82IBEPk8vfBc0cX7V/rE2xSrT+qkIbagbdXdz4piiFuIUZsOQ D24gUnFM6FDgMaAd7GkNrKN3Ve9xeAY7o3HoEeZhZLa4Gw9r6FLm1lqgoG/Jv/aAdr NO9jhW0rgZwKw== Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 3DC67202A66CF8; Sat, 13 Feb 2021 15:59:38 +0000 (GMT) Mail-Followup-To: Alan Third , Lars Ingebrigtsen , Yuan Fu , emacs-devel , Eli Zaretskii , Robert Pluim , monnier@iro.umontreal.ca Content-Disposition: inline In-Reply-To: <87h7mgovil.fsf@gnus.org> Received-SPF: pass client-ip=2a01:4f8:fff0:2d:8::218; envelope-from=alan@idiocy.org; helo=outbound.soverin.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:264640 Archived-At: On Sat, Feb 13, 2021 at 04:08:34PM +0100, Lars Ingebrigtsen wrote: > Alan Third writes: > > > Ah, I've misunderstood how GTK deals with scaling. I could've sworn > > someone said upthread that SVG images are shown at double size, the > > same as on macOS, but apparently not. > > I tried loading the splash.svg file, and it's displayed here the same > size as the splash.png file. Debian bullseye, HiDPI, scaling factor of > 2.3, so the 333-pixel-wide image is displayed as a 760-pixel-wide image: > > (insert-image (create-image "~/src/emacs/trunk/etc/images/splash.png")) > (insert-image (create-image "~/src/emacs/trunk/etc/images/splash.svg")) Strange. When I do that with GDK_SCALE=2 I get both images as 333 pixels wide. The only thing that appears to have been scaled are the menus and toolbar, everything else is the exact same size as if I use GDK_SCALE=1. I guess I'm doing something wrong. > > Nope, it's the same as on macOS. > > > > So on macOS and PGTK we want to use the scale factor to scale down > > images so they are displayed with physical pixels, and on XGTK we want > > to scale up (UI?) images so they are displayed in logical pixels. > > > > I'm somewhat inclined to ignore XGTKs desires, especially as it seems > > it may be removed once PGTK is merged. > > It sounds like confusion born out of some architectures reporting sizes > as logical pixels, and some as physical pixels. That has to be fixed, > or we'll just confuse ourselves even more. :-) It's not really a problem in practice unless you want images that aren't blurry due to being scaled up. The confusion I'm seeing is purely down to the XGTK emacs scaling only some UI elements. (It does look like Windows is confusing though, since the first page I've landed on to explain how it works describes three completely separate mechanisms, one of which appears to match what macOS and GTK do, while two are completely different.) > >> Uhm... but on Macos, Emacs doesn't know the physical pixel size, I > >> think you said earlier? So... er... now I'm confused. :-) > > > > It's something you have to go looking for specifically, usually > > through multiplying by the scale factor. The reason I said I wouldn't > > want Emacs to convert everything to physical pixels is because every > > single size would have to be multiplied or divided by the scale > > factor, and then Emacs would appear to be half the size of every other > > app (font sizes would be half what they are in the terminal, for > > example). > > I don't follow. This Gtk Emacs is exactly the size I want it to be, and > it computes everything in physical pixels. > > If the OS expects logical pixels, then we scale before asking the OS to > do something -- this is how Gtk menus are computed, for instance. I'd stick with the default behaviour and just work around the few occasions where that results in unwanted behaviour (the previously mentioned blurry images). -- Alan Third