Speed of creating the first GTK3 frame

Hello. I would like to ask whether it is possible to speed up the first GTK3 frame creation (not \`init.el\` loading) Background: Emacs 28.1 with GTK3 on ArchLinux (Awesome WM) and Ubuntu 20.04 (Gnome 3.36), both with Xorg. The config is on [GitHub](https://github.com/igorepst/dotfiles-reboot/tree/master/packages/emacs/config/emacs). On both machines the startup time for a non daemon Emacs UI instance is roughly the same and fluctuates between 0.46-0.55 seconds (depending on machine load perhaps, not sure), measured by \`emacs-init-time\`. The same measurement when opening a frame created from daemon (by \`systemd\`, but it shouldn't matter) or in terminal is 0.104 sec. When using \`emacs -Q\` it is 0.319 sec. So, although the startup times are fine, I anyway would like to find a way to lessen the time it takes to draw a GTK3 frame which is roughly 0.3 sec. as far as I understand (this is by simply calculating the difference between non-daemon UI init time and a daemon one). Why? Because I want it faster and because the frame flickers when it is drawn :) So, basically this is not about the speed of \`init\` loading, but UI drawing (although I will gladly accept suggestions to speed up the init as well \[the config is in the works, I choose not to use \`use-package\`, but instead to employ manual tweaks\]). Is it even possible to lessen this time? By the measurement of \`-Q\` it seems not... Thank you in advance

I'm not sure about startup time, but the flicker is probably from the default frame color not blending with your theme. I have the following in my .Xresources file, you'll have to adjust the colors to your theme. I'm not sure if turning of the widgets helps with speed, you can try it. ! turn these off early Emacs*toolBar: off Emacs*verticalScrollBars: off Emacs*menuBar: off ! blend in with theme for less flash at startup ! hc-zenburn theme !Emacs*background: #313131 !Emacs*foreground: #DCDCCC !Emacs.mode-line.attributeForeground: #9cbf9c !Emacs.mode-line.attributeBackground: #202020 !modus-operandi Emacs*foreground: #000000 Emacs*background: #ffffff Emacs.mode-line.attributeForeground: #505050 Emacs.mode-line.attributeBackground: #f0f0f0

Certain options can be set during early-init.el prior to the first frame being created which may increase the speed. e.g. If you're planning on disabling menu, scrollbar, tab-bar, do it there so they're not enabled and disabled during init.el.

Thank you very much. Will definitely check this a bit later today or tomorrow. Although talking about flickering I mostly thought to myself about maximizing the frame loaded with daemon (regular emacs is aliased for me to have `-mm`, so it is started maximized, but for daemon frames there is a redraw I tried to circumvent, but there is a noticable flickering still).

Thank you very much. I am aware of early init file and use it actually. Regarding menu, toolbar and scrollbar I feel I prefer to have them to employ a mouse ( not everyone is perfect;) ), although I will try to disable them to see the speed influence. Are there other options to try for UI speed you know of (I am not talking about GC threshold, etc.)?

> the frame flickers when it is drawn Which flicker? I don't see any flicker; never did. I am also on Arch Linux with X11 > Is it even possible to lessen this time? I don't know for your computer, on my computer, my setup with ~200 packages starts in about the same time as yoursl, 0.4 ~ 0.5 secs. With -Q option, it starts with ~0.25 sec. Of course the speed differs on packages loaded and hardware, so unless we load roughly similar setup and have similarly capable computers, it is not worth of comparing mine setup to yours. I am not exactly sure what you do with your setup, but I don't think you should require package and setup package repos in early init. You don't seem to be checking for packages at startup, so you can do your package setup lazily too after the package is loaded, similar to as you do with dired and other stuff. See if you can load more stuff lazily (do more in mode hooks if possible). Also, do you really need to load xresources to just maximize frame? Can't you just: (push '(fullscreen . maximized) initial-frame-alist) (push '(fullscreen . maximized) default-frame-alist) in your early-init.el? You save on accessing an extra config file for just one variable. I don't think you need to autoload non-interactive functions. Typically, when you press a key and invoke an interactive function (command), entire file and all functions and variables will be loaded. You do that for example in your ig-autoload-edit.el. Also since you have created those small libraries in form of one-file packages, why not just M-x package-install-file, for each of them, and let package-quickstart do all the work for you, so you skip your entire autoload stuff? Not speed hacks, but I also suggest loading more stuff on idle timer if you can. I load org mode, dired, helm and probably more which I don't remember at the moment in idle timer, so I skip small hiccups when using those. They are almost always pre-loaded in my Emacs without adding to init time. I also suggest restoring back original GC values instead of 128 meg. (Why 128 meg - where does the number come from?) Sorry if I misunderstand some finer points with your setup, I have just glanced over it in and am not an expert in these matters, so take my words with a grain of salt.

> I'm not sure if turning of the widgets helps with speed, you can try it. ??? What *widgets*? XWidgets? How should that have impact on speed? > ! turn these off early > Emacs*toolBar: off > Emacs*verticalScrollBars: off > Emacs*menuBar: off We have early-init to turn those off these days: (push '(menu-bar-lines . 0) default-frame-alist) (push '(tool-bar-lines . 0) default-frame-alist) (push '(vertical-scroll-bars . nil) default-frame-alist) Put that in your early-init.el and see what happends. The same for the rest of your .Xresource.

Thank you very much! I actually have a tab with your config opened for like a month already to check sometime later:) I don't see where I load Xresources specifically, but I will take a look. Regarding autoloading non interactive function. Again, need to check this later, but I think I have the only one which is triggered by a script to load Kitty terminal scrollback. The updating of packages is done via an external script as well, which loads early init and utils only, hence the initialization of packages there, but I will reconsider this to load more on timers. I will definitely check package-install-file as well. Didn't know it existed. But again, the external script processes the autoloads for me as well, making it possible to update on one computer what I done on another one. About the flickering: when daemon frame is opened, it opens in a small window and then resizes to be maximized. On non daemon frames this is handled pretty nice by alias 'emacs -mm' 🤷 Thanks again for the fine tips!

> Thank you very much! I actually have a tab with your config opened for like a month already to check sometime later:) :) Cool. That explains why I thought you had similar ideas as mine. Please be careful, mine setup has bugs, and is just a very big experiment and a general learning experience. It is on my init generator and setup that I learned lisp programming. On Windows it works only if symbolic links are enabled, and both windows and linux demand the hacked lisp/package.el to be loaded priot to updating. Also note, that my generator will generate an init file for the specific machine, so it does not prove for all kind of paths and files; the produced init file is meant to be like a hard-coded (and non-portable) setup for the particular machine. But I have to admit that I haven't executed the idea very well; there are still some extra computations done and quite few bugs I have to fix, but I have lost interest. However, it works well for me. > I don't see where I load Xresources specifically I see the config in emacs.Xresources in packages/emacs. I guess you merge that in your .Xresources file in your ~/ dir; I haven't check what install.sh does. > I think I have the only one which is triggered by a script to load Kitty terminal scrollback There are 4 non-interactive functions with autoload cookie in ig-autoload-edit.el; I assume there are more in other files, but I haven't checked. > About the flickering: when daemon frame is opened, it opens in a small window and then resizes to be maximized. Isn't it rather how X works? For example, when I start a small window with any application, I see similar behavior. Probably the way window manager animate maximization. Maybe try some other window manager? For the Emacs part, try to add those two lines to early-init.el; I think the initial-frame-alist is the one you really want. With that one I see really smooth animation, but it does not work well in non-fullscreen mode with my window manager. You maybe run Emacs only in fullscreen so for you it maybe does not matter. > Thanks again for the fine tips! You are welcome; you should really take my tips with a grain of salt; I am also really learning it, so I myself might be unaware of some detail.

You can do that if you want. I don’t care. I said I didn’t think it would help. Kudos on adding nothing to the conversation.