Re: Emacs's set-frame-size can not work well with gnome-shell?

Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

>  > Unfortunately, I'm getting reports that the Lucid build is much slower
>  > than GTK at least for some others:
> 
> I can't comment on that.  I only have non-optimized Lucid builds here
> and they are much too slow to do anything with child frames at all.

Today I test lucid emacs again,  maybe the slowness is  posn-at-point

(benchmark 1000 '(posn-at-point (point)))

"Elapsed time: 0.684959s"

for posframe call posn-at-point

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > Today I test lucid emacs again,  maybe the slowness is  posn-at-point
 >
 > (benchmark 1000 '(posn-at-point (point)))
 >
 > "Elapsed time: 0.684959s"
 >
 > for posframe call posn-at-point

And what do you get for a GTK build?  Here I get

in an O3 GTK build  Elapsed time: 0.590930s (0.175256s in 3 GCs)

in an O0 GTK build  Elapsed time: 2.644455s (0.764866s in 4 GCs)

in an O0 Lucid build  Elapsed time: 2.785499s (0.776188s in 4 GCs)

martin

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

At 2020-01-22 17:09:11, "martin rudalics" <rudalics@gmx.at> wrote:
> > Today I test lucid emacs again,  maybe the slowness is  posn-at-point
> >
> > (benchmark 1000 '(posn-at-point (point)))
> >
> > "Elapsed time: 0.684959s"
> >
> > for posframe call posn-at-point
>
>And what do you get for a GTK build?  Here I get
>
>in an O3 GTK build  Elapsed time: 0.590930s (0.175256s in 3 GCs)
>
>in an O0 GTK build  Elapsed time: 2.644455s (0.764866s in 4 GCs)
>
>in an O0 Lucid build  Elapsed time: 2.785499s (0.776188s in 4 GCs)
>
>martin

just ./configure

"Elapsed time: 0.209364s (0.025391s in 1 GCs)"

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

At 2020-01-22 17:09:11, "martin rudalics" <rudalics@gmx.at> wrote:
> > Today I test lucid emacs again,  maybe the slowness is  posn-at-point
> >
> > (benchmark 1000 '(posn-at-point (point)))
> >
> > "Elapsed time: 0.684959s"
> >
> > for posframe call posn-at-point
>
>And what do you get for a GTK build?  Here I get
>
>in an O3 GTK build  Elapsed time: 0.590930s (0.175256s in 3 GCs)
>
>in an O0 GTK build  Elapsed time: 2.644455s (0.764866s in 4 GCs)
>
>in an O0 Lucid build  Elapsed time: 2.785499s (0.776188s in 4 GCs)
>
>martin


Mark set
Elapsed time: 0.235007s (0.050980s in 2 GCs)
"Elapsed time: 0.235007s (0.050980s in 2 GCs)"
Elapsed time: 0.209364s (0.025391s in 1 GCs)
"Elapsed time: 0.209364s (0.025391s in 1 GCs)"
Mark activated
Elapsed time: 0.250710s (0.052309s in 2 GCs)
"Elapsed time: 0.250710s (0.052309s in 2 GCs)"
Elapsed time: 0.241979s (0.051069s in 2 GCs)
"Elapsed time: 0.241979s (0.051069s in 2 GCs)"
Mark set 

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > Mark set
 > Elapsed time: 0.235007s (0.050980s in 2 GCs)
 > "Elapsed time: 0.235007s (0.050980s in 2 GCs)"
 > Elapsed time: 0.209364s (0.025391s in 1 GCs)
 > "Elapsed time: 0.209364s (0.025391s in 1 GCs)"
 > Mark activated
 > Elapsed time: 0.250710s (0.052309s in 2 GCs)
 > "Elapsed time: 0.250710s (0.052309s in 2 GCs)"
 > Elapsed time: 0.241979s (0.051069s in 2 GCs)
 > "Elapsed time: 0.241979s (0.051069s in 2 GCs)"
 > Mark set

Sorry, what are these numbers?  Do they represent GTK builds with the
same options as the Lucid build that takes 0.684959s?  Did you test all
with emacs -Q in the same buffer and at the same position?

martin

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

At 2020-01-23 01:33:25, "martin rudalics" <rudalics@gmx.at> wrote:
> > Mark set
> > Elapsed time: 0.235007s (0.050980s in 2 GCs)
> > "Elapsed time: 0.235007s (0.050980s in 2 GCs)"
> > Elapsed time: 0.209364s (0.025391s in 1 GCs)
> > "Elapsed time: 0.209364s (0.025391s in 1 GCs)"
> > Mark activated
> > Elapsed time: 0.250710s (0.052309s in 2 GCs)
> > "Elapsed time: 0.250710s (0.052309s in 2 GCs)"
> > Elapsed time: 0.241979s (0.051069s in 2 GCs)
> > "Elapsed time: 0.241979s (0.051069s in 2 GCs)"
> > Mark set
>
>Sorry, what are these numbers?  Do they represent GTK builds with the
>same options as the Lucid build that takes 0.684959s?  Did you test all
>with emacs -Q in the same buffer and at the same position?
>

Sorry, finally I find it is set-frame-position's reason, it too slow,  not posn-at-point

When I test, I replace posn-at-point to a fix value, and  posframe has cached this value,
not call set-frame-positon, so speed is fast,






>martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Eli Zaretskii]

> Date: Wed, 22 Jan 2020 16:04:21 +0800 (CST)
> From: tumashu <tumashu@163.com>
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Today I test lucid emacs again,  maybe the slowness is  posn-at-point
> 
> (benchmark 1000 '(posn-at-point (point)))
> 
> "Elapsed time: 0.684959s"

That's 0.7 msec per call.  Is that really an issue?

In any case, the performance of posn-at-point depends heavily on
what's in the buffer, and even on how close point is to the beginning
of the window.  So testing the speed in a single window with a single
position of point is not really representative of what can happen
elsewhere.

Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

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

Hello:


When I use child-frame with gnome-shell, I find that set-frame-size is very slow and can not resize at all.
Is it emacs's problem or gnome problem?


```
(defun open-test (buffer)
  (display-buffer-in-child-frame
   buffer '((child-frame-parameters
             . ((width . 40)
                (height . 10)
                (top . 50)
                (left . 50)
                )))))

(defun resize-test (frame)
  (set-frame-height frame 20))

(setq-local test-buffer (get-buffer-create "test child-frame"))
(setq-local test-frame (window-frame (open-test test-buffer)))

(resize-test test-frame)
```
The below links are relate infos of this problem:

1. https://gitlab.gnome.org/GNOME/gnome-shell/issues/1733

2. https://github.com/tumashu/company-posframe/issues/17

3. https://github.com/tumashu/company-posframe/issues/2





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

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > When I use child-frame with gnome-shell, I find that set-frame-size is very slow and can not resize at all.
 > Is it emacs's problem or gnome problem?
 >
 >
 > ```
 > (defun open-test (buffer)
 >    (display-buffer-in-child-frame
 >     buffer '((child-frame-parameters
 >               . ((width . 40)
 >                  (height . 10)
 >                  (top . 50)
 >                  (left . 50)
 >                  )))))
 >
 > (defun resize-test (frame)
 >    (set-frame-height frame 20))
 >
 > (setq-local test-buffer (get-buffer-create "test child-frame"))
 > (setq-local test-frame (window-frame (open-test test-buffer)))
 >
 > (resize-test test-frame)
 > ```
 > The below links are relate infos of this problem:
 >
 > 1. https://gitlab.gnome.org/GNOME/gnome-shell/issues/1733
 >
 > 2. https://github.com/tumashu/company-posframe/issues/17
 >
 > 3. https://github.com/tumashu/company-posframe/issues/2

Both, 'display-buffer-in-child-frame' and 'set-frame-height', should
be written in a way that the child frame surely fits into its parent.
If you don't, the window manager might do strange things.

Also, I would disable all decorations that are not strictly needed.
For example, with a GTK build using your parameters I get a tool bar
on the child frame as soon as I type some character into it (which
might be an Emacs bug in one or the other way).  That tool bar is
truncated and GTK may not behave well with truncated tool bars.  See
section 29.14 of the Elisp manual for what better not to do on child
frames.

If neither of these helps, we would have to look into how Gnome-shell
treats child windows.  Gnome-shell seems particular (see Bug#38452).

martin

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

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







--
发自我的网易邮箱手机智能版
<br/><br/><br/>


----- Original Message -----
From: "martin rudalics" <rudalics@gmx.at>
To: tumashu <tumashu@163.com>, "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Sent: Fri, 10 Jan 2020 10:56:39 +0100
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?

 > When I use child-frame with gnome-shell, I find that set-frame-size is very slow and can not resize at all.
 > Is it emacs's problem or gnome problem?
 >
 >
 > ```
 > (defun open-test (buffer)
 >    (display-buffer-in-child-frame
 >     buffer '((child-frame-parameters
 >               . ((width . 40)
 >                  (height . 10)
 >                  (top . 50)
 >                  (left . 50)
 >                  )))))
 >
 > (defun resize-test (frame)
 >    (set-frame-height frame 20))
 >
 > (setq-local test-buffer (get-buffer-create "test child-frame"))
 > (setq-local test-frame (window-frame (open-test test-buffer)))
 >
 > (resize-test test-frame)
 > ```
 > The below links are relate infos of this problem:
 >
 > 1. https://gitlab.gnome.org/GNOME/gnome-shell/issues/1733
 >
 > 2. https://github.com/tumashu/company-posframe/issues/17
 >
 > 3. https://github.com/tumashu/company-posframe/issues/2

Both, 'display-buffer-in-child-frame' and 'set-frame-height', should
be written in a way that the child frame surely fits into its parent.
If you don't, the window manager might do strange things.

Sorry, i do not understand this, more detail or an example？

Also, I would disable all decorations that are not strictly needed.
For example, with a GTK build using your parameters I get a tool bar
on the child frame as soon as I type some character into it (which
might be an Emacs bug in one or the other way).  That tool bar is
truncated and GTK may not behave well with truncated tool bars.  See
section 29.14 of the Elisp manual for what better not to do on child
frames.

i think it is not toolbar's problem，posframe use childframe without toolbar, has resize problem too,



If neither of these helps, we would have to look into how Gnome-shell
treats child windows.  Gnome-shell seems particular (see Bug#38452). 


i think it may be gnome-shell problem, for other wm has no this problem

martin

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

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 >   > (defun open-test (buffer)
 >   >    (display-buffer-in-child-frame
 >   >     buffer '((child-frame-parameters
 >   >               . ((width . 40)
 >   >                  (height . 10)
 >   >                  (top . 50)
 >   >                  (left . 50)
 >   >                  )))))
 >   >
 >   > (defun resize-test (frame)
 >   >    (set-frame-height frame 20))
 >   >
 >   > (setq-local test-buffer (get-buffer-create "test child-frame"))
 >   > (setq-local test-frame (window-frame (open-test test-buffer)))
 >   >
 >   > (resize-test test-frame)
[...]
 > Both, 'display-buffer-in-child-frame' and 'set-frame-height', should
 > be written in a way that the child frame surely fits into its parent.
 > If you don't, the window manager might do strange things.
 >
 > Sorry, i do not understand this, more detail or an example？

I meant that resizing the child frame from 10 to 20 lines with the
given (50, 50) position might make edges of the child frame exceed the
edges of its parent and the window manager might not like that.  In
particular, a program like GNOME-shell that, as we've seen in
Bug#38452, seems to have its own interpretation of coordinates (I have
no idea what GNOME-shell is and does).

 > Also, I would disable all decorations that are not strictly needed.
 > For example, with a GTK build using your parameters I get a tool bar
 > on the child frame as soon as I type some character into it (which
 > might be an Emacs bug in one or the other way).  That tool bar is
 > truncated and GTK may not behave well with truncated tool bars.  See
 > section 29.14 of the Elisp manual for what better not to do on child
 > frames.
 >
 > i think it is not toolbar's problem，posframe use childframe without toolbar, has resize problem too,

Is it resizing only or moving the frame too?

 > i think it may be gnome-shell problem, for other wm has no this problem

Maybe we should contact their developers.  Here, moving and sizing
child frames seems noticeably smoother with my Windows builds than
with my Debian builds.

martin

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

>I meant that resizing the child frame from 10 to 20 lines with the
>given (50, 50) position might make edges of the child frame exceed the
>edges of its parent and the window manager might not like that.  In
>particular, a program like GNOME-shell that, as we've seen in
>Bug#38452, seems to have its own interpretation of coordinates (I have
>no idea what GNOME-shell is and does).

I think resizing problem is not this reason.

>Is it resizing only or moving the frame too?

I think resizing only,  moving works well.

>
> > i think it may be gnome-shell problem, for other wm has no this problem
>
>Maybe we should contact their developers.  Here, moving and sizing
>child frames seems noticeably smoother with my Windows builds than
>with my Debian builds.
>
>martin
>

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 >> This should allow to (1) drag the frame around with mouse-1 down on the
 >> mode line and (2) draw a 10 pixel wide red internal border (color
 >> visible only after a redisplay, maybe) I can use here to resize the
 >> frame with mouse-1 (Emacs resizing natively).  Both work quite snappy
 >> here with an optimized build running under Xfce on an old-stable Debian.
 >
 > Yup, that's working fine on my GNOME desktop. No obvious slowdown, at least.

I'm confused now.  Does (2) really work in the sense that you can resize
the frame by dragging its internal border?

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 16.01.2020 12:18, martin rudalics wrote:
>  >> This should allow to (1) drag the frame around with mouse-1 down on the
>  >> mode line and (2) draw a 10 pixel wide red internal border (color
>  >> visible only after a redisplay, maybe) I can use here to resize the
>  >> frame with mouse-1 (Emacs resizing natively).  Both work quite snappy
>  >> here with an optimized build running under Xfce on an old-stable 
> Debian.
>  >
>  > Yup, that's working fine on my GNOME desktop. No obvious slowdown, at 
> least.
> 
> I'm confused now.  Does (2) really work in the sense that you can resize
> the frame by dragging its internal border?

Ah! No, sorry.

I can drag it around no problem. As for resizing, it doesn't work. The 
cursor shows the appropriate shapes when near the window borders, but 
dragging it by the border can only move it (i.e. dragging the top or 
left border moves the child frame, but does not resize it).

Dragging it by the border is not as snappy as dragging it by the 
mode-line, BTW.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 >> I'm confused now.  Does (2) really work in the sense that you can resize
 >> the frame by dragging its internal border?
 >
 > Ah! No, sorry.
 >
 > I can drag it around no problem. As for resizing, it doesn't work. The cursor shows the appropriate shapes when near the window borders, but dragging it by the border can only move it (i.e. dragging the top or left border moves the child frame, but does not resize it).
 >
 > Dragging it by the border is not as snappy as dragging it by the mode-line, BTW.

Dragging the frame by dragging the border shouldn't have happened in the
first place.  Please try again with:


(custom-set-faces
  '(internal-border ((t (:background "red")))))

(defun open-test (buffer)
   (display-buffer-in-child-frame
    buffer '((child-frame-parameters
              . ((width . 40)
                 (height . 10)
                 (top . 50)
                 (left . 50)
         (minibuffer . nil)
         (border-width . 0)
         (internal-border-width . 10)
         (drag-internal-border . t)
         (drag-with-mode-line . t)
                 )))))

(setq-local test-buffer (get-buffer-create "*test child-frame*"))
(setq-local test-frame (window-frame (open-test test-buffer)))


martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 16.01.2020 12:44, martin rudalics wrote:
> 
> Dragging the frame by dragging the border shouldn't have happened in the
> first place.  Please try again with:
> 
> 
> (custom-set-faces
>   '(internal-border ((t (:background "red")))))
> 
> (defun open-test (buffer)
>    (display-buffer-in-child-frame
>     buffer '((child-frame-parameters
>               . ((width . 40)
>                  (height . 10)
>                  (top . 50)
>                  (left . 50)
>          (minibuffer . nil)
>          (border-width . 0)
>          (internal-border-width . 10)
>          (drag-internal-border . t)
>          (drag-with-mode-line . t)
>                  )))))
> 
> (setq-local test-buffer (get-buffer-create "*test child-frame*"))
> (setq-local test-frame (window-frame (open-test test-buffer)))

