* Re: Emacs's set-frame-size can not work well with gnome-shell?
@ 2020-01-22 8:04 tumashu
2020-01-22 9:09 ` martin rudalics
2020-01-22 15:55 ` Eli Zaretskii
0 siblings, 2 replies; 12+ messages in thread
From: tumashu @ 2020-01-22 8:04 UTC (permalink / raw)
To: Dmitry Gutov, martin rudalics, tumashu; +Cc: emacs-devel@gnu.org
> > 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 8:04 Emacs's set-frame-size can not work well with gnome-shell? tumashu @ 2020-01-22 9:09 ` martin rudalics 2020-01-22 10:01 ` tumashu 2020-01-22 10:03 ` tumashu 2020-01-22 15:55 ` Eli Zaretskii 1 sibling, 2 replies; 12+ messages in thread From: martin rudalics @ 2020-01-22 9:09 UTC (permalink / raw) To: tumashu, Dmitry Gutov; +Cc: 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" > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 9:09 ` martin rudalics @ 2020-01-22 10:01 ` tumashu 2020-01-22 10:03 ` tumashu 1 sibling, 0 replies; 12+ messages in thread From: tumashu @ 2020-01-22 10:01 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel@gnu.org, Dmitry Gutov 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)" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 9:09 ` martin rudalics 2020-01-22 10:01 ` tumashu @ 2020-01-22 10:03 ` tumashu 2020-01-22 17:33 ` martin rudalics 1 sibling, 1 reply; 12+ messages in thread From: tumashu @ 2020-01-22 10:03 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel@gnu.org, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 10:03 ` tumashu @ 2020-01-22 17:33 ` martin rudalics 2020-01-22 22:30 ` tumashu 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-22 17:33 UTC (permalink / raw) To: tumashu; +Cc: Dmitry Gutov, emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 17:33 ` martin rudalics @ 2020-01-22 22:30 ` tumashu 0 siblings, 0 replies; 12+ messages in thread From: tumashu @ 2020-01-22 22:30 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel@gnu.org, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 8:04 Emacs's set-frame-size can not work well with gnome-shell? tumashu 2020-01-22 9:09 ` martin rudalics @ 2020-01-22 15:55 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2020-01-22 15:55 UTC (permalink / raw) To: tumashu; +Cc: rudalics, emacs-devel, tumashu, dgutov > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Emacs's set-frame-size can not work well with gnome-shell? @ 2020-01-10 2:34 tumashu 2020-01-10 9:56 ` martin rudalics 2020-01-16 9:18 ` martin rudalics 0 siblings, 2 replies; 12+ messages in thread From: tumashu @ 2020-01-10 2:34 UTC (permalink / raw) To: emacs-devel@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-10 2:34 tumashu @ 2020-01-10 9:56 ` martin rudalics 2020-01-11 1:29 ` tumashu 2020-01-16 9:18 ` martin rudalics 1 sibling, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-10 9:56 UTC (permalink / raw) To: tumashu, emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-10 9:56 ` martin rudalics @ 2020-01-11 1:29 ` tumashu 2020-01-11 7:50 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: tumashu @ 2020-01-11 1:29 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel@gnu.org [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-11 1:29 ` tumashu @ 2020-01-11 7:50 ` martin rudalics 2020-01-11 10:36 ` tumashu 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-11 7:50 UTC (permalink / raw) To: tumashu; +Cc: emacs-devel@gnu.org > > (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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-11 7:50 ` martin rudalics @ 2020-01-11 10:36 ` tumashu 0 siblings, 0 replies; 12+ messages in thread From: tumashu @ 2020-01-11 10:36 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel@gnu.org >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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? @ 2020-01-16 9:18 ` martin rudalics 2020-01-16 9:27 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-16 9:18 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org >> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-16 9:18 ` martin rudalics @ 2020-01-16 9:27 ` Dmitry Gutov 2020-01-16 9:44 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-16 9:27 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-16 9:27 ` Dmitry Gutov @ 2020-01-16 9:44 ` martin rudalics 2020-01-16 10:12 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-16 9:44 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org >> 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-16 9:44 ` martin rudalics @ 2020-01-16 10:12 ` Dmitry Gutov 2020-01-16 10:22 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-16 10:12 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-16 10:12 ` Dmitry Gutov @ 2020-01-16 10:22 ` martin rudalics 2020-01-16 15:03 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-16 10:22 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-16 10:22 ` martin rudalics @ 2020-01-16 15:03 ` Dmitry Gutov 2020-01-16 18:33 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-16 15:03 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-16 15:03 ` Dmitry Gutov @ 2020-01-16 18:33 ` martin rudalics [not found] ` <15405719-d58d-44db-f1df-ad3bb272b2fc@yandex.ru> 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-16 18:33 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <15405719-d58d-44db-f1df-ad3bb272b2fc@yandex.ru>]
[parent not found: <aba0683f-466c-76cf-9024-e18bfc9fdc94@gmx.at>]
* Re: Emacs's set-frame-size can not work well with gnome-shell? [not found] ` <aba0683f-466c-76cf-9024-e18bfc9fdc94@gmx.at> @ 2020-01-18 2:05 ` Dmitry Gutov 2020-01-18 8:32 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-18 2:05 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-18 2:05 ` Dmitry Gutov @ 2020-01-18 8:32 ` martin rudalics 2020-01-20 13:37 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-18 8:32 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-18 8:32 ` martin rudalics @ 2020-01-20 13:37 ` Dmitry Gutov 2020-01-20 15:57 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-20 13:37 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-20 13:37 ` Dmitry Gutov @ 2020-01-20 15:57 ` martin rudalics 2020-01-20 23:02 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-20 15:57 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-20 15:57 ` martin rudalics @ 2020-01-20 23:02 ` Dmitry Gutov 2020-01-21 8:29 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-20 23:02 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-20 23:02 ` Dmitry Gutov @ 2020-01-21 8:29 ` martin rudalics 2020-01-21 12:11 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-21 8:29 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-21 8:29 ` martin rudalics @ 2020-01-21 12:11 ` Dmitry Gutov 2020-01-21 16:12 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-21 12:11 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-21 12:11 ` Dmitry Gutov @ 2020-01-21 16:12 ` martin rudalics 2020-01-21 22:26 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-21 16:12 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-21 16:12 ` martin rudalics @ 2020-01-21 22:26 ` Dmitry Gutov 2020-01-22 9:08 ` martin rudalics 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-21 22:26 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-21 22:26 ` Dmitry Gutov @ 2020-01-22 9:08 ` martin rudalics 2020-01-22 11:35 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: martin rudalics @ 2020-01-22 9:08 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org [-- 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); ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 9:08 ` martin rudalics @ 2020-01-22 11:35 ` Dmitry Gutov 2020-01-22 13:18 ` tumashu 2020-01-22 17:35 ` martin rudalics 0 siblings, 2 replies; 12+ messages in thread From: Dmitry Gutov @ 2020-01-22 11:35 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 11:35 ` Dmitry Gutov @ 2020-01-22 13:18 ` tumashu 2020-01-22 17:35 ` martin rudalics 1 sibling, 0 replies; 12+ messages in thread From: tumashu @ 2020-01-22 13:18 UTC (permalink / raw) To: Dmitry Gutov; +Cc: martin rudalics, emacs-devel@gnu.org 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). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 11:35 ` Dmitry Gutov 2020-01-22 13:18 ` tumashu @ 2020-01-22 17:35 ` martin rudalics 2020-01-22 22:40 ` tumashu 2020-01-23 0:21 ` Dmitry Gutov 1 sibling, 2 replies; 12+ messages in thread From: martin rudalics @ 2020-01-22 17:35 UTC (permalink / raw) To: Dmitry Gutov, tumashu; +Cc: emacs-devel@gnu.org > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 17:35 ` martin rudalics @ 2020-01-22 22:40 ` tumashu 2020-01-23 0:21 ` Dmitry Gutov 1 sibling, 0 replies; 12+ messages in thread From: tumashu @ 2020-01-22 22:40 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel@gnu.org, Dmitry Gutov ---------------------------------------------------------------- # 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-22 17:35 ` martin rudalics 2020-01-22 22:40 ` tumashu @ 2020-01-23 0:21 ` Dmitry Gutov 2020-01-23 0:39 ` tumashu 1 sibling, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2020-01-23 0:21 UTC (permalink / raw) To: martin rudalics, tumashu; +Cc: emacs-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re:Re: Emacs's set-frame-size can not work well with gnome-shell? 2020-01-23 0:21 ` Dmitry Gutov @ 2020-01-23 0:39 ` tumashu 0 siblings, 0 replies; 12+ messages in thread From: tumashu @ 2020-01-23 0:39 UTC (permalink / raw) To: Dmitry Gutov; +Cc: martin rudalics, emacs-devel@gnu.org 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-01-23 0:39 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-22 8:04 Emacs's set-frame-size can not work well with gnome-shell? tumashu 2020-01-22 9:09 ` martin rudalics 2020-01-22 10:01 ` tumashu 2020-01-22 10:03 ` tumashu 2020-01-22 17:33 ` martin rudalics 2020-01-22 22:30 ` tumashu 2020-01-22 15:55 ` Eli Zaretskii -- strict thread matches above, loose matches on Subject: below -- 2020-01-10 2:34 tumashu 2020-01-10 9:56 ` martin rudalics 2020-01-11 1:29 ` tumashu 2020-01-11 7:50 ` martin rudalics 2020-01-11 10:36 ` tumashu 2020-01-16 9:18 ` martin rudalics 2020-01-16 9:27 ` Dmitry Gutov 2020-01-16 9:44 ` martin rudalics 2020-01-16 10:12 ` Dmitry Gutov 2020-01-16 10:22 ` martin rudalics 2020-01-16 15:03 ` Dmitry Gutov 2020-01-16 18:33 ` martin rudalics [not found] ` <15405719-d58d-44db-f1df-ad3bb272b2fc@yandex.ru> [not found] ` <aba0683f-466c-76cf-9024-e18bfc9fdc94@gmx.at> 2020-01-18 2:05 ` Dmitry Gutov 2020-01-18 8:32 ` martin rudalics 2020-01-20 13:37 ` Dmitry Gutov 2020-01-20 15:57 ` martin rudalics 2020-01-20 23:02 ` Dmitry Gutov 2020-01-21 8:29 ` martin rudalics 2020-01-21 12:11 ` Dmitry Gutov 2020-01-21 16:12 ` martin rudalics 2020-01-21 22:26 ` Dmitry Gutov 2020-01-22 9:08 ` martin rudalics 2020-01-22 11:35 ` Dmitry Gutov 2020-01-22 13:18 ` tumashu 2020-01-22 17:35 ` martin rudalics 2020-01-22 22:40 ` tumashu 2020-01-23 0:21 ` Dmitry Gutov 2020-01-23 0:39 ` tumashu
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).