Re: [racket-users] canvas% mouse event handling difference in Racket CS?
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.
Re: [racket-users] canvas% mouse event handling difference in Racket CS?
Den lør. 22. maj 2021 kl. 05.37 skrev schle...@gmail.com < schleesi...@gmail.com>: > 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). > I was looking at the code for racket/draw and spotted this: ;; The Racket BC can handle concurrent callbacks in different Racket ;; threads, because it copies the C stack in and out to implement ;; threads. The Racket CS cannot do that, so callbacks have to be ;; atomic. At the same time, we need some atomic callbacks to be able ;; to escape with an exception. It matches your observations. https://github.com/racket/draw/blob/master/draw-lib/racket/draw/unsafe/callback.rkt /Jens Axel -- 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/CABefVgwx9gkphjpGeA08Z-%3DdRvTZMfEbm1B%2B6HzPmi_fWiSKgw%40mail.gmail.com.
[racket-users] canvas% mouse event handling difference in Racket CS?
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/9298249c-3d3d-4f1f-a18d-945ea7d1e34en%40googlegroups.com.