The behavior seems to be the same (dragging, not resizing; including 
dragging by the borders).

BTW, somewhat curiously the red border only shows up after I click on 
the child frame.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > The behavior seems to be the same (dragging, not resizing; including dragging by the borders).

Earlier your 'frame-geometry' reported that the child frame has no
borders.  So there should be no dragging by the borders, only resizing
via the internal borders.  Hence this behavior sounds strange.

 > BTW, somewhat curiously the red border only shows up after I click on the child frame.

Happens here as well, sometimes.  It appears right away with an
optimized GTK build, though.

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 16.01.2020 13:22, martin rudalics wrote:
>  > The behavior seems to be the same (dragging, not resizing; including 
> dragging by the borders).
> 
> Earlier your 'frame-geometry' reported that the child frame has no
> borders.  So there should be no dragging by the borders, only resizing
> via the internal borders.  Hence this behavior sounds strange.

My intuitive understanding is that the WM considers this frame 
fixed-size for some reason. And when mouse dragging of the top border is 
initiated, it is indeed resized by moving the top border.

And then some other piece of code somewhere sees that and thinks, hey, 
this window must be X height! And fixes the situation by resizing it 
back (but moving the bottom border). Which makes the frame move.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > My intuitive understanding is that the WM considers this frame
 > fixed-size for some reason. And when mouse dragging of the top border
 > is initiated, it is indeed resized by moving the top border.
 >
 > And then some other piece of code somewhere sees that and thinks, hey,
 > this window must be X height! And fixes the situation by resizing it
 > back (but moving the bottom border). Which makes the frame move.

