GNU bug report logs - #52042
29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from a scale@1x display to a scale@2x display

Previous Next

To reply to this bug, email your comments to 52042 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Fred Fu <moonsolo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [feature/pgtk] issue in moving a fullscreen emacs frame from
 a scale <at> 1x display to a scale <at> 2x display
Date: Mon, 22 Nov 2021 12:43:57 -0500

[Message part 1 (text/plain, inline)]

Hi,

Firstly, thanks for the hard work.

My DE is gnome 41. I have three monitors sitting in a row: the left
and middle runs at 3840 * 2160 with a scale factor of 2, the right
runs at 1920*1080 with a scale factor of 1.

When I move an *fullscreen* emacs frame from the right display to the
middle one,  the frame gets stretched over the two displays and the
text in the part of the frame on the middle display becomes blurry. I
have to move the frame again to the middle display to get the frame
back to normal.

This issue does not happen when I move a frame between the left and
middle display.  It neither happens when I use a non-pgtk build.

Here are the minimal steps to reproduce with emacs -Q:

1. move the frame to the right display (using super+shift+right)

2. make the emacs frame fullscreen (using super+up). See the attached
image file named "start".

3. move it to the middle display (using super+shift+left). The frame
gets stretched over the two displays. See the attached image file
named "stretched".

4. move it to the middle display again (using super+shift+left). The
frame now looks right on the middle display. See the attached image
file named "end".

In GNU Emacs 29.0.50 (build 5, x86_64-pc-linux-gnu, GTK+ Version
3.24.30, cairo version 1.16.0)
 of 2021-11-14 built on localhost.localdomain
Repository revision: f1a60225152af1f87d8580db0785cf5a0a9c7544
Repository branch: pgtk
Windowing system distributor 'System Description: openSUSE Tumbleweed

Configured using:
 'configure --with-native-compilation --prefix=/home/capfredf/.local/
 --with-pgtk'

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

Important settings:
  value of $LC_CTYPE: en_US.utf-8
  value of $LANG: en_US.utf-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068
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 time-date seq gv subr-x byte-opt 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 help-mode cl-loaddefs cl-lib iso-transl
tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/pgtk-win pgtk-win term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-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 emoji-zwj 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 lcms2 multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 79732 6491)
 (symbols 48 6800 0)
 (strings 32 20166 2340)
 (string-bytes 1 676176)
 (vectors 16 14281)
 (vector-slots 8 255752 11716)
 (floats 8 24 44)
 (intervals 56 482 0)
 (buffers 992 10))


-- 
Best regards
F

[start.png (image/png, attachment)]

[stretched.png (image/png, attachment)]

[end.png (image/png, attachment)]

Message #8 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: moonsolo <at> gmail.com
Cc: 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a
 fullscreen emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Wed, 01 Dec 2021 00:59:29 +0900 (JST)

On Mon, 22 Nov 2021 12:43:57 -0500,
	Fred Fu <moonsolo <at> gmail.com> wrote:
> Here are the minimal steps to reproduce with emacs -Q:
> 
> 1. move the frame to the right display (using super+shift+right)
> 
> 2. make the emacs frame fullscreen (using super+up). See the attached
> image file named "start".
> 
> 3. move it to the middle display (using super+shift+left). The frame
> gets stretched over the two displays. See the attached image file
> named "stretched".
> 
> 4. move it to the middle display again (using super+shift+left). The
> frame now looks right on the middle display. See the attached image
> file named "end".

Thanks for the steps to reproduce.
But I don't have 3 monitors, so I can't reproduce it.

-- 
Yuuki Harano

Message #11 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Fred Fu <moonsolo <at> gmail.com>
To: Yuuki Harano <masm+emacs <at> masm11.me>
Cc: 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen
 emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Tue, 30 Nov 2021 11:10:37 -0500

Hi Yuuki,

The stretching issue seems a Gnome/Mutter issue, because other GTK
applications have the same problem.
But that the text becomes blurry only happens to the pgtk port.

