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 racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/6914ecce-66f2-4221-9290-355c9ebcc78bn%40googlegroups.com.
