Skip to content
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

Drag and zoom support for plots #317

Merged
merged 15 commits into from
Apr 21, 2021
Merged

Conversation

EmbersArc
Copy link
Contributor

Closes #316.

@EmbersArc EmbersArc changed the title drag and zoom support for plots Drag and zoom support for plots Apr 18, 2021
@EmbersArc EmbersArc marked this pull request as ready for review April 18, 2021 18:11
egui/src/widgets/plot.rs Outdated Show resolved Hide resolved
egui/src/widgets/plot.rs Outdated Show resolved Hide resolved
Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for this PR; it works really well, and nice use of the new memory feature!

impl Default for PlotMemory {
fn default() -> Self {
Self {
bounds: Bounds::new_symmetrical(1.),
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is quite arbitrary. Would it make more sense to use Bounds::EMPTY here, and have that to mean "automatic"? Then at the first frame we would get the automatic bounds

impl Default for Plot {
fn default() -> Self {
impl Plot {
pub fn new(name: impl Into<String>) -> Self {
Copy link
Owner

@emilk emilk Apr 19, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be either changed to id_source: impl Hash, or we should actually use it as a String - i.e. show it on hover. Though then I wonder what the difference would be between a plot name and on_hover_ui-tooltip. Probably better to go with id_source: impl Hash and change the examples to use something that looks less like a user-visible name and more like an identifier ("my_plot")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about we use the same system that Window uses with a constructor that takes the shown name and
an id method to set a custom id when required? The title will be visible to the user at some point,
I just haven't thought about how to show it yet.

Comment on lines 368 to 369
/// If true, the bounds will be set based on the data.
pub fn automatic_bounds(mut self, enabled: bool) -> Self {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit under-documented (what is the default? what does it mean for it to be false?).

I wonder if we really need this at all? I like the behavior of automatically calculating bounds at the start and on double-click, but otherwise allow users to scroll and zoom.

egui/src/widgets/plot.rs Outdated Show resolved Hide resolved
egui/src/widgets/plot.rs Show resolved Hide resolved
Copy link
Contributor

@s-nie s-nie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nevermind, wrong account

@EmbersArc
Copy link
Contributor Author

EmbersArc commented Apr 19, 2021

Thanks for the review! I share your concerns about how to handle the plot bounds.
I got a bit carried away and started refactoring this whole thing quite a bit and added new features. If it's alright with you then I'll address the bounds issues there so that those changes don't have to be made twice. The bounds need a bit more thought anyway since there is no way for the user to define them manually or to make them fixed yet. I'll open a PR for these changes as soon as possible.

Is it alright with you when the plotting functionality keeps growing? In #155 you mentioned that
you'd prefer if it didn't get too extensive. But I really like the foundation that you've built here
and see potential for this to grow into something that can be used as much more than just a demo.

@emilk
Copy link
Owner

emilk commented Apr 20, 2021

If it's alright with you then I'll address the bounds issues there so that those changes don't have to be made twice

I'm a bit hesitant to merge a PR that removes a desired feature (include_x/include_y).
Maybe you can open the other PR as a draft so I can take a look?

Is it alright with you when the plotting functionality keeps growing?

I'm alright with that, but it would be good to sync exactly in what direction it is growing before you do too much work! Perhaps you can open a tracking issue with your plans?

@EmbersArc
Copy link
Contributor Author

I'm a bit hesitant to merge a PR that removes a desired feature

Understandable, I added back those methods, and made automatic bounds the default.

I'll open a tracking issue and a PR soon for the coming changes.

Question: Is there a way to tell if a window has been drawn for the first time?

Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized there is an important use-case that this breaks: plotting dynamic data. For instance, plotting the last few seconds of a recorded time series. In this case we want the bounds to automatically follow the data each frame.

I suggest a (hopefully) simple change: add a auto_bounds: bool to PlotMemory and initialize it to true. This is set to false on zoom/pan, and reset to true on double-tap. Then we will maintain previous behavior (tracking dynamic plots) while still allowing the new awesome zoom/pan behavior.

A second use case that need to work is the include_x/include_y (e.g. .include_y(0.0) to include the X-axis in a plot). This should be used when computing automatic bounds, but ignored when users pan and zoom. I suggest changing Plot::bounds to be called Plot::min_auto_bounds and use it as the starting point when computing automatic bounds.

PS: thanks for your patience and work :)

egui/src/widgets/plot.rs Show resolved Hide resolved
egui/src/widgets/plot.rs Show resolved Hide resolved
egui/src/widgets/plot.rs Outdated Show resolved Hide resolved
egui/src/widgets/plot.rs Outdated Show resolved Hide resolved
@EmbersArc
Copy link
Contributor Author

Thanks for the great suggestions! I tried to apply all of them. Might not work in all cases thought, but I don't have time to test it more thoroughly right now.

@EmbersArc
Copy link
Contributor Author

I've opened up a PR based on this one: #331

Copy link
Owner

@emilk emilk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work!

@emilk emilk merged commit 012542d into emilk:master Apr 21, 2021
@EmbersArc EmbersArc deleted the plot-drag-zoom branch April 21, 2021 21:20
@blagovestb2c2
Copy link

Hey guys, awesome library first of all. I found this PR after having problems with zoom. I am not sure how i'm supposed to achieve that on a Plot (mac with magic mouse if it matters). I tried reading the code and zoom seems to require hovering but i only see labels if i hover? And if I hover + track (or slide my finger on my mouse rather), the plot is just dragged. Am I doing something dumb? :D

egui = "0.12.0"
epi = "0.12.0"
eframe = "0.12.0"

@EmbersArc
Copy link
Contributor Author

@blagovestb2c2 You need to hold control while scrolling to zoom

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add drag and zoom support to the plotting demo
5 participants