I tested with Racket v7.8 bc and it was also slow. I also tested it with a year old version of my code and added similar `time` calls around the drawing code and it behaved like the recent version redrawing for all the mouse events, only difference is that the on-paint takes around 23ms instead of 50ms. So the older code takes half the time. So maybe the debounce is the right solution, because I can't find a version where something similar happens automatically.
I also wonder why the drawing has gotten so slow, maybe the memoization in the app fails somewhere and it repeatedly tries to load data from the sqlite db. Is the debounce the "right" way to do this? Maybe someone has a clever solution to collapse the calls to refresh less manually. I was under the impression refresh was doing that automatically but maybe at a different granularity that isn't working for my app/wanted performance. Now I also tested old app code with new racket and the draw is around 23ms there too. So the extra slowness seems to be a problem in the application logic introduced in the new code. And it seems that it just made it slow enough to make me notice that a debounce is useful for snappier user-feedback. So the next step for me is to look at the differences between the old and new code. schle...@gmail.com schrieb am Samstag, 22. Mai 2021 um 05:37:32 UTC+2: > I have a racket gui app that uses a canvas% with overridden on-event and > on-paint methods. > When the user hovers over drawn elements the on-paint is called via (send > this refresh) > to display the element under the cursor with a selection/outline. > > Recently I noticed that this has gotten extremely slow. > It seems to me this might be a difference between BC and CS, but I haven't > checked with different versions in depth yet. (just from the > behavior/performance I remember it had in the past) > > In the past a call to (send this refresh) seemed to be processed > concurrently in regard to on-event. > Now it seems like the first (send this refresh) eagerly triggers the > on-paint and this on-paint somehow blocks the processing of on-event until > the on-paint is finished, after that 1 more mouse event is processed > re-triggering the on-paint. > Effectively redrawing for every mouse event, causing the app to draw old > uninteresting frames (because the mouse events aren't processed fast enough > and only the last position is interesting for me). > > Currently I have implemented a workaround: > (define (oneoff-timer interval thk) > (new timer% > [notify-callback thk] > [interval interval] > [just-once? #t])) > > (define (debounce interval thk) > (define timer #f) > (define (fire) > (set! timer #f) > (thk)) > (define (trigger) > (unless timer > (set! timer (oneoff-timer interval fire)))) > trigger) > > ;; within the canvas impl > (define dirty! (debounce 50 (thunk (send this refresh)))) > ;; within on-event calling (dirty!) instead of (send this refresh) directly > ;; this effectively waits at least 50 ms before trying to refresh thus > allowing most on-event > ;; calls to complete before on-paint is executed the first/next time, thus > only drawing the last frame or a few in-between frames if the mouse is > moved for a long time > > I may try to construct a minimal example, but wanted to put the info out > there, because the behavior seems so different from before. > > Tested version: Racket v8.1 [cs] linux > > Simon > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/81fd2264-4806-4e93-8424-f63deb114e1en%40googlegroups.com.
