bug#65183: 29.1; Child frame moving and resizing problems

bug#65183: 29.1; Child frame moving and resizing problems

[陈宇迪]

[-- Attachment #1.1: Type: text/plain, Size: 5762 bytes --]

Start Emacs with `emacs -Q' and evaluate the following code:

;;;;; CODE BEGIN ;;;;;

(defun test-child-frame ()
  (interactive)
  (let ((f (make-frame `((parent-frame . ,(selected-frame))
                         (internal-border-width . 3)
                         (vertical-scroll-bars . nil)
                         (menu-bar-lines . 0)
                         (tool-bar-lines . t)
                         (left . 20)
                         (top . 20)
                         (width . 50)
                         (height . 20))))
        (b (generate-new-buffer "*child-frame-test*")))
    ;; Setup the frame and the buffer.
    (with-selected-frame f
      (switch-to-buffer b)
      (with-current-buffer b
        (set-background-color "black")
        (setq mode-line-format nil)))
    (sit-for 0.3)
    ;; inhibit redisplay
    (let ((inhibit-redisplay t))
      ;; resize
      (set-frame-size f 50 10)
      ;; move
      (set-frame-position f 20 60))
    (sit-for 0.3)
    ;; clean up
    (delete-frame f)
    (kill-buffer b)))

(test-child-frame) ;; Call the function defined above.

;;;;; CODE END ;;;;;

I recorded what I saw and sent it as the attachment "bug_slow_motion.mp4".
Briefly, the child frame appeared, then moved downwards, and then resized.
The moving and resizing are very quick so I slowed down the video (about
10x slower).

There are two problems:

1. I wrap the set size and set position code in a `(let ((inhibit-redisplay
t)) ...)'.
The docstring of `inhibit-redisplay' says "Non-nil means don’t actually do
any redisplay.",
but the process of setting size and setting position is displayed.

2. In the code I gave, `set-frame-size' should be executed before
`set-frame-position'.
But in fact, the child frame was first moved, and then resized. It is in
the wrong order.


In GNU Emacs 29.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.38,
cairo version 1.17.8)
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Arch Linux

Configured using:
 'configure --with-x-toolkit=gtk3 --with-native-compilation=aot
 --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib
 --with-tree-sitter --localstatedir=/var --with-cairo
 --disable-build-details --with-harfbuzz --with-libsystemd
 --with-modules 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt
 -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -g
 -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto'
 'LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto'
 'CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS -g
 -ffile-prefix-map=/build/emacs/src=/usr/src/debug/emacs -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

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

Major mode: ELisp/l

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
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv cl-extra
help-mode bytecomp byte-compile cl-lib sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 79379 8930)
 (symbols 48 7147 0)
 (strings 32 19698 1723)
 (string-bytes 1 576171)
 (vectors 16 16564)
 (vector-slots 8 334975 11306)
 (floats 8 33 71)
 (intervals 56 420 0)
 (buffers 984 14))

[-- Attachment #1.2: Type: text/html, Size: 6514 bytes --]

[-- Attachment #2: bug_slow_motion.mp4 --]
[-- Type: video/mp4, Size: 1290297 bytes --]

bug#65183: 29.1; Child frame moving and resizing problems

[Eli Zaretskii]

> From: 陈宇迪 <jodieydchen@gmail.com>
> Date: Wed, 9 Aug 2023 15:28:16 +0100
> 
> Start Emacs with `emacs -Q' and evaluate the following code:
> 
> ;;;;; CODE BEGIN ;;;;;
> 
> (defun test-child-frame ()
>   (interactive)
>   (let ((f (make-frame `((parent-frame . ,(selected-frame))
>                          (internal-border-width . 3)
>                          (vertical-scroll-bars . nil)
>                          (menu-bar-lines . 0)
>                          (tool-bar-lines . t)
>                          (left . 20)
>                          (top . 20)
>                          (width . 50)
>                          (height . 20))))
>         (b (generate-new-buffer "*child-frame-test*")))
>     ;; Setup the frame and the buffer.
>     (with-selected-frame f
>       (switch-to-buffer b)
>       (with-current-buffer b
>         (set-background-color "black")
>         (setq mode-line-format nil)))
>     (sit-for 0.3)
>     ;; inhibit redisplay
>     (let ((inhibit-redisplay t))
>       ;; resize
>       (set-frame-size f 50 10)
>       ;; move
>       (set-frame-position f 20 60))
>     (sit-for 0.3)
>     ;; clean up
>     (delete-frame f)
>     (kill-buffer b)))
> 
> (test-child-frame) ;; Call the function defined above.
> 
> ;;;;; CODE END ;;;;;
> 
> I recorded what I saw and sent it as the attachment "bug_slow_motion.mp4".
> Briefly, the child frame appeared, then moved downwards, and then resized.
> The moving and resizing are very quick so I slowed down the video (about 10x slower).
> 
> There are two problems:
> 
> 1. I wrap the set size and set position code in a `(let ((inhibit-redisplay t)) ...)'. 
> The docstring of `inhibit-redisplay' says "Non-nil means don’t actually do any redisplay.",
> but the process of setting size and setting position is displayed.