Tracking that red border is something Emacs internal and is eventually
translated to gtk_window_resize calls just like 'set-frame-size' and
setting the 'height' or 'width' frame parameters.  Hence, all your
earlier attempts to resize the frame would then have resulted in frame
movements as well.

What I'm more concerned about here is that mutter actually _moves_ the
frame although there should not be any decorations that would make such
movement possible and not that dragging the red border does not resize
the frame because I already knew from your earlier observations that
resizing child frames is not supported.

You could try one more thing: Set the frame's 'override-redirect'
parameter to bypass the WM like


(custom-set-faces
  '(internal-border ((t (:background "red")))))

(defun open-test (buffer)
   (display-buffer-in-child-frame
    buffer '((child-frame-parameters
              . ((width . 40)
                 (height . 10)
                 (top . 50)
                 (left . 50)
         (minibuffer . nil)
	(override-redirect . t)
         (border-width . 0)
         (internal-border-width . 10)
         (drag-internal-border . t)
         (drag-with-mode-line . t)
                 )))))

(setq-local test-buffer (get-buffer-create "*test child-frame*"))
(setq-local test-frame (window-frame (open-test test-buffer)))


And also make sure that 'frame-resize-pixelwise' is t although I doubt
that this would make any difference.  I've tried to read the mutter
source code but hardly found anything revealing.  BTW, did you ever try
shrinking the initial frame instead of growing it?

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 17.01.2020 2:53, martin rudalics wrote:
> Then I'm at my wits' end ..

