emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: tumashu
Subject: Re:Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Wed, 22 Jan 2020 21:18:05 +0800 (CST)
















At 2020-01-22 19:35:40, "Dmitry Gutov" <address@hidden> 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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]