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

Inconsistent resize behavior for plots #1174

Closed
Bromeon opened this issue Jan 29, 2022 · 3 comments · Fixed by #1184
Closed

Inconsistent resize behavior for plots #1174

Bromeon opened this issue Jan 29, 2022 · 3 comments · Fixed by #1184
Labels
bug Something is broken

Comments

@Bromeon
Copy link
Contributor

Bromeon commented Jan 29, 2022

The resize behavior is different when a plot is "centered" (after double-click) vs. when the position is moved:

egui-resize-plot.mp4

To Reproduce
Steps to reproduce the behavior:

  1. Open plot demo example
  2. Resize horizontally or vertically -- the zoom doesn't change
  3. Move plot slightly with left click
  4. Resize again horizontally or vertically -- when reducing size, plot shrinks

Desktop

  • OS: Windows 10
  • egui master version, commit 3333d63
@Bromeon Bromeon added the bug Something is broken label Jan 29, 2022
@saecki
Copy link
Contributor

saecki commented Jan 30, 2022

Also related to this. Changing the data_aspect when the Plot isn't centered will always zooms out.
The problem in both cases is that egui always tries to keep everything that was previously visble also visible after resizing/changing the aspect ratio, thus always expanding one axis.

I think it would be a better user experience to make sure that the same amount of data on one axis will be kept visible.
So when rapidly resizing like in the video, or trying to find the right data_aspect using a slider the plot wont zoom out further and further.

Either way I think it's more important that this is consistent across resize/aspect-ratio.
So when the behavior will be changed both should be changed.

The code regarding changing the aspect ratio is here

if current_aspect < aspect - epsilon {
self.bounds
.expand_x((aspect / current_aspect - 1.0) * self.bounds.width() * 0.5);
} else if current_aspect > aspect + epsilon {
self.bounds
.expand_y((current_aspect / aspect - 1.0) * self.bounds.height() * 0.5);
}

Changing this would be trivial, and would simplify the code a bit by always expanding/shrinking one axis.

The code regarding resizing is a bit more complex:

// Determine the size of the plot in the UI
let size = {
let width = width
.unwrap_or_else(|| {
if let (Some(height), Some(aspect)) = (height, view_aspect) {
height * aspect
} else {
ui.available_size_before_wrap().x
}
})
.at_least(min_size.x);
let height = height
.unwrap_or_else(|| {
if let Some(aspect) = view_aspect {
width / aspect
} else {
ui.available_size_before_wrap().y
}
})
.at_least(min_size.y);
vec2(width, height)
};

But about the same would apply here.

@s-nie
Copy link
Contributor

s-nie commented Jan 31, 2022

Just stumbled upon this issue. I think #1184 should fix it.

@saecki
Copy link
Contributor

saecki commented Jan 31, 2022

Yes that is pretty much exactly what I had in mind, and more.

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

Successfully merging a pull request may close this issue.

3 participants