[GUI Emacs] Weird: the bigger the frame size is, the slower Emacs becomes (!?)

I am running GUI Emacs on Arch Linux WSL2 (Vcxsrv X-server). I am noticing a **significant** slowdown when I full-screen my GUI Emacs. The slowdown is particularly noticeable in **input latency**. When I type fast, I would have to wait a few seconds for the letters to appear one by one. When I shrink down the size of the GUI frame, Emacs becomes very snappy and responsive. I have noticed a positive correlation between Emacs lag and the size of the frame -- this is the weirdest thing I've come across since I started using Emacs years ago. Running no configuration with \`emacs -q\` is the same thing -- significant latency when the frame is big. Has anyone been faced with this issue? I am so bewildered by this but can't find anything related online. At the moment I'm using terminal Emacs as the frame-size vs. latency issue does not exist in the terminal. \--- **Edit (12/10/2022)**: I have found a workaround from browsing Doom Emacs' issues ([https://github.com/doomemacs/doomemacs/issues/2217](https://github.com/doomemacs/doomemacs/issues/2217)), they suggested several options and the one that worked for me was adding the following line to my init.el: (add-to-list 'default-frame-alist '(inhibit-double-buffering . t)) The input latency immediately improved upon restart. Double buffering was introduced in Emacs 26.1 to reduce screen flickering. I'll experiment with it a few more days and report back if the flickering occurs. ​

I use almost the exact same setup, except that I use ubuntu. I haven't seen any problems. how big are you talking about?

Try a different X server?

[deleted]

edit: The profiler will prob not help you. I can replicate this behavior when I pipe X over ssh to a win xserve. I suspect the bottleneck is there. I often am doing remote work, and for that I use TRAMP with a native emacs. It is tolerable but not great, esp if you use something like magit on large codebases or other tools like helm that cause a lot of tramp traffic). If you are on a windows host and using windows emacs, I'd recommend you use plink in place of ssh for tramp. I often just use the term, as you are already doing. \------- If you're interested in debugging, something like this could be illuminating: [https://ianyepan.github.io/posts/emacs-profiling/](https://ianyepan.github.io/posts/emacs-profiling/)

You lost me at WSL

When the frame size is big (especially full-screen), the input lag is big enough to prevent one from doing meaningful work..

XMing and other alternatives more or less have the same problem, I have been testing different X servers as you suggested. X410 is the snappiest one, and seems to suffer from the full-screen input latency only slightly. Perhaps it's using a different protocol to render the GUI. The only downside is that X410 costs $50. I am pretty sure it is because I am running Emacs on a 4K monitor, so the GUI rendering could be to heavy to handle by Vcxsrv when the frame size is big.

Thanks, after trying out a few X servers (and seeing similar behaviors), I am quite certain that the problem comes from me running Emacs in a 4K monitor, and the X server is just not powerful enough to render it swiftly, especially when the frame size is big. ​ >If you're interested in debugging, something like this could be illuminating: Haha, this is actually "my" blog post!

win11 and win 10 has native x in WSL fyi: [https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps](https://learn.microsoft.com/en-us/windows/wsl/tutorials/gui-apps)

!!!! That's awesome - haha - great write up

Ah yes, I have tried that too. But the default WSL GUI is even worse than other 3rd party X servers...

Thanks, appreciate it!