Fixes#5174.
The drag velocity was not being updated unless the cursor counted as
"dragging", which only happens when it's in motion. This effectively
guarantees that the drag velocity will never be zero, even if the cursor
is not moving, and results in spurious scroll velocity being applied
when the cursor is released.
Instead, we update the velocity only when the drag is stopped, which is
when the kinetic scrolling actually needs to begin. Note that we
immediately *apply* the scroll velocity on the same frame that we first
set it, to avoid a 1-frame gap where the scroll area doesn't move.
I believe that *not* setting `scroll_stuck_to_end` and `offset_target`
when the drag is released is the correct thing to do, as they should
apply immediately once the user stops dragging. Should we maybe clear
the drag velocity instead if `scroll_stuck_to_end` is true or
`offset_target` exists?
* Closes#5174
* [x] I have followed the instructions in the PR template
Part 1 of 2 of adding a better API for egui_plot's auto-bounds feature.
In this PR:
- change the `Plot` builder struct field to `default_auto_bounds` (was
`auto_bounds`)
- change the `Plot` state field to `auto_bounds` (was `bounds_modified`)
- minor improvements to `Vec2b`
Thanks to `impl From<bool> for Vec2b` one can now shorten some builder
calls, like:
Previous:
```rust
egui::ScrollArea::vertical()
.auto_shrink([false; 2])
```
New:
```rust
egui::ScrollArea::vertical()
.auto_shrink(false)
```
valadaptive
Emil Ernerfeldt
Antoine Beyeler