-
-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add scrollspeed for Menu and increase the default for non apple system #2616
Conversation
We could also try normalizing with |
Compile Times benchmarkNote, that these numbers may fluctuate on the CI servers, so take them with a grain of salt. All benchmark results are based on the mean time and negative percent mean faster than the base branch. Note, that GLMakie + WGLMakie run on an emulated GPU, so the runtime benchmark is much slower. Results are from running: using_time = @ctime using Backend
# Compile time
create_time = @ctime fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @ctime Makie.colorbuffer(display(fig))
# Runtime
create_time = @benchmark fig = scatter(1:4; color=1:4, colormap=:turbo, markersize=20, visible=true)
display_time = @benchmark Makie.colorbuffer(display(fig))
|
Test failure is unrelated |
I actually don't think it's an apple thing, I think it's a trackpad vs mouse thing. A scroll wheel usually has a discrete scroll behavior and that seems to trigger a value of 1. And trackpad values come much more frequently but with smaller values. |
For example, this is what I get when I scroll a little bit, like a centimeter downwards, on my macbook:
I don't know what the correct way is to reconcile that with a mouse that outputs |
Hmm, I thought it was kind of the inverse issue where ios had larger numbers. But if it's trackpads that have more scroll events and feel faster then I'm not sure what to do about it. Something like |
One hacky workaround I thought about was to simply feed the scroll values through some logic that checks if there has ever been a value other than 0, 1 or -1. If yes, then apply a trackpad scaling behavior, otherwise scroll wheel. |
My scroll wheel generates whole values, but if I scroll fast enough, I can get 2, 3, or 4 returned also. |
On my old laptop the trackpad is recognized as -1/0/+1 on ubuntu. On windows it's not working at all anymore. I guess my drivers got corrupted somehow... I guess we could check something like |
src/makielayout/blocks/menu.jl
Outdated
# Hack to differentiate mousewheel and trackpad scrolling | ||
step = (isinteger(y) ? 15.0 : 1.0) * m.scroll_speed[] * y | ||
new_y = max(min(t[2] - step, 0), height(menuscene.px_area[]) - listheight[]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume this will cause problems with trackpads but maybe it's worth trying?
I think for the heuristic we do need some value tracking, because a trackpad can also output integers: s = Scene()
on(vals -> any(x -> x != 0 && isinteger(x), vals) && println(vals), s.events.scroll)
s With this I get occasional output when scrolling around:
|
Yea, that's what I expected. Since this would be generally useful, should we adjust the scroll event to be |
Wouldn't it be easiest to modify the number sent out by the event struct already so that users get usably transformed values? Kind of doing what glfw is not doing for us. The values would change compared to what they are now but I wouldn't consider that change breaking. In terms of the logic, I would set the default to assume mouse and change that to touchpad when a non-integer is encountered maybe? That would flip the trackpad correctly from the first non-integer sample, which given the accelerating motion of the fingers should happen pretty much immediately? I have no idea if there aren't mice with smoothly varying wheels that would break this scheme but I guess we'll find out? Another question is if this decision can be made across scenes or if it's per scene? |
I generally prefer making changes like that a bit later, just in case some use cases do not want the change. But we can do that as well.
Yea sounds good. From what googling about this topic showed me it seems like apple mouses have fractional scrolling on macs at least, while 3rd party ones do not. I have two logitech mouses with free swinging scroll wheels which only produce integer scroll steps on ubuntu and windows.)
If we do the scaling before |
I should find the mouse I have lying around here somewhere and test it on mac. |
Looking at GLFW it seems like apple has fractional scrolling natively Windows and linux with x11 don't And linux with wayland, does I guess, but I don't know if it would need rescaling: |
Weird that glfw's also using seemingly arbitrary constants for scaling. I guess for Mac it would matter whether the active device |
Yea. Godot also has a hardcoded scaling |
Should we merge this for the next release? |
Description
Fixes https://discourse.julialang.org/t/how-to-increase-a-scrolling-speed-in-makie-menu/93221
I also added a news entry for #2614 since I forgot to do it there and this is a small pr as well.
Type of change
Checklist