bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]

In tetris, pong and friends, the size of each grid is much larger in
the pgtk branch compared to master (see the attached files).  However,
I'm not sure if this can be considered a bug since the physical size of
each grid, measured using a ruler, is 7 mm in the pgtk branch as one
would expect from the value of `gamegrid-glyph-height-mm'.


In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27, cairo version 1.16.0)
Repository revision: 13a9a5e836cbe6e64aadaba40fe1f7eb83320d08
Repository branch: master
Windowing system distributor 'System Description: NixOS 21.11 (Porcupine)

Configured using:
'configure
--prefix=/nix/store/wfl7dxjy5zm2mb2rsrmfli12jrxzjqn9-emacs-pgtk-20210725.0
--disable-build-details --with-modules --with-x-toolkit=gtk3
--with-cairo --with-pgtk'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PGTK
PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XIM GTK3 ZLIB

Important settings:
  value of $EMACSLOADPATH:
  value of $EMACSNATIVELOADPATH: /nix/store/ld3lv1bbi9zx15k3h5hni467gyqxckjr-emacs-packages-deps/share/emacs/native-lisp::
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  view-mode: t

Load-path shadows:
None found.

Features:
(dabbrev view vc-git diff-mode easy-mmode vc-dispatcher cl-extra smiley
ansi-color gnus-cite mm-archive jka-compr gnus-msg gnus-art mm-uu
mml2015 mm-view mml-smime smime dig gnus-sum shr kinsoku svg dom
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse url-vars gnus-group gnus-undo
gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7
netrc nnoo parse-time iso8601 gnus-spec gnus-int gnus-range gnus-win
gnus nnheader mailcap cus-edit cus-start cus-load wid-edit help-mode pp
shadow sort mail-extr ispell emacsbug message rmc puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg epg-config gnus-util
rmail rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search seq byte-opt
gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils time-date subr-x cl-loaddefs
cl-lib disp-table tetris gamegrid iso-transl tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/pgtk-win
pgtk-win term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit pgtk multi-tty make-network-process emacs)

Memory information:
((conses 16 147251 9401)
(symbols 48 15021 0)
(strings 32 45794 2504)
(string-bytes 1 1615778)
(vectors 16 28360)
(vector-slots 8 320281 12896)
(floats 8 221 59)
(intervals 56 909 434)
(buffers 992 27))



[-- Attachment #2: emacs-master.png --]
[-- Type: image/png, Size: 58906 bytes --]

[-- Attachment #3: emacs-pgtk.png --]
[-- Type: image/png, Size: 65355 bytes --]

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Robert Pluim]

>>>>> On Sun, 8 Aug 2021 05:01:29 +0200 (CEST), Visuwesh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:

    Visuwesh> In tetris, pong and friends, the size of each grid is much larger in
    Visuwesh> the pgtk branch compared to master (see the attached files).  However,
    Visuwesh> I'm not sure if this can be considered a bug since the physical size of
    Visuwesh> each grid, measured using a ruler, is 7 mm in the pgtk branch as one
    Visuwesh> would expect from the value of `gamegrid-glyph-height-mm'.

Are they using the same font? You can check by putting point on one of
the blocks and doing 'C-u C-x ='

Robert
-- 

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

9 Aug 2021, 21:42 by rpluim@gmail.com:

>>>>>> On Sun, 8 Aug 2021 05:01:29 +0200 (CEST), Visuwesh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
>>>>>>
>
> Visuwesh> In tetris, pong and friends, the size of each grid is much larger in
>  Visuwesh> the pgtk branch compared to master (see the attached files).  However,
>  Visuwesh> I'm not sure if this can be considered a bug since the physical size of
>  Visuwesh> each grid, measured using a ruler, is 7 mm in the pgtk branch as one
>  Visuwesh> would expect from the value of `gamegrid-glyph-height-mm'.
>
> Are they using the same font? You can check by putting point on one of
> the blocks and doing 'C-u C-x ='
>
> Robert
> --
>
Are you sure the font size affects the display?  Doing as you suggested, I get
the following.

what-cursor-position: Wrong type argument: arrayp, (image :type xpm :data "/* XPM */
static char *noname[] = {
/* width height ncolors chars_per_pixel */
\"24 24 3 1\",
/* colors */
\"+ s col1\",
\". s col2\",
\"- s col3\",
/* pixels */
\"-----------------------+\",
\"----------------------++\",
\"---------------------+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"---..................+++\",
\"--++++++++++++++++++++++\",
\"-+++++++++++++++++++++++\",
\"++++++++++++++++++++++++\"
};
" :ascent center :color-symbols (("col1" . "#4c4c4c") ("col2" . "#666666") ("col3" . "#7f7f7f")))

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Alan Third]

On Mon, Aug 09, 2021 at 06:12:33PM +0200, Robert Pluim wrote:
> >>>>> On Sun, 8 Aug 2021 05:01:29 +0200 (CEST), Visuwesh via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> said:
> 
>     Visuwesh> In tetris, pong and friends, the size of each grid is much larger in
>     Visuwesh> the pgtk branch compared to master (see the attached files).  However,
>     Visuwesh> I'm not sure if this can be considered a bug since the physical size of
>     Visuwesh> each grid, measured using a ruler, is 7 mm in the pgtk branch as one
>     Visuwesh> would expect from the value of `gamegrid-glyph-height-mm'.
> 
> Are they using the same font? You can check by putting point on one of
> the blocks and doing 'C-u C-x ='

