I updated window.rkt, and it fixed the scrolling problem. It's exactly as it was with 7.9. Thanks! One last thing, I noticed that a small window appears top-left corner of the screen before the full DrRacket window opens since 8.0.0.1x :
[image: small-window.PNG] I had trouble capturing it, as it only appears a few seconds. Cheers, Dex On Wednesday, April 7, 2021 at 12:24:13 PM UTC+2 Dexter Lagan wrote: > Thanks for the info, I'll try updating window.rkt and report back. > > What surprises me is that scrolling by keeping the mouse button down > while hovering on the scrollbar is fast and smooth, while using a > two-finger gesture is erratic and choppy (on top of the direction-change > delay). I wonder if there would be a way to map the scrolling gesture > (which might be bound to the mouse wheel handler), to the scrollbar > instead. If one could do this, the scrolling would smooth no matter which > input device is used. > > When it comes to executable file size, I understand that there's a > balance between file loading time and decompression time. > Intuitively, for local machines - especially with today's NVMe's - it > would make sense to generate larger files, with less compression for best > overall performance. However, as soon as one runs an executable file from a > network drive (say, over 100Mbits ethernet), file size might be directly > correlated to startup time, accounting for network transfer time. I don't > know if these ideas are in consideration, and I understand you have other > priorities. I'm available to help with benchmarks, debugging and any other > task you might find useful. > > As always, I greatly appreciate you taking the time to answer with such > detail and care. > > Dex > > On Wed, Apr 7, 2021 at 1:54 AM Matthew Flatt <[email protected]> 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/4ee9e85c-dde7-4053-8963-2b52ffab672dn%40googlegroups.com.
