Delayed coloring / application of colorscheme

[mcctuxic]

Hardware: Ryzen 5 3600 / Nvidia GeForce RTX 2060 SUPER / 32 GByte RAM

The change from monochrome display to the final colored display is delayed. This happens with the OpenGL wezterm as with
URXVT, which doesn't use OpenGL. No other heavy process was running while the screencapture was done.

delayedcoloring.mp4

[NTBBloodbath]

Hey, yeah this is something that I'm aware of. It's not a hardware nor terminal related issue, it's simply because of how Doom loads stuff and and how long it takes for Doom modules to load.

I've been trying to fix this for a long time but i think the only thing that I can do is change the loading order to make it faster, but it will not disappear 😕

[mcctuxic]

Hi Alejandro, one observation: After a fresh reboot of my Linux or if nvim was compiled from its repo, the effect is even worse. I disabled all modules (doom_modules.lua), which are able to be disabled without getting errors and the effect is still there. For my it looks like it is not processing speed as such, which delayed the final redraw of the contents but loading time, because after a recompile of nvim or a reboot the file caches of Linux are empty. What do you think?

…

On 09/25 09:25, Alejandro wrote: Hey, yeah this is something that I'm aware of. It's not a hardware nor terminal related issue, it's simply because of how Doom loads stuff and and how long it takes for Doom modules to load. I've been trying to fix this for a long time but i think the only thing that I can do is change the loading order to make it faster, but it will not disappear 😕 -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #131 (comment)

[NTBBloodbath]

Ah yeah, cold runs makes it even worse, and Neovim isn't usable until it finishes loading all Doom stuff and that's a really bad thing for us. I don't really know how should we hack or bypass this at the moment, if you have an idea please lemme know.

[NTBBloodbath]

Hey, I got some good and bad news on this.

The good one if that I found the root of this, since we use vim.defer_fn() in our init file we delay almost everything to happen until the Neovim API functions are safe to call. That means, we avoid having weird errors and also a faster startup time.

The bad one is that I can remove the deferred logic and the colorscheme will load instantly, no more delays. However, this will only work if the colorscheme is available on launch so manually added colorschemes with packer will cause an error because packer_plugins table is not loaded yet.

If we manually source the plugin/packer_compiled.lua file for hacking this behavior with the packer_plugins table then some plugins breaks and it's hell haha.

As a "hack" to have coloring before loading our UI module (that actually loads the user-defined colorscheme in doom_config.lua) we can manually set the doom-one colorscheme at top of our init because this one will be always here and then the user-defined colorscheme will be loaded once the packer_plugins table is available by using the vim.defer_fn() method. Don't know if you like this "solution", however is the only option that I see right now.

Nevermind, I was trying out this behavior with a gruvbox colorscheme and don't know why but packer was adding it to opt/ directory so it was obviously not available on startup. I'm going to do more testing and use this refactor to our init for a few days to discard potential bugs and happily we will get rid of this delay.

[mcctuxic]

I am not /that/ deep into neovims internals...so beware of "crazy ideas" from my side ... ;) If doom-one is able to be launched right in the beginning (and there for avoid "late coloring") and user defined colorschemes are available later, because they may be plugin dependand...would it be possible to put just that userplugin/-colorscheme in front of anything else? I never used vim.defer_fn() in my (minimal) setups for neovim and I am currently using colorbuddy (a plugin) with modified (different colors, not different code) version of a colorscheme which is available from the site of colorbuddy, which depends on colorbuddy...and have no delays whatsoever. I am using a minimal amount of plugins, though. Another thing: Doomnvim uses colorizer as hexcode coloring tool. Try Hexokinase (YES! The name is correct ;) ). It is faster, since it is implemented in Go, and has a lot of options.

…

On 09/28 07:12, Alejandro wrote: Hey, I got some good and bad news on this. The good one if that I found the root of this, since we use `vim.defer_fn()` in our init file we delay almost everything to happen until the Neovim API functions are safe to call. That means, we avoid having weird errors _and also a faster startup time_. The bad one is that I can remove the deferred logic and the colorscheme will load instantly, no more delays. However, this will only work if the colorscheme is available on launch so manually added colorschemes with packer will cause an error because `packer_plugins` table is not loaded yet. If we manually source the `plugin/packer_compiled.lua` file for hacking this behavior with the `packer_plugins` table then some plugins breaks and it's hell haha. As a "hack" to have coloring before loading our UI module (that actually loads the user-defined colorscheme in `doom_config.lua`) we can manually set the `doom-one` colorscheme at top of our init because this one will be always here and then the user-defined colorscheme will be loaded once the `packer_plugins` table is available by using the `vim.defer_fn()` method. Don't know if you like this "solution", however is the only option that I see right now. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #131 (comment)

[NTBBloodbath]

Right so the doom-one hack isn't a thing anymore, user-defined colorschemes should work as expected if they're not being lazy-loaded (I don't really see why should someone lazy-load them tho).

This also applies to colorschemes with dependencies like colorbuddy or lush.nvim. If the required dependency is available on launch (not lazy-loaded) then them should work like a charm on startup.

In the new init file (that I'm gonna push in a few mins) we still have the defer_fn to safely load some stuff and avoid errors that shouldn't happen with certain plugins loading, but this will not directly affect coloring nor Doom runtime speed so it's ok IMO.

---

About hexokinase I'll not add it at the moment until RRethy make binary releases for the vim-hexokinase plugin runtime dependency since I don't want to tell our users "Hey, you need to install Golang to use this plugin". However I'll really consider it and maybe send a PR to hexokinase repo to add the releases stuff, the virtual text is definitely a killer feature to me, also a cleaner and more pleasant approach to display the colors.

[mcctuxic]

Oh! oooops! I didn't realized that - as I included Hexokinase in my local (other-than-doom-nvim) setup - Hexokinase hasn't included binaries. Go is installed here, though...it must had been compiled its stuff in the beground without me noticing that. Yes, users should not be urged to install another programming language just for being able to use doom-nvim - absolutely correct ! :)

…

On 09/28 09:43, Alejandro wrote: Right so the doom-one hack isn't a thing anymore, user-defined colorschemes should work as expected if they're not being lazy-loaded (I don't really see why should someone lazy-load them tho). This also applies to colorschemes with dependencies like colorbuddy or `lush.nvim`. If the required dependency is available on launch (not lazy-loaded) then them should work like a charm on startup. In the new init file (that I'm gonna push in a few mins) we still have the `defer_fn` to safely load some stuff and avoid errors that shouldn't happen with certain plugins loading, but this will not directly affect coloring nor Doom runtime speed so it's ok IMO. --- About hexokinase I'll not add it at the moment until RRethy make binary releases for the `vim-hexokinase` plugin runtime dependency since I don't want to tell our users "Hey, you need to install Golang to use this plugin". However I'll really consider it _and maybe send a PR to hexokinase repo to add the releases stuff_, the virtual text is definitely a killer feature to me, also a cleaner and more pleasant approach to display the colors. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: #131 (comment)

[NTBBloodbath]

Agreed, let's see how it goes. Hopefully we will be able to replace colorizer soon haha

By the way this issue should be finally fixed, already pushed the init file changes. As always feel free to reopen this issue if you're still facing this delay problem after updating :)