So in conclusion, only two changes required: In const.rkt: (define WHEEL_DELTA 120) to (define WHEEL_DELTA 30)
In Window.rkt: (define wheel-steps-mode 'one) to (define wheel-steps-mode 'integer) The change to const.rkt may affect a lot more code, I'll let you decide if this change should be left local to gen-wheels. It fixes the direction change delay, as well as slow/erratic scrolling on the Thinkpad's trackpoint. Dex On Saturday, April 10, 2021 at 12:54:33 PM UTC+2 Dexter Lagan wrote: > One precision: this work for Racket 8.0 BC release. There might have > been changes made to current. > DrRacket feels as smooth as Sublime Text with this change, a completely > different experience. I'd like to make a proper commit if somebody held my > hand to do so. > > Dex > > On Saturday, April 10, 2021 at 12:44:44 PM UTC+2 Dexter Lagan wrote: > >> Hi again, >> >> After playing around with the gen-wheels procedure and comparing its >> code with the WM_HSCROLL handling, I was able to get fast, accurate and >> smooth scrolling for both mouse and touchpad by switching the >> wheel-steps-mode to 'integer and reducing WHEEL_DELTA by a factor of 4. >> Here's the updated code : >> >> <pre> >> (define wheel-steps-mode 'integer) >> (define/public (get-wheel-steps-mode) wheel-steps-mode) >> (define/public (set-wheel-steps-mode mode) (set! wheel-steps-mode mode)) >> >> (define/private (gen-wheels w msg lParam amt down up) >> (define AUG_WHEEL_DELTA (/ WHEEL_DELTA 4)) >> (let loop ([amt amt]) >> (cond >> [((abs amt) . < . AUG_WHEEL_DELTA) >> (case wheel-steps-mode >> [(one integer) amt] >> [(fraction) >> (unless (zero? amt) >> (do-key w msg down lParam #f #f void (/ amt (exact->inexact >> AUG_WHEEL_DELTA)))) >> 0.0])] >> [(negative? amt) >> (case wheel-steps-mode >> [(one) >> (do-key w msg down lParam #f #f void 1.0) >> (loop (+ amt AUG_WHEEL_DELTA))] >> [(integer) >> (define steps (quotient (- amt) AUG_WHEEL_DELTA)) >> (do-key w msg down lParam #f #f void (exact->inexact steps)) >> (loop (+ amt (* steps AUG_WHEEL_DELTA)))] >> [else >> (do-key w msg down lParam #f #f void (/ (- amt) >> (exact->inexact AUG_WHEEL_DELTA))) >> 0.0])] >> [else >> (case wheel-steps-mode >> [(one) >> (do-key w msg up lParam #f #f void 1.0) >> (loop (- amt AUG_WHEEL_DELTA))] >> [(integer) >> (define steps (quotient amt AUG_WHEEL_DELTA)) >> (do-key w msg up lParam #f #f void (exact->inexact steps)) >> (loop (- amt (* steps AUG_WHEEL_DELTA)))] >> [else >> (do-key w msg up lParam #f #f void (/ amt (exact->inexact >> AUG_WHEEL_DELTA))) >> 0.0])]))) >> </pre> >> >> On Wednesday, April 7, 2021 at 1:54:24 AM UTC+2 Matthew Flatt wrote: >> >>> At Mon, 5 Apr 2021 14:29:22 -0700 (PDT), Dexter Lagan wrote: >>> > I installed the latest build, and it does start. Generated executable >>> is >>> > 80MB vs 32MB for 7.9 BC, about 10MB more than 8.0 release. >>> >>> That difference is again related to the compilation paths, but this >>> time the likely result is that the v8.1 release will be larger in the >>> way you saw here. >>> >>> In the cross-compilation path that the release builds use, there was an >>> unintended layer of compression. (I noticed the size difference before, >>> but had not yet investigated.) Checking that again, if the extra layer >>> is used, the 10% or so savings in file size causes a 5% decompression >>> slowdown for loading. Compressing just the code, meanwhile, makes load >>> times faster on machines that I tried. So, I think the current >>> (non-cross) default is still the best choice for most situations, and >>> I'll adjust cross-compilation to match. >>> >>> We can make the extra layer of compression an option for someone who >>> needs to minimize file size. But a more relevant effect may be the >>> existing configure-time option to compress boot files... >>> >>> >>> Compressing embedded boot files would save 30 MB, which would make a >>> big difference in your case. Compressed boot files take 20-40ms longer >>> to load on a typical machine, which is significant relative to the >>> minimal load time, but it's very little time in many situations. >>> >>> Boot-file compression was already an option for the `configure` way of >>> building on Unix (but the option had rotted; now fixed). I've updated >>> the MSVC build to recognize a `PLT_BOOTFILE_COMPRESS` environment >>> variable to enable boot-file compression when building that way. So, it >>> will be easier to build Racket with compressed boot files --- but you >>> would have to build Racket yourself. >>> >>> It may be that compressed boot files make sense as the default on >>> Windows. I'm starting to lean in that direction, but I'm not sure, and >>> I haven't changed the default for now. >>> >>> > I understand that there's a difference between bytecode and compiled >>> > binary size with CS, but I'm not certain if we're talking about the >>> Racket >>> > distribution itself, or generated executables. Is there any hope to >>> > eventually get closer to BC's executable size with CS? >>> >>> Compressing boot files brings the size of the Racket CS executable/DLL >>> itself closer to Racket BC --- more like a factor of 2 instead of a >>> factor of 10 --- and that turns out to be almost half of the size in >>> your case. But the more code you add in terms of embedded ".zo" files, >>> the more the size difference will approach a factor of 2 overall; I >>> don't see a route to big improvements there. >>> >>> > The raco demod option seemed to do miracles on previous versions, but >>> > never worked on gracket / gui programs for me. >>> >>> Restoring `raco demod` has been on my list, and I may get to that soon, >>> but probably not before v8.1. It may be possible to improve `raco >>> demod` to support `dynamic-require`d pieces like the platform-specific >>> backends in `racket/gui`. >>> >>> > Also, somehow touchpad scrolling has degraded since 7.9 BC (which was >>> > decent, and even had momentum). If I scroll downwards, then upwards, >>> it >>> > keeps going down for another 1 second before switching direction, and >>> > momentum is no longer simulated. If I use the scrollbar, it scrolls >>> fast >>> > and smooth, with no direction problem. >>> >>> I don't know what happened there. Version 8.0 included a change for >>> handling scroll-wheel events, but I don't think that's the same kind of >>> event as touchpad scrolling. You could try changing `(* wheel-scale >>> amt)` in "share/pkgs/gui-lib/mred/private/wx/win32/window.rkt" back to >>> just `amt` to make sure that change isn't the reason. >>> >> -- 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/49cf730d-566d-4ee6-ad0e-355b6ad86e6dn%40googlegroups.com.
