GNU bug report logs - #60585
30.0.50; global-text-scale-adjust shrinks window (was not before)

Previous Next

Package: emacs;

Reported by: Jean Louis <bugs <at> gnu.support>

Date: Thu, 5 Jan 2023 22:30:02 UTC

Severity: normal

Found in version 30.0.50

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 60585 <at> debbugs.gnu.org, rpluim <at> gmail.com
Subject: bug#60585: 30.0.50; global-text-scale-adjust shrinks window (was not before), was: Re: bug#52493: 29.0.50; Setting Inconsolata up in init.el makes default face rendered wrong
Date: Fri, 27 Jan 2023 10:35:43 +0100
>> (118 vs 112 looks slightly preposterous BTW - it would mean that
>> scroll bar and fringes are six characters wide.  Here both width and
>> height differ by 1 only.)
>
> They're definitely not that. I would roughly estimate that the scroll
> bar plus the right fringe are about 2-3 characters wide. And the left
> fringe is about 1/2 a character.

I underestimated the scaling effect.  With a character width scaled from
17 to 8 a base_width of 32 and a native width of 1952 pixels we get

(/ (- (/ 1952 2) 32) 8) ~> 118

On the other hand with 1904 text pixels (scroll bar + fringes are the
remaining 48 pixels) and the unscaled character width we get

(/ 1904 17) ~> 112

This shows how scaling strongly affects whatever GNOME displays here and
what Emacs uses internally.  It might be illustrative to put two equally
sized frames above each other - one from a GTK and one from a Lucid
build - and look at what size hints GNOME displays for each of them.

For the rest, the transcript nowhere shows that the GNOME hints jump by
two or more after 'set-face-attribute'.  Can you spot such behavior?

There are jumps like these

xg_frame_resized old native pixels 1472x1368 new native pixels 1568x1404
adjust_frame_size old native pixels 1472x1368 new native pixels 1568x1404 old text pixels 1424x1368 new text pixels 1520x1404 old text chars 83x36 new text chars 89x37
    base_size 32x84 size increments 8x18 WM hint 94x38
xg_frame_resized old native pixels 1568x1404 new native pixels 1712x1440
adjust_frame_size old native pixels 1568x1404 new native pixels 1712x1440 old text pixels 1520x1404 new text pixels 1664x1440 old text chars 89x37 new text chars 97x38
    base_size 32x84 size increments 8x18 WM hint 103x39
xg_frame_resized old native pixels 1712x1440 new native pixels 1984x1548
adjust_frame_size old native pixels 1712x1440 new native pixels 1984x1548 old text pixels 1664x1440 new text pixels 1936x1548 old text chars 97x38 new text chars 113x41
    base_size 32x84 size increments 8x18 WM hint 120x42

during mouse dragging.  But these result from redisplay lagging behind
your drag speed.  Hence subsequent drags are collapsed into larger ones
and Emacs "adjusts" the frame size only after redisplay has decided in
good faith that it now can present the frame to your eyes.

martin




This bug report was last modified 2 years and 205 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.