I ran the program with your modifications, but counter to the documentation <https://docs.racket-lang.org/gui/event_.html?q=get-time-stamp#%28meth._%28%28%28lib._mred%2Fmain..rkt%29._event~25%29._get-time-stamp%29%29>, the values I get from get-time-stamp don't seem at all similar to current-milliseconds or current-inexact-milliseconds. I ended up defining delta as follows (with 1559695139340 being a guess):
(define delta (- (current-inexact-milliseconds) 1559695139340 (send event get-time-stamp))) Here are the results: $ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt Mouse Min: 2.425048828125 Max: 97.818115234375 Mean: 30.901338585251057 StdDev: 28.349128820378922 Paint Min: 0.282958984375 Max: 10.380859375 Mean: 4.27886962890625 StdDev: 4.162199753791872 $ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt Mouse Min: 2.034912109375 Max: 295.45703125 Mean: 54.28094064372857 StdDev: 40.51587689852278 Paint Min: 0.177978515625 Max: 6.715087890625 Mean: 3.2418212890625 StdDev: 2.868002614564615 So this perhaps shows that mouse events are being triggered almost twice as slowly in 7.3, but I think my hack makes these numbers unreliable. Also, the latency experienced interacting with the plot seems much worse than just twice as slow. Are you at least able to see a disconnect between current-inexact-milliseconds and get-time-stamp? Evan On Wednesday, June 5, 2019 at 2:17:46 AM UTC-10, Alex Harsanyi wrote: > > I had a look at the code and it is not exactly what I had in mind for the > measurements. The problem with your measurements is that the canvas is > re-drawn only when needed, so the time between two calls to on-paint is not > relevant for performance measurements. > > For the on-paint, the time of the draw itself needs to be measured: > > (define/override (on-paint) > (define begin-timestamp (current-inexact-milliseconds)) > (super on-paint) > (define end-timestamp (current-inexact-milliseconds)) > (set! paint-event-stats > (update-statistics paint-event-stats (- end-timestamp begin- > timestamp)))) > > For the mouse event, the time between when the event is created and the > time it is passed to the callback: > > (define ((make-current-value-renderer fn) snip event x y) > (define delta (- (current-inexact-milliseconds) (send event get-time- > stamp))) > (set! mouse-event-stats (update-statistics mouse-event-stats delta)) > (define overlays > (and x y (eq? (send event get-event-type) 'motion) > (list (vrule x #:style 'long-dash) > (point-label (vector x (fn x)) #:anchor 'auto)))) > (send snip set-overlay-renderers overlays)) > > > Alex. > > On Wednesday, June 5, 2019 at 8:06:26 PM UTC+8, evdubs wrote: >> >> Thanks for responding, Alex. >> >> Here's what I came up with <http://pasterack.org/pastes/893> that I >> think satisfies your recommendations. It shows the sin() plot, expects >> interaction for 10 seconds, then prints min/max/mean/std dev for both the >> mouse-event-callback for the snip and on-paint for the editor-canvas%. >> >> Here's the output from running that with Racket 7.2 and Racket 7.3.0.4: >> >> $ ./racket-7.2/bin/racket ~/Code/racket/chart-lag-test.rkt >> Mouse >> Min: 1.115966796875 >> Max: 1209.123046875 >> Mean: 40.23961775104986 >> StdDev: 81.88591520019294 >> >> Paint >> Min: 3.35302734375 >> Max: 275.579833984375 >> Mean: 79.6534423828125 >> StdDev: 113.45367443728956 >> >> $ ./racket-7.3.0.4/bin/racket ~/Code/racket/chart-lag-test.rkt >> Mouse >> Min: 1.072021484375 >> Max: 1095.2412109375 >> Mean: 21.93592705160883 >> StdDev: 54.53777963909044 >> >> Paint >> Min: 3.18798828125 >> Max: 284.447998046875 >> Mean: 80.8831787109375 >> StdDev: 117.90272049413493 >> >> These numbers seem to suggest that 7.3 is an improvement, at least from >> the mouse-event stats, even though that is counter to the experience from >> interacting with the plot. Have any other ideas? >> >> Evan >> >> On Tuesday, June 4, 2019 at 1:39:49 PM UTC-10, Alex Harsanyi wrote: >>> >>> >>> >>> On Tuesday, June 4, 2019 at 11:32:42 AM UTC+8, evdubs wrote: >>>> >>>> Thanks for trying it out. >>>> >>>> I just tried using the bash installer from >>>> https://download.racket-lang.org/ and I experience the same issue of >>>> lagginess in 7.3. I also tried using a snapshot release from >>>> https://plt.eecs.northwestern.edu/snapshots/ and I experienced the >>>> same issue. >>>> >>>> I am not sure what I should try next other than maybe profiling, but I >>>> have not had much luck making effective use of the profiler in the past >>>> for >>>> interactive applications. >>>> >>> >>> Here are a few things you can try: >>> >>> First, check again whether there’s a performance drop in Racket 7.2 too >>> -- you >>> don’t want to spend time tracking down a Racket problem only to find out >>> that >>> the latest Ubuntu update disabled the hardware acceleration on the >>> graphics >>> card. >>> >>> If it is indeed a regression in Racket 7.3, you can try narrowing the >>> problem >>> down to either rendering or mouse event delays: >>> >>> * you can measure the time it takes to render the plot by measuring the >>> time >>> the paint method of the `editor-canvas%`. You will need to create a >>> custom >>> `editor-canvas%` and override `on-paint` and use >>> `current-inexact-milliseconds` to measure the time. >>> >>> * to check if mouse events are delivered too late to the callback. You >>> can use >>> the `get-time-stamp` method on the event and compare it against >>> `current-inexact-milliseconds` to determine the delay. >>> >>> You will need to compare both values against Racket 7.2 to see which one >>> is >>> causing the slow down. >>> >>> Alex. >>> >> -- 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/0c0648e2-7013-4422-825f-25235e6618c9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
