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

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: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?

[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: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?

[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.

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: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: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