Delay before preview box is shown?

Just installed 3.0 beta (I’m still using ST3)

(But, this is something that I noticed on 2.x as well, not a new thing.)

There’s a noticable (~0.5s) delay between clicking on a hex color and waiting for the inline preview to appear. I understand that this square is an image and is dynamically generated, but I’m wondering if there’s any way to optimize or speed this up.

Here’s a video:

https://user-images.githubusercontent.com/1992842/108530941-1eb03700-72a4-11eb-8e7a-f67fa503e43d.mp4

Support Info

- ST ver.: 3211
- Platform: osx
- Arch: x64
- Plugin ver.: 3.0.0-beta.01
- Install via PC: True
- mdpopups ver.: 3.7.5
- markdown ver.: 3.1.1
- pygments ver.: 2.1a0
- jinja2 ver.: 2.10.1

[facelessuser]

If the event loop timing is hardware dependent, then maybe an adjustable sleep time in prefs would be the best?

Maybe. If I can come up with a reasonable time that generally works well enough for everyone, I may try that. Really, we just need to maybe reel it in enough to make it a little more snappy. I imagine there is a threshold where people are like, yeah, it’s fast enough, even if it isn’t optimized for the machine.

If after I tweak it and push it out, people are like, “I wanna go fast!!!”, we can expose it. I don’t think the current speed is awful, but yeah it is noticeable enough and maybe too conservative. I think maybe even if we shaved off only a third of the time, it may be enough to feel good enough. Worst case scenario, if I push it out and people aren’t happy with it, we can then make it configurable.

[facelessuser]

We may be able to speed up our event loop some. I’ll see how performance goes. We wait for events to settle down for approx. 0.12 seconds. But then we wait for 0.5 seconds before checking again. Maybe we can cut that 0.5 sec wait in half.

In other plugins, like BracketHighlighter, we can actually just wait for an event to pop in the queue and sleep until that happens. We still “debounce” events, but we can just wake up when events occur. With ColorHelper, we are monitoring scrolling (as we only load color previews within the viewable window), so cannot go completely to sleep as Sublime doesn’t wake us up for scroll, we have to inspect if a scroll takes place, but we can certainly cut that sleep down.

I haven’t measured the impact yet in large files and other areas, but the above shows the suggested change.