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

Resizing visualizations #7164

Merged
merged 19 commits into from
Jul 9, 2023
Merged

Resizing visualizations #7164

merged 19 commits into from
Jul 9, 2023

Conversation

vitvakatu
Copy link
Contributor

@vitvakatu vitvakatu commented Jun 29, 2023

Pull Request Description

Closes #7047

Adds an ability to resize visualizations by dragging a special (invisible) shape along the bottom and right borders of visualizations.

  • Visualizations are aligned to the left border of the node now.
  • Default visualization width now equals to the node's width (default height is the same)
  • Changing the width of the node also changes visualization width, but only if no manual drag-resizing was applied
  • Visualization size is preserved when reopening visualization (but it is not saved in project metadata)
  • No visual indication that resizing is possible exist, it will be implemented in Mouse pointer should change shape on visualization boundaries #7049
2023-07-03.13-18-16.mp4

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • All code has been tested:
    • Unit tests have been written where possible.
    • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

@vitvakatu vitvakatu self-assigned this Jun 29, 2023
@farmaazon farmaazon linked an issue Jun 29, 2023 that may be closed by this pull request
@vitvakatu vitvakatu marked this pull request as ready for review July 3, 2023 08:38
Copy link
Contributor

@farmaazon farmaazon left a comment

Choose a reason for hiding this comment

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

If adding new layers is a way to go, agreed with @wdanilo, then it's ok, but otherwise I would restrain from adding new layers.

Comment on lines 58 to 61
/// Default width and height of the visualization container.
pub const DEFAULT_SIZE: (f32, f32) = (200.0, 200.0);
/// Minimal allowed size of the visualization container.
const MIN_SIZE: Vector2 = Vector2(200.0, 200.0);
Copy link
Contributor

Choose a reason for hiding this comment

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

The DEFAULT_SIZE could also have Vector2 type.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@@ -278,11 +282,15 @@ impl View {
}

fn init(self) -> Self {
self.init_background();
let styles = StyleWatch::new(&self.scene.style_sheet);
Copy link
Contributor

Choose a reason for hiding this comment

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

The FIXME comment was lost. You can also take the chance and change it to StyleWatchFRP (but it would need some FRP nodes for refreshing).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Restored the fixme comment, also used FRP for part of the stuff in this method. The main stopper is shadow for dom, I don't think we have FRP-based API for that at the moment.

@@ -561,13 +587,18 @@ impl Container {
let action_bar = &model.action_bar.frp;
let registry = &model.registry;
let selection = Animation::new(network);
let width_anim = Animation::new(network);

let on_down = model.view.resize_grip.on_event_capturing::<mouse::Down>();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need to do this on capturing phase? Shouldn't the grip be just over elements?

Also, the var name does not say it's resizing mouse down, so looking 30 lines below we may miss this information.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

TBH I just copied bits if @wdanilo's implementation of drag-n-drop in the list editor :D
Removed capturing, seems to be working just fine.

let width_anim = Animation::new(network);

let on_down = model.view.resize_grip.on_event_capturing::<mouse::Down>();
let on_up_source = scene.on_event::<mouse::Up>();
Copy link
Contributor

Choose a reason for hiding this comment

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

source suggests this is a source node. Why does this need the prefix, and on_down does not?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed it

Comment on lines +203 to +208
let overlay = Rectangle::default().build(|r| {
r.set_color(INVISIBLE_HOVER_COLOR).set_border_color(INVISIBLE_HOVER_COLOR);
});
let resize_grip = Rectangle::default().build(|r| {
r.set_color(INVISIBLE_HOVER_COLOR).set_border_color(INVISIBLE_HOVER_COLOR);
});
Copy link
Contributor

Choose a reason for hiding this comment

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

Looking through the code, I have no idea how it works: we have only one rectangle for resize grip, which somehow covers both axes, while being also a child of overlay (so technically, it's over overlay).

Copy link
Contributor Author

@vitvakatu vitvakatu Jul 3, 2023

Choose a reason for hiding this comment

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

I added the comment explaining it to the definition of resize_grip field. So resize grip is below overlay, and has a slight offset to the bottom right, so that it "peeks" from under the overlay. The ordering is done through partition layers, see below.

Screenshot 2023-07-03 at 17 21 47

Comment on lines +783 to +784
viz_resize_grip,
viz_overlay,
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand EnsoGL correctly, we do not have any actual performance gains from using Rectangle if it forces us to create new layers, as the layers are a separate draw calls anyway. Perhaps the resize_grip could be a custom shape? That would make the code simpler (we already have a bit too many layers).

If you add new layers because you need to set ordering of the rectangles, you should probably use instance ordering implemented in #6140 instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not using layers here, but rather partition layers implemented in #6140, as you suggested. All these added layers are "fake" ones, so everything should be ok here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, I forgot about partition layers (and that they are in the same place as normal layers).

@vitvakatu
Copy link
Contributor Author

After discussion with @Frizi I decided to take a second look at the selection shape, and was able to replace it with a Rectangle. So one less custom shader is used in the application now. In total, this PR replaces two custom shapes with Rectangles. I decided to include this change along with review fixes into this PR. @farmaazon you can review this comment: f290006

I also checked how table visualization looks like on develop – and it doesn't have rounded corners there either, so I'm removing mentioning it from the PR description.

@vitvakatu vitvakatu requested a review from farmaazon July 3, 2023 13:55
@vitvakatu
Copy link
Contributor Author

As discussed on the demo, I added max size restriction (80% of screen dimensions) and disabled size reset when opening the visualization. Both options can be adjusted by code constants.

app/gui/view/component-browser/src/lib.rs Outdated Show resolved Hide resolved
app/gui/view/graph-editor/src/component/node.rs Outdated Show resolved Hide resolved
@wdanilo
Copy link
Member

wdanilo commented Jul 3, 2023

@vitvakatu would it be possible to remove animation when dragging the size with mouse? If its hard, skip my comment.

@xvcgreg
Copy link

xvcgreg commented Jul 4, 2023

Changing the width of the node also changes visualization width, but only if no manual drag-resizing was applied
The above condition is reset when reopening the visualization, so that it again starts following the width of the node

is that still true after yesterday's meeting?

@vitvakatu
Copy link
Contributor Author

is that still true after yesterday's meeting?

Fixed.

would it be possible to remove animation when dragging the size with mouse? If its hard, skip my comment.

There is no animation when dragging the size with mouse. Animation is only applied when the node size changes.

@farmaazon
Copy link
Contributor

farmaazon commented Jul 4, 2023

QA report 🟡

No regressions, but resizing some visualizations causes a significant performance drop during resize.

resize-test-2023-07-04_11.54.34.mp4

It's probably caused by reflow. @Frizi @wdanilo do you have any ideas how to fix that? Probably we could update HTML only when user stops dragging, but that may worse UX as well (sometimes I want to see the resizing "live" so I know when it's enough).

@vitvakatu vitvakatu added the CI: Ready to merge This PR is eligible for automatic merge label Jul 6, 2023
@vitvakatu
Copy link
Contributor Author

Merging after discussion, we can address performance issues in the future if needed.

@mergify mergify bot merged commit 8020916 into develop Jul 9, 2023
23 of 24 checks passed
@mergify mergify bot deleted the wip/vitvakatu/resize-vis branch July 9, 2023 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI: Ready to merge This PR is eligible for automatic merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Resizing visualization by dragging container's edge.
6 participants