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/332e02b7-734b-454b-b94d-f1703af02e4an%40googlegroups.com.