This is really unfortunate, because the users have been asking, 
repeatedly, for a (popup-based) interface for completion, "M-x", and 
other features. And the overlay-based approach has had known problems 
and limitations for years.

As we can see, posframe is kind of working okay for some users:

https://i.redd.it/cwaq7dsrny941.png

But somewhat ironically, it only mostly works on non-free OSes (GNOME is 
the most popular Free DE still).

(Also see 
https://www.reddit.com/r/emacs/comments/ejzwz7/wilmersdorf_theme_v050_also_featured_in/)

Is there anything more I can do to facilitate fixing this? Helping you 
set up a VM, or renting one in the Cloud, for instance.

So far my research says that we're maybe doing something unusual. 
Because there are few hits mentioning any problems with "child windows 
resize" on Goog, but something similar also comes up in relation to X 
Server implementations for MS Windows:

https://superuser.com/questions/300555/problem-with-resizing-subwindows-in-eclipse-xming-combination

https://github.com/sebastiencs/company-box/issues/76#event-2935078315

The latter is a report on somewhat similar problem our users have with 
childframe-based packages (company-box and company-posframe) when using 
VcXsrv or Xming. In this environment, resizing happens, but with heavy 
graphical artefacts. Fixed by switching to "MobaXTerm", apparently.

Alternatively, if we can't make resizing child frames work reliably, 
maybe prohibit it on the API level? And then work on making sure that 
deleting and re-creating a new child frame, and showing a buffer there, 
is fast enough.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > Is there anything more I can do to facilitate fixing this?

We'd first need a somewhat wider audience here.  Are all the colleagues
running into these problems on GNOME or tunneling into it, do they all
use a HiDPI display?  Could one of them try to change the WM for
experimenting so we can at least determine that this is a mutter-only
problem?  Could we find at least one guru able to build mutter so she or
he can debug it - I don't have the faintest idea how to do that.  Maybe
there's also someone still running Metacity who could tell us whether
the same problems exist there already.

Here with Xfce on Debian I'm using a minibuffer child frame that moves
along with the selected window, resizes exactly like the normal
minibuffer window and disappears whenever it's not active.  So child
frames work reliably here.

OTOH, as we've seen with Bug#38452, mutter also seems to have problems
processing calls for normal Emacs frames as requested.  So we really
should try to contact Florian Müllner (fmuellner@gnome.org) - maybe he
could give us at least some hints on how to proceed or what to test.
But this means that at least two or three people using Emacs on GNOME
shell should participate, so this doesn't look like some sort of stray
issue, occasionally encountered by one or two users as with
https://gitlab.gnome.org/GNOME/mutter/issues/840.

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 18.01.2020 11:32, martin rudalics wrote:
>  > Is there anything more I can do to facilitate fixing this?
> 
> We'd first need a somewhat wider audience here.  Are all the colleagues
> running into these problems on GNOME or tunneling into it, do they all
> use a HiDPI display?

The reports are here:

https://github.com/tumashu/company-posframe/issues/2

Mutter is singled out as a cause, HiDPI or not.

> Could one of them try to change the WM for
> experimenting so we can at least determine that this is a mutter-only
> problem? Maybe
> there's also someone still running Metacity who could tell us whether
> the same problems exist there already.

Andrey Orst said that he tried it with Mate desktop (using a fork of 
Metacity), and didn't see this problem here.

 > Could we find at least one guru able to build mutter so she or
 > he can debug it - I don't have the faintest idea how to do that.

I've posted that question.

> Here with Xfce on Debian I'm using a minibuffer child frame that moves
> along with the selected window, resizes exactly like the normal
> minibuffer window and disappears whenever it's not active.  So child
> frames work reliably here.

Well... guess I'm happy it works at least for some users.

> OTOH, as we've seen with Bug#38452, mutter also seems to have problems
> processing calls for normal Emacs frames as requested.  So we really
> should try to contact Florian Müllner (fmuellner@gnome.org) - maybe he
> could give us at least some hints on how to proceed or what to test.
> But this means that at least two or three people using Emacs on GNOME
> shell should participate, so this doesn't look like some sort of stray
> issue, occasionally encountered by one or two users as with
> https://gitlab.gnome.org/GNOME/mutter/issues/840.

Should we start commenting on that issue?

Maybe you could start with a more comprehensive explanation there. Using 
terms that Mutter developers would understand more easily (meaning, not 
Lisp code).

Florian seems to be subscribed to that issue, BTW.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > https://github.com/tumashu/company-posframe/issues/2
 >
 > Mutter is singled out as a cause, HiDPI or not.

OK.  Has anyone tried with a non-GTK build so we can exclude GTK
dependencies too?  Has anyone tried with NS (here GNUstep doesn't even
build at the moment)?

 > Andrey Orst said that he tried it with Mate desktop (using a fork of Metacity), and didn't see this problem here.

OK.

One more thing to try.  In x_wm_set_size_hint we don't set size hints
for child windows here (around line 1404 of gtkutil.c):

   if (NILP (Vafter_init_time)
       || !FRAME_GTK_OUTER_WIDGET (f)
       || FRAME_PARENT_FRAME (f))
     return;

I forgot why, maybe it broke something or caused some weird behavior.  I
should have had a reason back then and forgot to comment it.

Replace that with

   if (NILP (Vafter_init_time)
       || !FRAME_GTK_OUTER_WIDGET (f))
/**       || FRAME_PARENT_FRAME (f)) **/
     return;

and rebuild (it builds and runs without problems here).  Make sure to
run with 'frame-resize-pixelwise' t.  To the best of my knowledge we do
set size hints for non-GTK builds ...

 >  > Could we find at least one guru able to build mutter so she or
 >  > he can debug it - I don't have the faintest idea how to do that.
 >
 > I've posted that question.

Thanks.  I have no great hope that anyone will answer.

 > Should we start commenting on that issue?

Politely so, yes.  Always keep in mind that our way of using GTK is a
peculiar one and that child frames are a somewhat underdeveloped issue,
mostly used for modal dialogues, centered on their parent, never
changing size and the like.

 > Maybe you could start with a more comprehensive explanation
 > there. Using terms that Mutter developers would understand more easily
 > (meaning, not Lisp code).

Will do as soon as I know answers to the questions above.

 > Florian seems to be subscribed to that issue, BTW.

That's why I mentioned him.

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 20.01.2020 18:57, martin rudalics wrote:
>  > https://github.com/tumashu/company-posframe/issues/2
>  >
>  > Mutter is singled out as a cause, HiDPI or not.
> 
> OK.  Has anyone tried with a non-GTK build so we can exclude GTK
> dependencies too?  Has anyone tried with NS (here GNUstep doesn't even
> build at the moment)?

GNUstep what? I'm hesitant to install the dependencies, whatever they are.

Still, a good question. I did a Lucid toolkit build and, lo and behold, 
the bug went away. Also it's blazing fast:

(benchmark 200 '(resize-test test-frame))
=> 0.007s

> One more thing to try.  In x_wm_set_size_hint we don't set size hints
> for child windows here (around line 1404 of gtkutil.c):
> 
>    if (NILP (Vafter_init_time)
>        || !FRAME_GTK_OUTER_WIDGET (f)
>        || FRAME_PARENT_FRAME (f))
>      return;
> 
> I forgot why, maybe it broke something or caused some weird behavior.  I
> should have had a reason back then and forgot to comment it.
> 
> Replace that with
> 
>    if (NILP (Vafter_init_time)
>        || !FRAME_GTK_OUTER_WIDGET (f))
> /**       || FRAME_PARENT_FRAME (f)) **/
>      return;
> 
> and rebuild (it builds and runs without problems here).  Make sure to
> run with 'frame-resize-pixelwise' t.  To the best of my knowledge we do
> set size hints for non-GTK builds ...

That didn't help, however. With either value of frame-resize-pixelwise.

Did 'make bootstrap', to make doubly sure.

>  > Should we start commenting on that issue?
> 
> Politely so, yes.  Always keep in mind that our way of using GTK is a
> peculiar one and that child frames are a somewhat underdeveloped issue,
> mostly used for modal dialogues, centered on their parent, never
> changing size and the like.

Sure.

It appears that they work okay in other desktop environments, though. It 
might also turn out to be a GTK problem.

FTR, my GTK version is 3.24.8.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > GNUstep what? I'm hesitant to install the dependencies, whatever they are.

Forget it.  It can be useful for checking dependencies when implementing
new features.  One cannot do practical work with it IME.  What I meant
was rather whether anyone see problms like yours on NS-based machines.

 > Still, a good question. I did a Lucid toolkit build and, lo and behold, the bug went away. Also it's blazing fast:
 >
 > (benchmark 200 '(resize-test test-frame))
 > => 0.007s

So is it usable?  In your other mail you seemed to indicate that it's
still flickering.  And can you resize child frames by dragging their
borders with it?

If it _is_ usable, the problem is not with mutter but with GTK (maybe in
connection with mutter) or our interpretation of GTK.  To make very sure
you could also try a Motif build (it had very few dependencies when I
installed it, IIRC).

In either case this is the most important finding we had so far.  I
should have asked you earlier.

 > That didn't help, however. With either value of frame-resize-pixelwise.
 >
 > Did 'make bootstrap', to make doubly sure.

I have to go through our GTK code once more.  Maybe I find a similar
discrepancy.  For example, does anything change when you set
'x-gtk-use-window-move' to nil?

 > It appears that they work okay in other desktop environments, though. It might also turn out to be a GTK problem.
 >
 > FTR, my GTK version is 3.24.8.

Mine is 3.22.11 and I'm always reluctant to upgrade my environment.  For
every problem upgrading fixes, I usually get three new ones.  Does your
GTK still have the

(emacs:2053): Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed

problem?  I see it here when starting emacs -Q from a terminal and use
the mouse to shrink the Emacs GUI frame to something less than the tool
bar width.

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 21.01.2020 11:29, martin rudalics wrote:
>  > GNUstep what? I'm hesitant to install the dependencies, whatever they 
> are.
> 
> Forget it.  It can be useful for checking dependencies when implementing
> new features.  One cannot do practical work with it IME.  What I meant
> was rather whether anyone see problms like yours on NS-based machines.

Like a Mac? Apparently not. But they do complain about flickering:

https://github.com/sebastiencs/company-box/issues/79#issuecomment-576507598

>  > Still, a good question. I did a Lucid toolkit build and, lo and 
> behold, the bug went away. Also it's blazing fast:
>  >
>  > (benchmark 200 '(resize-test test-frame))
>  > => 0.007s
> 
> So is it usable?  In your other mail you seemed to indicate that it's
> still flickering.

It's usable, yes. Without visibility cycling, there's little flickering, 
and it doesn't happen in the simple scenario we're discussing now.

 > And can you resize child frames by dragging their
 > borders with it?

Yes, that works both with Lucid and Motif. BTW, dragging bottom and 
right borders is fast and smooth, but dragging top-left is very choppy.

> If it _is_ usable, the problem is not with mutter but with GTK (maybe in
> connection with mutter) or our interpretation of GTK.  To make very sure
> you could also try a Motif build (it had very few dependencies when I
> installed it, IIRC).

Apparently so. Again, Motif works about as well as Lucid.

Unfortunately, I'm getting reports that the Lucid build is much slower 
than GTK at least for some others: 
https://github.com/tumashu/company-posframe/issues/2#issuecomment-576582371

> In either case this is the most important finding we had so far.  I
> should have asked you earlier.

I should have tried it myself as well.

>  > That didn't help, however. With either value of frame-resize-pixelwise.
>  >
>  > Did 'make bootstrap', to make doubly sure.
> 
> I have to go through our GTK code once more.  Maybe I find a similar
> discrepancy.  For example, does anything change when you set
> 'x-gtk-use-window-move' to nil?

No change.

>  > It appears that they work okay in other desktop environments, though. 
> It might also turn out to be a GTK problem.
>  >
>  > FTR, my GTK version is 3.24.8.
> 
> Mine is 3.22.11 and I'm always reluctant to upgrade my environment.  For
> every problem upgrading fixes, I usually get three new ones.

If only we didn't have to support newer versions for other users. :-)

> Does your
> GTK still have the
> 
> (emacs:2053): Gtk-CRITICAL **: gtk_distribute_natural_allocation: 
> assertion 'extra_space >= 0' failed
> 
> problem?  I see it here when starting emacs -Q from a terminal and use
> the mouse to shrink the Emacs GUI frame to something less than the tool
> bar width.

Yup. I see it.

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > Yes, that works both with Lucid and Motif. BTW, dragging bottom and right borders is fast and smooth, but dragging top-left is very choppy.

Because the frame has to resize _and_ move.  GTK has an internal
function that moves and resizes a window in one go but I haven't seen an
external interface to it.

 > Unfortunately, I'm getting reports that the Lucid build is much slower
 > than GTK at least for some others:

I can't comment on that.  I only have non-optimized Lucid builds here
and they are much too slow to do anything with child frames at all.

Next thing to try: Before the

   gtk_window_get_size (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
		       &gwidth, &gheight);

lines in xg_frame_set_char_size insert the two lines

   if (!gtk_window_get_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f))))
     gtk_window_set_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), TRUE);

