Actually the flag version does not work for me. (I thought it did because on-paint was fast enough not to be noticed that it was sequentially processing every mouse event with a paint call)
#(struct:v2 109 80) ;; mouse pos draw ;; beginning of draw cpu time: 8 real time: 8 gc time: 0 ;; duration / end of draw #(struct:v2 110 66) draw cpu time: 9 real time: 9 gc time: 0 #(struct:v2 110 64) draw cpu time: 8 real time: 8 gc time: 0 #(struct:v2 110 62) draw cpu time: 8 real time: 8 gc time: 0 #(struct:v2 112 61) draw cpu time: 9 real time: 9 gc time: 0 #(struct:v2 126 42) draw cpu time: 8 real time: 8 gc time: 0 ... The debounce works because it creates a time-window in which on-paint isn't running allowing all mouse events that arrive in that window to be processed before on-paint blocks processing of on-event. #(struct:v2 51 371) #(struct:v2 49 364) #(struct:v2 44 346) #(struct:v2 44 344) #(struct:v2 44 343) #(struct:v2 44 341) #(struct:v2 42 340) #(struct:v2 42 338) #(struct:v2 42 336) #(struct:v2 42 334) draw cpu time: 8 real time: 8 gc time: 0 #(struct:v2 42 329) #(struct:v2 42 324) #(struct:v2 42 319) #(struct:v2 42 298) #(struct:v2 42 297) #(struct:v2 42 295) #(struct:v2 42 294) #(struct:v2 44 292) #(struct:v2 44 290) draw cpu time: 8 real time: 8 gc time: 0 #(struct:v2 44 285) #(struct:v2 45 282) #(struct:v2 47 279) #(struct:v2 50 270) #(struct:v2 51 270) draw cpu time: 8 real time: 8 gc time: 0 #(struct:v2 51 269) #(struct:v2 52 268) draw cpu time: 8 real time: 8 gc time: 0 ... [sidenote: the difference to yesterdays timings is that more other stuff was running on my box, I think] The debounce makes it work somewhat similar to a "traditional single threaded game-eventloop", the difference being that the game-loop would process the queue of n events that arrived for that frame until it is empty and then do other calculations and finish the frame by rendering, while the debounce just specifies a fixed time for event and other processing before rendering takes place. The mouse event can't run while on-paint runs and the window event priority ensures that on-paint always has a higher prio than mouse-events, this means that we can only process multiple mouse-events in one batch when they don't immediately add a on-paint/refresh event: https://docs.racket-lang.org/gui/windowing-overview.html?q=eventspace#%28part._.Event_.Types_and_.Priorities%29 I constructed a minimal example, while playing around with it I found a variant of flag that works for me: Instead of resetting the flag at the end of on-paint, I use queue-callback to add a low priority callback that resets it, because of event-handling priorities this means that the mouse events can be processed before the flag is reset. (I think this my new favorite solution for a lot of mouse move cases) https://gist.github.com/SimonLSchlee/1a748b5a93b86aea2fc15045cad2be50 The example lets you switch between the 3 modes I have currently added, it is a canvas that changes the color of a grid of rounded rectangles based on mouse position, it also prints mouse position and draw timings to the console. 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/6914ecce-66f2-4221-9290-355c9ebcc78bn%40googlegroups.com.