Your interpretation of that variable is incomplete and inaccurate.
Binding it to non-nil inhibits redisplay during the time the binding
is active, but in your case redisplay happens after the function
exits, when the binding is no longer in effect.  The function
set-frame-size doesn't call redisplay, it just modifies the frame
dimension, and the next redisplay cycle then adjusts the frame
accordingly, but that redisplay cycle happens after your function
returns.

> 2. In the code I gave, `set-frame-size' should be executed before `set-frame-position'.
> But in fact, the child frame was first moved, and then resized. It is in the wrong order.

I don't think you can trust the order in this case, as at least some
of the actual move/resize is performed by the window-manager.

Adding Po Lu and Martin, who know this stuff better than I do.

bug#65183: 29.1; Child frame moving and resizing problems

[Eli Zaretskii]

[Please use Reply All to reply, so as to keep the bug address CC'ed.]

> From: 陈宇迪 <jodieydchen@gmail.com>
> Date: Thu, 10 Aug 2023 16:07:19 +0100
> 
> About problem 1:
> Sorry, I didn't express what I meant clearly. 
> In the code I gave, the `set-frame-size' and `set-frame-position' are in the binding
> where `inhibit-redisplay' is `t'. So, both the resizing and the moving are expected
> to be displayed (shown on the screen) after the let binding. 
> However, the resizing and the moving are displayed separately, step by step.
> This is what I cannot understand.

As I tried to explain, the frame is redrawn after your function
returns, and by that time the binding of inhibit-redisplay is no
longer in effect.

You see, in Emacs, redisplay happens when Emacs is idle.  Lisp code
invoked from the Emacs commands changes various variables and
parameters: the buffer text, the window and frame dimensions, etc.;
then the command exits, Emacs gets back to its idle loop, and then
redisplay is called and reflects the changes on the screen.  But by
that time your binding is already undone.

> About problem 2:
> It's said to lean that the order is not controllable from Emacs. 
> But if the first problem can be solved, the order would not matter.
> 
> It seems that the problems only occur on specific platforms.
> I am using KDE with KWin (X11) version 5.27.7. I hope this info can help.
> If anyone tells me how to tweak the KWin to find out the cause, I will try it.

bug#65183: 29.1; Child frame moving and resizing problems

[martin rudalics]

 >> 2. In the code I gave, `set-frame-size' should be executed before `set-frame-position'.
 >> But in fact, the child frame was first moved, and then resized. It is in the wrong order.
 >
 > I don't think you can trust the order in this case, as at least some
 > of the actual move/resize is performed by the window-manager.

... and Emacs only fills its text into the areas provided and exposed by
the window manager.  As a rule, never trust the order of execution in
such case.  Resizing child frames is already tricky enough with GTK3 and
some window managers.  We have the variable 'x-gtk-resize-child-frames'
for that but setting it shouldn't change anything in the case at hand.
Neither should 'x-gtk-use-window-move' help but you can still try.

martin

bug#65183: 29.1; Child frame moving and resizing problems

[陈宇迪]

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

It seems that variables `x-gtk-resize-child-frames' and
`x-gtk-use-window-move' do not help with this.
I am using KDE with KWin (X11) version 5.27.7. I don't know where there is
any known issue on this platform.

From another perspective, is there a way to perform resize and move at the
same time?
(I mean, could the two steps be executed within a single redisplay cycle,
so that users would not see the intermediate changes?)
If these two steps are not done separately, the execution order would not
matter.
As I wrote in my first email, I can see the child frame being moved and
then resized
on my computer, even though the two steps happen very quickly.

martin rudalics <rudalics@gmx.at> 于2023年8月11日周五 08:06写道：

>  >> 2. In the code I gave, `set-frame-size' should be executed before
> `set-frame-position'.
>  >> But in fact, the child frame was first moved, and then resized. It is
> in the wrong order.
>  >
>  > I don't think you can trust the order in this case, as at least some
>  > of the actual move/resize is performed by the window-manager.
>
> ... and Emacs only fills its text into the areas provided and exposed by
> the window manager.  As a rule, never trust the order of execution in
> such case.  Resizing child frames is already tricky enough with GTK3 and
> some window managers.  We have the variable 'x-gtk-resize-child-frames'
> for that but setting it shouldn't change anything in the case at hand.
> Neither should 'x-gtk-use-window-move' help but you can still try.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 2787 bytes --]