put a breakpoint on the second one and tell me whether you get a hit.
Just to make sure ...

martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 21.01.2020 19:12, martin rudalics wrote:
>  > Yes, that works both with Lucid and Motif. BTW, dragging bottom and 
> right borders is fast and smooth, but dragging top-left is very choppy.
> 
> Because the frame has to resize _and_ move.  GTK has an internal
> function that moves and resizes a window in one go but I haven't seen an
> external interface to it.

But I can drag it smoothly (by the mode-line), and I can resize it 
smoothly. It kind of weird that drag+resize is more than 2x as slow.

Anyway, that's not the current issue.

>  > Unfortunately, I'm getting reports that the Lucid build is much slower
>  > than GTK at least for some others:
> 
> I can't comment on that.  I only have non-optimized Lucid builds here
> and they are much too slow to do anything with child frames at all.

Does building with '-Og' help? It's really fast here, faster than GTK by 
an order of magnitude (or two).

> Next thing to try: Before the
> 
>    gtk_window_get_size (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
>                 &gwidth, &gheight);
> 
> lines in xg_frame_set_char_size insert the two lines
> 
>    if (!gtk_window_get_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f))))
>      gtk_window_set_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), 
> TRUE);
> 
> put a breakpoint on the second one and tell me whether you get a hit.
> Just to make sure ...

