Closed DexterLagan closed 4 years ago
I was able to get a comfortable behavior by 1) updating the code so the timer is reset at each buffer change, and 2) adjust the timer's timeout to 1000ms instead of 300 :
(define/private (start-the-timer now?)
;(unless timer-running?
(set! timer-running? #t)
(send timer start (if now? 10 1000) #t)) ;) ; default 10 300
The original code does not reset the timer when a buffer change is detected, and the delay occurs while the user is typing, making it uncomfortable. Apologies, I have to learn how to make a commit.
Thanks for identifying this as the culprit for the unfortunate slowness!
One question: are you seeing this only on the first one, or every time the content of the blue box changes?
If it is every time, do you see that the fetch
function is called many times or just once? That is, if you were to put a printf between these two lines do you see it printing out only once or do you see it printing out many times?
Hello sir,
The delay only happens the first time the blue box is populated. Once it’s done, subsequent queries are instant. There’s something about the very first access to documentation, probably the cache init. that takes a second or two during the first fetch.
Dex
Thanks! I'll push a fix.
I traced the problem back to blueboxes-gui.rkt. Adjusting the timer to a longer default improves things, but only offsets the blue-box display. Could (update-the-strs) be run in the docs-text-gui-mixin constructor? I wasn't able to do this as startpos isn't yet initialized and causes an error at startup. Another possibility would be to run (update-the-strs) in a separate thread or future as not to interrupt the main thread.
The relevant code is following :
;; triggered when buffer has changed (define/private (trigger-buffer-changed-callback #:now? [now? #f]) (when (or locked? mouse-in-blue-box? (not the-strs)) (set! update-the-strs-coroutine #f) (start-the-timer now?)))
...