masm11 / emacs

Mirror of GNU Emacs
http://www.gnu.org/software/emacs/
GNU General Public License v3.0
198 stars 14 forks source link

Minibuffer feels frozen when using straight.el's `straight-rebuild-all` #99

Closed declantsien closed 2 years ago

declantsien commented 3 years ago

See screencast https://streamable.com/f7ttx8

In the screen cast, left is Emacs 27.2 running on xwayland and right is PGTK Emacs running on wayland. Both has a lot messages been output to minibuffer. The left behaves fluent while the PGTK feels frozen.

straight.el is an Emacs functional package manager. https://github.com/raxod502/straight.el.

declantsien commented 3 years ago

Just compiled https://github.com/emacs-mirror/emacs/commit/5b97b98daa7f61311c3662beecbeca7037505992 without --with-pgtk, minibuffer behaviors the same as 27.2. Pretty sure it's a pgtk issue.

masm11 commented 3 years ago

Write to cairo_surface_t some times, and copy the result to window. It is gtk-way.

In this issue: at "Write to cairo_surface_t some times", all the message buffer changes go to cairo_surface_t, and after that at "copy the result to window", the cairo_surface_t goes to the window. Because straight.el is very busy while rebuilding.

I'll look for a workaround.

fejfighter commented 3 years ago

I had been stepping through the redisplay code in the little time I get to work on emacs now, I noticed that I missed the change in 9ae94ebdfa80cf3983c254696b5ab998f7296aec where the gui_update_window_begin|end functions were added and the platform specific ones were removed. This meant we executed that code twice as it the pgtk specific work was identical.

It seems to have made some difference as straight-rebuild-all now appears to update the minibuffer.

@masm11, the attached patch should apply to the feature/pgtk branch on savannah.

0001-src-pgtkterm.c-remove-duplicated-code.patch.txt

declantsien commented 3 years ago

Just tested the patch. It's still the same though.

Also forget to mention that C-g is not working when executing straight-rebuild-all while it immediately stops when using 27.2

fejfighter commented 3 years ago

@declanqian my machine locked you and I thought this comment did not actually get posted.

I had a dirty build environment and wasn't actually building emacs as expected.

The patch is still a good idea. But does not address this particular problem.

masm11 commented 3 years ago

@fejfighter Thanks. Committed and pushed.

fejfighter commented 3 years ago

This is a weird bug.

If I put (straight-rebuild-all) in the scratch buffer and call C-j or C-x C-e it will update the minibuffer. but if I call the same function through M-x it will not update

Seemingly it's an issue with high load interactive function calls

and I confirmed that I had a clean, correctly compiled 'pgtk-emacs

masm11 commented 3 years ago
(let ((i 0))
  (while (< i 100000)
    (message "i %i" i)
    (setq i (1+ i))
    (sit-for 1)))

This code counts up, but it stops counting up after pressing any key. That may be related.

masm11 commented 3 years ago

If I define:

(global-set-key "\C-w" 'straight-rebuild-all)

and use it, start_hourglass is called. While straight-rebuild-all is executing, atimer event is called periodically. When that, drawing is processed.

If I execute it with M-x straight-rebuild-all, start_hourglass is called but cancel_hourglass is also called. So atimer event is not called.

fejfighter commented 3 years ago

test2.log

Using a smaller, modified version of the counting snippet above I get a minimal log as attached, at some pint (around 3) i hit a key and the PGTK_TRACE log is much shorter for each message call

masm11 commented 3 years ago

I tried to fix in 8a649cb. It fixed this issue but generated frame-positioning issue, so I reverted it.

masm11 commented 2 years ago

@declanqian Could you build emacs-mirror@master and confirm whether the issue reproduces yet?

declantsien commented 2 years ago

Nice, the issue does not reproduce any more. Can you kindly point out the commit which fixed this issue? @masm11 Also, I think this issue can be closed now.

masm11 commented 2 years ago

@declanqian Thanks for the confirmation.

Can you kindly point out the commit which fixed this issue?

I'm not sure, but maybe b3277883f35c5ac9980b4ef05dc99fa8b5ce6792 by Po Lu.

declantsien commented 2 years ago

I'm not sure, but maybe b327788 by Po Lu.

Thanks for adding this link.