Still no luck (hits line 960, but not 961).

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

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

 >> Because the frame has to resize _and_ move.  GTK has an internal
 >> function that moves and resizes a window in one go but I haven't seen an
 >> external interface to it.
 >
 > But I can drag it smoothly (by the mode-line), and I can resize it smoothly. It kind of weird that drag+resize is more than 2x as slow.

It's not only weird.  IIUC it's also wrong sometimes.  I guess parts of
Emacs' readjust-positions code get into the way here.

 > Does building with '-Og' help? It's really fast here, faster than GTK by an order of magnitude (or two).

I haven't tried it.  What I need is an executable I can debug reliably.

 >> Next thing to try: Before the
 >>
 >>    gtk_window_get_size (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
 >>                 &gwidth, &gheight);
 >>
 >> lines in xg_frame_set_char_size insert the two lines
 >>
 >>    if (!gtk_window_get_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f))))
 >>      gtk_window_set_resizable (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)), TRUE);
 >>
 >> put a breakpoint on the second one and tell me whether you get a hit.
 >> Just to make sure ...
 >
 > Still no luck (hits line 960, but not 961).

So at least no-one interferes with this.

Next thing to try is to always run XResizeWindow and XMoveWindow for GTK
child windows.  This should avoid any GTK related checks for them.  The
attached patch has three hunks.  Try them all first and maybe try to
only apply the last one (or the last two) afterwards.  Here it breaks my
"moving the left or top border of GTK child frames" behavior.

martin

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xterm.diff --]
[-- Type: text/x-patch; name="xterm.diff", Size: 1767 bytes --]

diff --git a/src/xterm.c b/src/xterm.c
index 21d99f0c7b..02055f133f 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10604,9 +10604,13 @@ x_set_offset (struct frame *f, register int xoff, register int yoff, int change_
     }

 #ifdef USE_GTK
-  /* Make sure we adjust for possible scaling.  */
-  gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
-		   modified_left / scale, modified_top / scale);
+  if (FRAME_PARENT_FRAME (f))
+    XMoveWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
+		 modified_left, modified_top);
+  else
+    /* Make sure we adjust for possible scaling.  */
+    gtk_window_move (GTK_WINDOW (FRAME_GTK_OUTER_WIDGET (f)),
+		     modified_left / scale, modified_top / scale);
 #else
   XMoveWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 	       modified_left, modified_top);
@@ -11355,9 +11359,14 @@ x_set_window_size_1 (struct frame *f, bool change_gravity,
   int old_height = FRAME_PIXEL_HEIGHT (f);
   Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);