They're images, ostensibly 7mm in height but it appears on X (and NS)
they're much smaller. I imagine it depends on the screen's reported
DPI since the gamegrid code appears to calculate the size using it.

-- 
Alan Third

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> They're images, ostensibly 7mm in height but it appears on X (and NS)
> they're much smaller. I imagine it depends on the screen's reported
> DPI since the gamegrid code appears to calculate the size using it.

I think this is bug#47039 -- pgtk scales images correctly, which images
found via `find-image' are not scaled correctly on the trunk.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Robert Pluim]

>>>>> On Tue, 10 Aug 2021 14:51:44 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:

    Lars> Alan Third <alan@idiocy.org> writes:
    >> They're images, ostensibly 7mm in height but it appears on X (and NS)
    >> they're much smaller. I imagine it depends on the screen's reported
    >> DPI since the gamegrid code appears to calculate the size using it.

    Lars> I think this is bug#47039 -- pgtk scales images correctly, which images
    Lars> found via `find-image' are not scaled correctly on the trunk.

The images in this case are created on the fly by gamegrid.el, which
uses 'display-mm-height', which gives the wrong answer under X:

ELISP> (display-mm-height)
572

In pgtk itʼs correct:

ELISP> (display-mm-height)
190 (#o276, #xbe)

We could change gamegrid.el to use 'display-monitor-attributes-list'
instead, that gives the right values under both:

X:

ELISP> (display-monitor-attributes-list)
(((name . "XWAYLAND0")
  (geometry 0 0 3840 2160)
  (workarea 0 26 3840 2100)
  (mm-size 350 190)
  (frames #<frame *ielm* - GNU Emacs at rltb 0x564418c8a710>)
  (source . "Gdk")))

pgtk under wayland:

ELISP> (display-monitor-attributes-list)
(((name . "0x1431")
  (geometry 0 0 3840 2160)
  (workarea 0 0 3840 2160)
  (mm-size 350 190)
  (scale-factor . 1.0)
  (frames #<frame *ielm* - GNU Emacs at rltb 0x561d802c4670>)
  (source . "Gdk")))

Robert
-- 

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Alan Third]

On Tue, Aug 10, 2021 at 04:55:24PM +0200, Robert Pluim wrote:
> >>>>> On Tue, 10 Aug 2021 14:51:44 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
> 
>     Lars> Alan Third <alan@idiocy.org> writes:
>     >> They're images, ostensibly 7mm in height but it appears on X (and NS)
>     >> they're much smaller. I imagine it depends on the screen's reported
>     >> DPI since the gamegrid code appears to calculate the size using it.
> 
>     Lars> I think this is bug#47039 -- pgtk scales images correctly, which images
>     Lars> found via `find-image' are not scaled correctly on the trunk.
> 
> The images in this case are created on the fly by gamegrid.el, which
> uses 'display-mm-height', which gives the wrong answer under X:
> 
> ELISP> (display-mm-height)
> 572
> 
> In pgtk itʼs correct:
> 
> ELISP> (display-mm-height)
> 190 (#o276, #xbe)
> 
> We could change gamegrid.el to use 'display-monitor-attributes-list'
> instead, that gives the right values under both:

Sounds reasonable to me, although I wonder if we'll get a bunch of bug
reports complaining their tetris is too big for their screen now. ;)

Alternatively, should we fix display-mm-height to give the correct
value? Presumably it must be possible. I think we manage to display
SVG images at the correct size by calculating the real DPI...

(Except on macOS where the "DPI" is a magic number decided by Apple.)
-- 
Alan Third

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Eli Zaretskii]

> Date: Sat, 21 Aug 2021 13:30:49 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 49937@debbugs.gnu.org,
>  Visuwesh <visuwesh@tutanota.com>
> 
> > We could change gamegrid.el to use 'display-monitor-attributes-list'
> > instead, that gives the right values under both:
> 
> Sounds reasonable to me, although I wonder if we'll get a bunch of bug
> reports complaining their tetris is too big for their screen now. ;)
> 
> Alternatively, should we fix display-mm-height to give the correct
> value?

Yes, we probably should.

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors]

21 Aug 2021, 18:00 by alan@idiocy.org:

> On Tue, Aug 10, 2021 at 04:55:24PM +0200, Robert Pluim wrote:
>
>> >>>>> On Tue, 10 Aug 2021 14:51:44 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
>>
>>  Lars> Alan Third <alan@idiocy.org> writes:
>>  >> They're images, ostensibly 7mm in height but it appears on X (and NS)
>>  >> they're much smaller. I imagine it depends on the screen's reported
>>  >> DPI since the gamegrid code appears to calculate the size using it.
>>
>>  Lars> I think this is bug#47039 -- pgtk scales images correctly, which images
>>  Lars> found via `find-image' are not scaled correctly on the trunk.
>>
>> The images in this case are created on the fly by gamegrid.el, which
>> uses 'display-mm-height', which gives the wrong answer under X:
>>
>> ELISP> (display-mm-height)
>> 572
>>
>> In pgtk itʼs correct:
>>
>> ELISP> (display-mm-height)
>> 190 (#o276, #xbe)
>>
>> We could change gamegrid.el to use 'display-monitor-attributes-list'
>> instead, that gives the right values under both:
>>
>
> Sounds reasonable to me, although I wonder if we'll get a bunch of bug
> reports complaining their tetris is too big for their screen now. ;)
>
Count me in.  :P I play tetris often enough to find the huge block sizes
annoying.

bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> We could change gamegrid.el to use 'display-monitor-attributes-list'
> instead, that gives the right values under both:

I've now done this in Emacs 29.