Delay before preview box is shown?

[luckman212]

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:

CleanShot.2021-02-19.at.11.17.08.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]

Keep in mind, there is a sort of debounce (for lack of a better word) associated. We purposely wait for selections events to die down first before servicing the event. So if you are moving your cursor quickly down the page, we don't want to generate an inline for every line you touch, we want to wait until the events die down so we are certain you've settled on the line of interest.

This is intentional. I'm sure that maybe part of it is generating a dynamic image, but I think a good portion is that we do not want to bog down performance trying to update things while people are typing and quickly moving around the cursor.

[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.

[luckman212]

Wow, thank you for the response. The above does look better to me 🚀

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

[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]

I've tweaked the timing. I've basically broken it up into separate timings:

1. General event loop will yield to the main thread for 2.5 secs (of course this is the minimum time as the GIL may give more time to the main thread).
2. General cool down after selection and edit events is still 1.2 sec.
3. Scroll event checks will still be less frequent and remain at 0.5 sec (want to reduce lags in scroll, I think a longer wait here works better).

I have an older computer I want to test this on, just to gauge the feel, but assuming things go well this should make it into the next beta. I need to update the underlying color lib before I cut the next beta release, but I should get it out soon-ish.

[facelessuser]

It feels fine on my 10 year old mac and my recent mac, I think it is safe to ship.

[luckman212]

Good news. Can't wait to try!

[facelessuser]

Slow night, went ahead and pushed it out: #159 (comment).

Package Control probably won't see the release for an hour or two, but if afterwards it doesn't update your coloraide dependency, just run "Package Control: Satisfy Dependencies" from the command palette. A restart of Sublime may be needed. The dependency provides a number of color translation fixes and such.

Let me know if that gives you more of what you were looking for.

[luckman212]

@facelessuser Thanks again for this. I was able to pull in the new beta. It's a subtle difference, but noticeable. It does feel more responsive.

[facelessuser]

Great, then I shall consider this issue closed 🙂.