-  if (change_gravity)
-    f->win_gravity = NorthWestGravity;
-  x_wm_set_size_hint (f, 0, false);
+
+  if (!FRAME_PARENT_FRAME (f))
+    {
+      if (change_gravity)
+	f->win_gravity = NorthWestGravity;
+
+      x_wm_set_size_hint (f, 0, false);
+    }

   /* When the frame is fullheight and we only want to change the width
      or it is fullwidth and we only want to change the height we should
@@ -11489,7 +11498,7 @@ x_set_window_size (struct frame *f, bool change_gravity,
     }

 #ifdef USE_GTK
-  if (FRAME_GTK_WIDGET (f))
+  if (FRAME_GTK_WIDGET (f) && !FRAME_PARENT_FRAME (f))
     xg_frame_set_char_size (f, width, height);
   else
     x_set_window_size_1 (f, change_gravity, width, height);

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 22.01.2020 12:08, martin rudalics wrote:

>  > Does building with '-Og' help? It's really fast here, faster than GTK 
> by an order of magnitude (or two).
> 
> I haven't tried it.  What I need is an executable I can debug reliably.

All I'm saying, the users are not really helpful so far, so you might be 
the best person to try debugging the perf problems with Lucid. I'd try, 
but I don't have any.

> Next thing to try is to always run XResizeWindow and XMoveWindow for GTK
> child windows.  This should avoid any GTK related checks for them.  The
> attached patch has three hunks.  Try them all first and maybe try to
> only apply the last one (or the last two) afterwards.  Here it breaks my
> "moving the left or top border of GTK child frames" behavior.

Aaand none of this helped either. Not all 3 hunks together, nor 
combinations (2, 3), (3) or (1).

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

At 2020-01-22 19:35:40, "Dmitry Gutov" <dgutov@yandex.ru> wrote:
>On 22.01.2020 12:08, martin rudalics wrote:
>
>>  > Does building with '-Og' help? It's really fast here, faster than GTK 
>> by an order of magnitude (or two).
>> 
>> I haven't tried it.  What I need is an executable I can debug reliably.
>
>All I'm saying, the users are not really helpful so far, so you might be 
>the best person to try debugging the perf problems with Lucid. I'd try, 
>but I don't have any.
>

I think it is set-frame-position's reason,   posframe have positon cache, so if posframe's position no
change, it will fast, if position changed, it will show half second lags

(require 'posframe)

(posframe-show "test" :string "aaaaaaaa"
               :background-color "red")

```
(setq child-frame
      (with-current-buffer "test"
        posframe--frame))

(setq p nil)

(defun test ()
  (setq p (if (equal p '(10 10))
              '(100 100)
            '(10 10)))
  (set-frame-position child-frame (car p) (cadr p)))

(benchmark 5 '(test))
```

"Elapsed time: 1.063156s"




>> Next thing to try is to always run XResizeWindow and XMoveWindow for GTK
>> child windows.  This should avoid any GTK related checks for them.  The
>> attached patch has three hunks.  Try them all first and maybe try to
>> only apply the last one (or the last two) afterwards.  Here it breaks my
>> "moving the left or top border of GTK child frames" behavior.
>
>Aaand none of this helped either. Not all 3 hunks together, nor 
>combinations (2, 3), (3) or (1).

Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

 > All I'm saying, the users are not really helpful so far, so you might
 > be the best person to try debugging the perf problems with Lucid. I'd
 > try, but I don't have any.

That was a misunderstanding.  All my debug builds here are too slow for
normal editing.  I keep them all for testing purposes only.  Optimized
builds have certain performance problems but these are not related to
the use of child frames.

 > Aaand none of this helped either. Not all 3 hunks together, nor
 > combinations (2, 3), (3) or (1).

(1) was a NOOP anyway.  I have to think of something better - the
height specifications for GTK and other X builds are not compatible and
break the behavior even on my build.  I should come up with something
better.

Till then please do the following.  With emacs -Q put this modified
version of tumashu's code into *scratch*


(defun open-test (buffer)
   (display-buffer-in-child-frame
    buffer '((child-frame-parameters
              . ((width . 40)
                 (height . 10)
                 (top . 50)
                 (left . 50)
                 )))))

(defun resize-test (frame)
   (set-frame-height frame 20))

(setq-local test-buffer (get-buffer-create "test child-frame"))
(setq-local test-frame (window-frame (open-test test-buffer)))

;; (eval-buffer)
;; (setq frame-size-history '(100))
;; (resize-test test-frame)
;; (frame--size-history test-frame)
;; (display-buffer "*frame-size-history*")


and evaluate from top to bottom each of the commented out forms.  At the
end this gets me a buffer like

Frame size history of #<frame test child-frame 0x5636a0abf9a0>
adjust-frame-size-1	 (360 180 360 360) (height 1)
adjust-frame-size-2	 (360 180 360 360) (nil nil)
xg-frame-set-char-size-3 (360 180 360 360) (390 360)
xg-frame-resized	 (360 180 360 360) nil
adjust-frame-size-1	 (360 180 360 360) (change-frame-size 5)
adjust-frame-size-3	 (360 180 360 360) (390 180 390 360)

Please do this for the GTK and Lucid build.  And, replace the body of
'resize-test' with your invisible, resize, visible trick and post the
history for that case as well.

Thanks, martin

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

----------------------------------------------------------------
# in xfce4, gtk emacs
----------------------------------------------------------------
Frame size history of #<frame test child-frame 0x555960081020>
adjust-frame-size-1      (440 240 440 480) (height 1)
adjust-frame-size-2      (440 240 440 480) (nil nil)
xg-frame-set-char-size-3 (440 240 440 480) (456 480)
xg-frame-resized         (440 240 440 480) nil
adjust-frame-size-1      (440 240 440 480) (change-frame-size 5)
adjust-frame-size-3      (440 240 440 480) (456 240 456 480)
adjust-frame-size-1      (440 480 440 480) (height 1)

-----------------------------------------------------------------
# in gnome shell, gtk emacs
------------------------------------------------------------------
Frame size history of #<frame test child-frame 0x56253dbbf000>
adjust-frame-size-1      (440 240 440 480) (height 1)
adjust-frame-size-2      (440 240 440 480) (nil nil)
xg-frame-set-char-size-3 (440 240 440 480) (456 480)
















At 2020-01-23 01:35:50, "martin rudalics" <rudalics@gmx.at> wrote:
> > All I'm saying, the users are not really helpful so far, so you might
> > be the best person to try debugging the perf problems with Lucid. I'd
> > try, but I don't have any.
>
>That was a misunderstanding.  All my debug builds here are too slow for
>normal editing.  I keep them all for testing purposes only.  Optimized
>builds have certain performance problems but these are not related to
>the use of child frames.
>
> > Aaand none of this helped either. Not all 3 hunks together, nor
> > combinations (2, 3), (3) or (1).
>
>(1) was a NOOP anyway.  I have to think of something better - the
>height specifications for GTK and other X builds are not compatible and
>break the behavior even on my build.  I should come up with something
>better.
>
>Till then please do the following.  With emacs -Q put this modified
>version of tumashu's code into *scratch*
>
>
>(defun open-test (buffer)
>   (display-buffer-in-child-frame
>    buffer '((child-frame-parameters
>              . ((width . 40)
>                 (height . 10)
>                 (top . 50)
>                 (left . 50)
>                 )))))
>
>(defun resize-test (frame)
>   (set-frame-height frame 20))
>
>(setq-local test-buffer (get-buffer-create "test child-frame"))
>(setq-local test-frame (window-frame (open-test test-buffer)))
>
>;; (eval-buffer)
>;; (setq frame-size-history '(100))
>;; (resize-test test-frame)
>;; (frame--size-history test-frame)
>;; (display-buffer "*frame-size-history*")
>
>
>and evaluate from top to bottom each of the commented out forms.  At the
>end this gets me a buffer like
>
>Frame size history of #<frame test child-frame 0x5636a0abf9a0>
>adjust-frame-size-1	 (360 180 360 360) (height 1)
>adjust-frame-size-2	 (360 180 360 360) (nil nil)
>xg-frame-set-char-size-3 (360 180 360 360) (390 360)
>xg-frame-resized	 (360 180 360 360) nil
>adjust-frame-size-1	 (360 180 360 360) (change-frame-size 5)
>adjust-frame-size-3	 (360 180 360 360) (390 180 390 360)
>
>Please do this for the GTK and Lucid build.  And, replace the body of
>'resize-test' with your invisible, resize, visible trick and post the
>history for that case as well.
>
>Thanks, martin

Re: Emacs's set-frame-size can not work well with gnome-shell?

[Dmitry Gutov]

On 22.01.2020 20:35, martin rudalics wrote:

> Till then please do the following.  With emacs -Q put this modified
> version of tumashu's code into *scratch*
> 
> <...>
> Please do this for the GTK and Lucid build.  And, replace the body of
> 'resize-test' with your invisible, resize, visible trick and post the
> history for that case as well.

Here you go.

GNOME Shell, Lucid Emacs:

Frame size history of #<frame test child-frame 0x55c2abb444a0>
adjust-frame-size-1	 (720 360 720 720) (height 1)
adjust-frame-size-2	 (720 360 720 720) (nil nil)
x-set-window-size-3	 (720 360 720 720) (754 722 0)
x-net-wm-state		 nil (nil nil)
EmacsFrameResize	 (720 360 720 720) (754 722 0 0 2)
EmacsFrameResize	 (720 360 720 720) (754 722 0 0 2)
adjust-frame-size-1	 (720 360 720 720) (change-frame-size 5)
adjust-frame-size-3	 (720 360 720 720) (754 362 754 722)
EmacsFrameResize	 (720 720 720 720) (754 722 0 0 2)
EmacsFrameResize	 (720 720 720 720) (754 722 0 0 2)
adjust-frame-size-1	 (720 720 720 720) (change-frame-size 5)

GNOME Shell, GTK Emacs:

Frame size history of #<frame test child-frame 0x5580c2116ea0>
adjust-frame-size-1	 (720 360 720 720) (height 1)
adjust-frame-size-2	 (720 360 720 720) (nil nil)
xg-frame-set-char-size-3 (720 360 720 720) (384 360)

GNOME Shell, GTK Emacs with modified resize-test:

Frame size history of #<frame test child-frame 0x5649dd2e5640>
adjust-frame-size-1	 (720 360 720 720) (height 1)
adjust-frame-size-2	 (720 360 720 720) (nil nil)
xg-frame-set-char-size-3 (720 360 720 720) (384 360)
adjust-frame-size-1	 (720 360 720 720) (xg-frame-set-char-size 5)
adjust-frame-size-3	 (720 360 720 720) (768 360 768 720)
xg-frame-resized	 (720 720 720 720) nil

Re:Re: Emacs's set-frame-size can not work well with gnome-shell?

[tumashu]

At 2020-01-23 08:21:13, "Dmitry Gutov" <dgutov@yandex.ru> wrote:
>On 22.01.2020 20:35, martin rudalics wrote:
>
>> Till then please do the following.  With emacs -Q put this modified
>> version of tumashu's code into *scratch*
>> 
>> <...>
>> Please do this for the GTK and Lucid build.  And, replace the body of
>> 'resize-test' with your invisible, resize, visible trick and post the
>> history for that case as well.
>
>Here you go.
>
>GNOME Shell, Lucid Emacs:
>
>Frame size history of #<frame test child-frame 0x55c2abb444a0>
>adjust-frame-size-1	 (720 360 720 720) (height 1)
>adjust-frame-size-2	 (720 360 720 720) (nil nil)
>x-set-window-size-3	 (720 360 720 720) (754 722 0)
>x-net-wm-state		 nil (nil nil)
>EmacsFrameResize	 (720 360 720 720) (754 722 0 0 2)
>EmacsFrameResize	 (720 360 720 720) (754 722 0 0 2)
>adjust-frame-size-1	 (720 360 720 720) (change-frame-size 5)
>adjust-frame-size-3	 (720 360 720 720) (754 362 754 722)
>EmacsFrameResize	 (720 720 720 720) (754 722 0 0 2)
>EmacsFrameResize	 (720 720 720 720) (754 722 0 0 2)
>adjust-frame-size-1	 (720 720 720 720) (change-frame-size 5)

I have tested with lucid emacs , the result is below

Frame size history of #<frame test child-frame 0x5566cb63e550>
adjust-frame-size-1	 (320 230 320 460) (height 1)
adjust-frame-size-2	 (320 230 320 460) (nil nil)
x-set-window-size-3	 (320 230 320 460) (354 462 0)
x-net-wm-state		 nil (nil nil)
EmacsFrameResize	 (320 230 320 460) (354 462 0 0 2)
EmacsFrameResize	 (320 230 320 460) (354 462 0 0 2)
adjust-frame-size-1	 (320 230 320 460) (change-frame-size 5)
adjust-frame-size-3	 (320 230 320 460) (354 232 354 462)
EmacsFrameResize	 (320 460 320 460) (354 462 0 0 2)
EmacsFrameResize	 (320 460 320 460) (354 462 0 0 2)
adjust-frame-size-1	 (320 460 320 460) (change-frame-size 5)




>
>GNOME Shell, GTK Emacs:
>
>Frame size history of #<frame test child-frame 0x5580c2116ea0>
>adjust-frame-size-1	 (720 360 720 720) (height 1)
>adjust-frame-size-2	 (720 360 720 720) (nil nil)
>xg-frame-set-char-size-3 (720 360 720 720) (384 360)
>
>GNOME Shell, GTK Emacs with modified resize-test:
>
>Frame size history of #<frame test child-frame 0x5649dd2e5640>
>adjust-frame-size-1	 (720 360 720 720) (height 1)
>adjust-frame-size-2	 (720 360 720 720) (nil nil)
>xg-frame-set-char-size-3 (720 360 720 720) (384 360)
>adjust-frame-size-1	 (720 360 720 720) (xg-frame-set-char-size 5)
>adjust-frame-size-3	 (720 360 720 720) (768 360 768 720)
>xg-frame-resized	 (720 720 720 720) nil