On Tue, Nov 30, 2021 at 10:59 AM Yuuki Harano <masm+emacs <at> masm11.me> wrote:
>
>
> On Mon, 22 Nov 2021 12:43:57 -0500,
>         Fred Fu <moonsolo <at> gmail.com> wrote:
> > Here are the minimal steps to reproduce with emacs -Q:
> >
> > 1. move the frame to the right display (using super+shift+right)
> >
> > 2. make the emacs frame fullscreen (using super+up). See the attached
> > image file named "start".
> >
> > 3. move it to the middle display (using super+shift+left). The frame
> > gets stretched over the two displays. See the attached image file
> > named "stretched".
> >
> > 4. move it to the middle display again (using super+shift+left). The
> > frame now looks right on the middle display. See the attached image
> > file named "end".
>
> Thanks for the steps to reproduce.
> But I don't have 3 monitors, so I can't reproduce it.

I don't think three monitors are needed. Two monitors, one scaled <at> 2x
and one @1x, should be enough to reproduce the issue.

That said, I'd love to help debug this issue on my end, but I don't
know what to start with. Any ideas?


> --
> Yuuki Harano



-- 
Best regards
F

Message #14 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: moonsolo <at> gmail.com
Cc: 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a
 fullscreen emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Thu, 02 Dec 2021 00:08:56 +0900 (JST)

On Tue, 30 Nov 2021 11:10:37 -0500,
	Fred Fu <moonsolo <at> gmail.com> wrote:
> I don't think three monitors are needed. Two monitors, one scaled <at> 2x
> and one @1x, should be enough to reproduce the issue.

Reproduced.
I have a TV, that can be connected to my note PC, and tried GNOME(Wayland).
The PC's monitor is 2x and the TV is 1x.
I moved a pgtk emacs frame from the TV to the PC's monitor, and it became
blurry.  When I resized it, it recovered.

> That said, I'd love to help debug this issue on my end, but I don't
> know what to start with. Any ideas?

I have a cairo_surface_t and draw on it.  And I copy it on gtk window
when gtk wants so.
I don't scale fonts explicitly.  Scaling is done implicitly by compositor,
gtk, and cairo.

My guess:
cairo_surface_t is bitmap.
On 1x, cairo_surface_t has non-scaled texts, and it is drawn on
gtk window as is.
When I move it to 2x, cairo_surface_t is drawn on gtk window
at double size.  It is blurry, because cairo_surface_it is bitmap.
When I resize it, I recreate cairo_surface_t of logical size.
When that, cairo_surface_t is double size implicitly.
cairo_surface_t has 2x scaled texts.  It is not blurry, because
fonts are vector graphics.
It is drawn on gtk window as is.

Maybe, I need to recreate cairo_surface_t when monitor
is changed.  I looked for such a signal but nothing found.

-- 
Yuuki Harano

Message #17 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Fred Fu <moonsolo <at> gmail.com>
To: Yuuki Harano <masm+emacs <at> masm11.me>
Cc: 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen
 emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Wed, 1 Dec 2021 10:20:41 -0500

[Message part 1 (text/plain, inline)]

I have zero knowledge of GTK thus I have some dump questions:

How do GTK applications handle this situation?

Does each gnome app deal with their windows moving among displays of scale
factors on their own?

Or do they just delegate the dirty job to GTK or other lower-level
mechanisms?

On Wed, Dec 1, 2021, 10:09 AM Yuuki Harano <masm+emacs <at> masm11.me> wrote:

