* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger @ 2021-08-08 3:01 Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-08-09 16:12 ` Robert Pluim 0 siblings, 1 reply; 10+ messages in thread From: Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-08 3:01 UTC (permalink / raw) To: 49937 [-- 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 --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-08 3:01 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 @ 2021-08-09 16:12 ` Robert Pluim 2021-08-09 16:48 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-08-09 21:45 ` Alan Third 0 siblings, 2 replies; 10+ messages in thread From: Robert Pluim @ 2021-08-09 16:12 UTC (permalink / raw) To: 49937; +Cc: Visuwesh >>>>> 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 -- ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-09 16:12 ` Robert Pluim @ 2021-08-09 16:48 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-08-09 21:45 ` Alan Third 1 sibling, 0 replies; 10+ messages in thread From: Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-09 16:48 UTC (permalink / raw) To: Robert Pluim; +Cc: 49937 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"))) ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-09 16:12 ` Robert Pluim 2021-08-09 16:48 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-09 21:45 ` Alan Third 2021-08-10 12:51 ` Lars Ingebrigtsen 1 sibling, 1 reply; 10+ messages in thread From: Alan Third @ 2021-08-09 21:45 UTC (permalink / raw) To: Robert Pluim; +Cc: Visuwesh, 49937 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-09 21:45 ` Alan Third @ 2021-08-10 12:51 ` Lars Ingebrigtsen 2021-08-10 14:55 ` Robert Pluim 0 siblings, 1 reply; 10+ messages in thread From: Lars Ingebrigtsen @ 2021-08-10 12:51 UTC (permalink / raw) To: Alan Third; +Cc: Robert Pluim, 49937, Visuwesh 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-10 12:51 ` Lars Ingebrigtsen @ 2021-08-10 14:55 ` Robert Pluim 2021-08-21 12:30 ` Alan Third 2022-08-22 11:53 ` Lars Ingebrigtsen 0 siblings, 2 replies; 10+ messages in thread From: Robert Pluim @ 2021-08-10 14:55 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: Alan Third, 49937, Visuwesh >>>>> 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 -- ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-10 14:55 ` Robert Pluim @ 2021-08-21 12:30 ` Alan Third 2021-08-21 12:47 ` Eli Zaretskii 2021-08-22 9:14 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-08-22 11:53 ` Lars Ingebrigtsen 1 sibling, 2 replies; 10+ messages in thread From: Alan Third @ 2021-08-21 12:30 UTC (permalink / raw) To: Robert Pluim; +Cc: Lars Ingebrigtsen, 49937, Visuwesh 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-21 12:30 ` Alan Third @ 2021-08-21 12:47 ` Eli Zaretskii 2021-08-22 9:14 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2021-08-21 12:47 UTC (permalink / raw) To: Alan Third; +Cc: larsi, visuwesh, 49937, rpluim > 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-21 12:30 ` Alan Third 2021-08-21 12:47 ` Eli Zaretskii @ 2021-08-22 9:14 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 0 replies; 10+ messages in thread From: Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2021-08-22 9:14 UTC (permalink / raw) To: Alan Third; +Cc: Robert Pluim, 49937, Lars Ingebrigtsen 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#49937: 28.0.50; feature/pgtk: tetris blocks are comparatively larger 2021-08-10 14:55 ` Robert Pluim 2021-08-21 12:30 ` Alan Third @ 2022-08-22 11:53 ` Lars Ingebrigtsen 1 sibling, 0 replies; 10+ messages in thread From: Lars Ingebrigtsen @ 2022-08-22 11:53 UTC (permalink / raw) To: Robert Pluim; +Cc: Alan Third, 49937, Visuwesh 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-08-22 11:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-08-08 3:01 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 2021-08-09 16:12 ` Robert Pluim 2021-08-09 16:48 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2021-08-09 21:45 ` Alan Third 2021-08-10 12:51 ` Lars Ingebrigtsen 2021-08-10 14:55 ` Robert Pluim 2021-08-21 12:30 ` Alan Third 2021-08-21 12:47 ` Eli Zaretskii 2021-08-22 9:14 ` Visuwesh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-08-22 11:53 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).