bug#65183: 29.1; Child frame moving and resizing problems

[martin rudalics]

 > It seems that variables `x-gtk-resize-child-frames' and
 > `x-gtk-use-window-move' do not help with this.

As expected.

 > I am using KDE with KWin (X11) version 5.27.7. I don't know where there is
 > any known issue on this platform.

AFAICT KDE does not have any such problems.

 >>From another perspective, is there a way to perform resize and move at the
 > same time?

We could try gdk_window_move_resize but we'd have to (1) investigate
whether it works well for child frames and (2) what to do on non-GTK
platforms.

 > (I mean, could the two steps be executed within a single redisplay cycle,
 > so that users would not see the intermediate changes?)
 > If these two steps are not done separately, the execution order would not
 > matter.
 > As I wrote in my first email, I can see the child frame being moved and
 > then resized
 > on my computer, even though the two steps happen very quickly.

What happens when you change 'x-wait-for-event-timeout' to zero?

martin

bug#65183: 29.1; Child frame moving and resizing problems

[陈宇迪]

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

I tried `(setq x-wait-for-event-timeout 0)' and ran the test function.
It was the same.

By the way, I noticed that (though I believe you have read it),
the GTK doc says "(gdk_window_move_resize) avoids strange visual effects.
i.e. the user may be able to see the window first move, then resize,
if you don’t use gdk_window_move_resize().". That is exactly what I saw.

martin rudalics <rudalics@gmx.at> 于2023年8月11日周五 11:00写道：

>  > It seems that variables `x-gtk-resize-child-frames' and
>  > `x-gtk-use-window-move' do not help with this.
>
> As expected.
>
>  > I am using KDE with KWin (X11) version 5.27.7. I don't know where there
> is
>  > any known issue on this platform.
>
> AFAICT KDE does not have any such problems.
>
>  >>From another perspective, is there a way to perform resize and move at
> the
>  > same time?
>
> We could try gdk_window_move_resize but we'd have to (1) investigate
> whether it works well for child frames and (2) what to do on non-GTK
> platforms.
>
>  > (I mean, could the two steps be executed within a single redisplay
> cycle,
>  > so that users would not see the intermediate changes?)
>  > If these two steps are not done separately, the execution order would
> not
>  > matter.
>  > As I wrote in my first email, I can see the child frame being moved and
>  > then resized
>  > on my computer, even though the two steps happen very quickly.
>
> What happens when you change 'x-wait-for-event-timeout' to zero?
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 2018 bytes --]

bug#65183: 29.1; Child frame moving and resizing problems

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

How is Emacs meant to establish when XMoveResizeWindow is desired?  We
don't have a function for altering both the size and position of a
frame.

bug#65183: 29.1; Child frame moving and resizing problems

[martin rudalics]

 > How is Emacs meant to establish when XMoveResizeWindow is desired?  We
 > don't have a function for altering both the size and position of a
 > frame.

We'd add a suitable front-end and leave it to users and package writers
whether they want to call it.  'mouse-drag-frame-resize' could profit
from it if we have 'modify-frame-parameters' detect whether both
top/left and width/height shall be changed in one and the same call.
Maybe by adding a set_window_size_and_offset_hook.

martin

bug#65183: 29.1; Child frame moving and resizing problems

[martin rudalics]

 > By the way, I noticed that (though I believe you have read it),
 > the GTK doc says "(gdk_window_move_resize) avoids strange visual effects.
 > i.e. the user may be able to see the window first move, then resize,
 > if you don’t use gdk_window_move_resize().". That is exactly what I saw.

I think nobody would oppose the addition of a function like
'set-frame-size-and-position'.  On other X platforms we would end up
calling XMoveResizeWindow and on Windows MoveWindow.  Where we don't
find a suitable back-end we'd have to use two calls.  Could you try
writing it?

martin

bug#65183: 29.1; Child frame moving and resizing problems

[陈宇迪]

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

Of course, I'm happy to try writing this.

But there is one thing that I don't know what the best solution is: how to
reuse the code
in the function `adjust_frame_size' (defined in src/frame.c, used by
`set-frame-size')?
I want to add two arguments: `new_x' and `new_y'. When  `new_x' and `new_y'
are the
same with the current frame position, execute the original branch
(`set_window_size_hook'
or `resize_frame_window'); otherwise, call a move and resize function.
But I have to rename this function to `adjust_frame_position_and_size'. For
compatibility,
I will also create a wrapper function called `adjust_frame_size', in which
`adjust_frame_position_and_size' is called with the current frame position
as the last two args
so that the frame will be only resized but not moved.
Do you think this is an appropriate solution?

[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

bug#65183: 29.1; Child frame moving and resizing problems

[martin rudalics]

 > But there is one thing that I don't know what the best solution is: how to
 > reuse the code
 > in the function `adjust_frame_size' (defined in src/frame.c, used by
 > `set-frame-size')?
 > I want to add two arguments: `new_x' and `new_y'. When  `new_x' and `new_y'
 > are the
 > same with the current frame position,

... with GNOME/mutter it's hard to tell but that shouldn't bother us
here ...

 > execute the original branch
 > (`set_window_size_hook'
 > or `resize_frame_window'); otherwise, call a move and resize function.
 > But I have to rename this function to `adjust_frame_position_and_size'. For
 > compatibility,

Alternatively you could put new_x and new_y together with an identifier
(say 'size_and_position') into PARAMETER and extract them before running
the hook.  INHIBIT would be 1 anyway, so frame_inhibit_resize is of no
concern here.

 > I will also create a wrapper function called `adjust_frame_size', in which
 > `adjust_frame_position_and_size' is called with the current frame position
 > as the last two args

This is the crucial point - rewriting all those adjust_frame_size calls
would be a great pain.

 > so that the frame will be only resized but not moved.
 > Do you think this is an appropriate solution?

I think so, yes.

Before coding other backends of set_window_size_hook make sure that the
code gives the desired results on your own system to avoid writing them
without any gain.

martin

bug#65183: 29.1; Child frame moving and resizing problems

[陈宇迪]

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

Since I'm not familiar with Emacs' source code and the ideas, I find it
difficult
to write the patch code that has fewer duplicates, covers all corner cases,
and is easy to maintain. So, I decided not to write this code.

But I'm sure the resize and move functions can solve the issue that I
mentioned
in my first email, based on my tests.

By the way, I suggest naming the function to add as
`set-frame-position-and-size'
instead of `set-frame-size-and-position', because most underlying APIs are
called
xxx_move_resize_xxx: `gdk_window_move_resize' (GTK), `XMoveResizeWindow'
(X11),
`MoveWindow(hWnd, X, Y, nWidth, nHeight, bRepaint)' (Windows).

martin rudalics <rudalics@gmx.at> 于2023年8月13日周日 08:21写道：

>  > But there is one thing that I don't know what the best solution is: how
> to
>  > reuse the code
>  > in the function `adjust_frame_size' (defined in src/frame.c, used by
>  > `set-frame-size')?
>  > I want to add two arguments: `new_x' and `new_y'. When  `new_x' and
> `new_y'
>  > are the
>  > same with the current frame position,
>
> ... with GNOME/mutter it's hard to tell but that shouldn't bother us
> here ...
>
>  > execute the original branch
>  > (`set_window_size_hook'
>  > or `resize_frame_window'); otherwise, call a move and resize function.
>  > But I have to rename this function to `adjust_frame_position_and_size'.
> For
>  > compatibility,
>
> Alternatively you could put new_x and new_y together with an identifier
> (say 'size_and_position') into PARAMETER and extract them before running
> the hook.  INHIBIT would be 1 anyway, so frame_inhibit_resize is of no
> concern here.
>
>  > I will also create a wrapper function called `adjust_frame_size', in
> which
>  > `adjust_frame_position_and_size' is called with the current frame
> position
>  > as the last two args
>
> This is the crucial point - rewriting all those adjust_frame_size calls
> would be a great pain.
>
>  > so that the frame will be only resized but not moved.
>  > Do you think this is an appropriate solution?
>
> I think so, yes.
>
> Before coding other backends of set_window_size_hook make sure that the
> code gives the desired results on your own system to avoid writing them
> without any gain.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 3179 bytes --]

bug#65183: 29.1; Child frame moving and resizing problems

[martin rudalics]

 > Since I'm not familiar with Emacs' source code and the ideas, I find it
 > difficult
 > to write the patch code that has fewer duplicates, covers all corner cases,
 > and is easy to maintain. So, I decided not to write this code.

That's a pity.  From what you wrote so far I was convinced that you had
already covered everything needed.

 > But I'm sure the resize and move functions can solve the issue that I
 > mentioned
 > in my first email, based on my tests.
 >
 > By the way, I suggest naming the function to add as
 > `set-frame-position-and-size'
 > instead of `set-frame-size-and-position', because most underlying APIs are
 > called
 > xxx_move_resize_xxx: `gdk_window_move_resize' (GTK), `XMoveResizeWindow'
 > (X11),
 > `MoveWindow(hWnd, X, Y, nWidth, nHeight, bRepaint)' (Windows).

I'll look into it when I have time.

Thanks, martin