>
> On Tue, 30 Nov 2021 11:10:37 -0500,
>         Fred Fu <moonsolo <at> gmail.com> wrote:
> > I don't think three monitors are needed. Two monitors, one scaled <at> 2x
> > and one @1x, should be enough to reproduce the issue.
>
> Reproduced.
> I have a TV, that can be connected to my note PC, and tried GNOME(Wayland).
> The PC's monitor is 2x and the TV is 1x.
> I moved a pgtk emacs frame from the TV to the PC's monitor, and it became
> blurry.  When I resized it, it recovered.
>
> > That said, I'd love to help debug this issue on my end, but I don't
> > know what to start with. Any ideas?
>
> I have a cairo_surface_t and draw on it.  And I copy it on gtk window
> when gtk wants so.
> I don't scale fonts explicitly.  Scaling is done implicitly by compositor,
> gtk, and cairo.
>
> My guess:
> cairo_surface_t is bitmap.
> On 1x, cairo_surface_t has non-scaled texts, and it is drawn on
> gtk window as is.
> When I move it to 2x, cairo_surface_t is drawn on gtk window
> at double size.  It is blurry, because cairo_surface_it is bitmap.
> When I resize it, I recreate cairo_surface_t of logical size.
> When that, cairo_surface_t is double size implicitly.
> cairo_surface_t has 2x scaled texts.  It is not blurry, because
> fonts are vector graphics.
> It is drawn on gtk window as is.
>
> Maybe, I need to recreate cairo_surface_t when monitor
> is changed.  I looked for such a signal but nothing found.
>
> --
> Yuuki Harano
>

[Message part 2 (text/html, inline)]

Message #20 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: moonsolo <at> gmail.com
Cc: 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a
 fullscreen emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Thu, 02 Dec 2021 00:47:20 +0900 (JST)

On Wed, 1 Dec 2021 10:20:41 -0500,
	Fred Fu <moonsolo <at> gmail.com> wrote:
> How do GTK applications handle this situation?
> 
> Does each gnome app deal with their windows moving among displays of scale
> factors on their own?
> 
> Or do they just delegate the dirty job to GTK or other lower-level
> mechanisms?

Switching scale factor among display is usually done by gtk.
Usual applications create cairo_surface_t(bitmap), use it for a short
time, and destroy it.  When creating it, scaling factor is reflected.

Pgtk emacs create cairo_surface_t, use it for a long time for cost and
algorithms, and scaling factor is not reflected until recreation.

-- 
Yuuki Harano

Message #23 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Yuuki Harano <masm+emacs <at> masm11.me>
Cc: moonsolo <at> gmail.com, 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen
 emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Thu, 2 Dec 2021 22:09:53 +0000

On Thu, Dec 02, 2021 at 12:08:56AM +0900, Yuuki Harano wrote:
> Maybe, I need to recreate cairo_surface_t when monitor
> is changed.  I looked for such a signal but nothing found.

On the NS port whenever we create the context for drawing to the
bitmap we compare the dimensions/scaling. It's not ideal but it
doesn't seem to cause any noticeable slowdown. Perhaps PGTK can do
something similar?
-- 
Alan Third

Message #26 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Yuuki Harano <masm+emacs <at> masm11.me>, moonsolo <at> gmail.com,
 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a fullscreen
 emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Thu, 2 Dec 2021 22:12:48 +0000

On Thu, Dec 02, 2021 at 10:09:54PM +0000, Alan Third wrote:
> On Thu, Dec 02, 2021 at 12:08:56AM +0900, Yuuki Harano wrote:
> > Maybe, I need to recreate cairo_surface_t when monitor
> > is changed.  I looked for such a signal but nothing found.
> 
> On the NS port whenever we create the context for drawing to the
> bitmap we compare the dimensions/scaling. It's not ideal but it
> doesn't seem to cause any noticeable slowdown. Perhaps PGTK can do
> something similar?

But then, having said that, I've just remembered we also call
expose_frame when the scale changes. That may not be possible if
there's no signal to let you know.
-- 
Alan Third

Message #29 received at 52042 <at> debbugs.gnu.org (full text, mbox):

From: Yuuki Harano <masm+emacs <at> masm11.me>
To: moonsolo <at> gmail.com
Cc: 52042 <at> debbugs.gnu.org
Subject: Re: bug#52042: 29.0.50; [feature/pgtk] issue in moving a
 fullscreen emacs frame from a scale <at> 1x display to a scale <at> 2x display
Date: Sat, 04 Dec 2021 16:41:56 +0900 (JST)

I tried to keep track of scale factor using atimer.
I can see bluriness for a short time, but it is gone soon.
I think that is enough.

-- 
Yuuki Harano

Previous Next

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