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

Toward enable should_render (fix pane render) #318

Merged
merged 11 commits into from
Apr 30, 2021

Conversation

horasal
Copy link
Contributor

@horasal horasal commented Apr 22, 2021

This pr is the first step toward enable should_render, by fixing pane render when switching/resize tab.

When should_render is enabled, pane won't be re-rendered unless its content is changed. When switching tab, panes in target tab may be not changed from its last render. Thus the render requests will be ignored and those panes' areas will mess up.

This pr add a set_force_render to Tab, which will clear the should_render flag of panes belongs to this tab. Then tab::rander call can rerender all panes.

currently, set_force_render is called when:

  • go to tab
  • switch tab next
  • switch tab prev
  • terminal resize

pane should_render will be true if

  • reflow_lines happens
  • new character is written to terminal
  • scroll

@horasal horasal marked this pull request as draft April 22, 2021 07:39
@horasal
Copy link
Contributor Author

horasal commented Apr 22, 2021

All tests passed after enable should_render and remove cfg(test), results can be found at actions for commit d949a99

After that, 8c47401 changes should_render() to true because we still have wide char issue.
aa25ba2 fixes cargo fmt and cargo clippy.

@horasal horasal marked this pull request as ready for review April 22, 2021 08:00
Copy link
Member

@imsnif imsnif left a comment

Choose a reason for hiding this comment

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

Hey, @horasal - great work on this. I very much like this solution. Thanks for being patient with the review taking a bit longer than usual with the burst of attention this project received in the past week :)

Personally, I'm good to go forward with this. But I'd first like to understand the plan: are you interested in continuing the work on this? As I understand it, the main thing we have left is dealing with the implications of wide-characters on this. Do you have a plan to deal with them? I have some ideas otherwise... let me know if/how you'd like to continue. Then we can think if we'd like to have that change as part of this PR or not (eg. there are a few hacky ideas I can think of that can get us to uncomment the conditional in this PR and move forward).

@@ -656,6 +656,11 @@ impl Tab {
pub fn toggle_fullscreen_is_active(&mut self) {
self.fullscreen_is_active = !self.fullscreen_is_active;
}
pub fn set_force_render(&mut self) {
Copy link
Member

Choose a reason for hiding this comment

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

Nice. I would have gone with something on the state of Tab that bypasses the should_render of each pane, but the more I think about it, the more I like this solution.

@@ -315,6 +316,7 @@ impl TerminalPane {
let rows = self.get_rows();
let columns = self.get_columns();
self.grid.change_size(rows, columns);
self.set_should_render(true);
Copy link
Member

Choose a reason for hiding this comment

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

Elegant!

@horasal
Copy link
Contributor Author

horasal commented Apr 26, 2021

are you interested in continuing the work on this? As I understand it, the main thing we have left is dealing with the implications of wide-characters on this. Do you have a plan to deal with them?

I did some experiments but still need many works and far from becoming a PR.

horasal@e8e8639

(In current zellij, grid and cursor treat number of character = width of string = position. However for widechar, width can be larger than character so this rule doesn't apply. I'm not sure a major revise on grid is the right way or not)

I have some ideas otherwise

It will be great if you can make zellij works with widechar!

@imsnif
Copy link
Member

imsnif commented Apr 27, 2021

For sure making Zellij support wide characters is on the roadmap, but as you say this requires a bigger change.
I was thinking we can improve on the current functionality (namely, uncomment that if), if we do the following:

  1. Identify wide characters as part of the TerminalCharacter struct
  2. Force a tab re-render if there's a wide character anywhere in the viewport.

A little hacky, but I think it's better than what we have now and will probably give us a performance boost until we can handle them properly. What do you think?

@horasal
Copy link
Contributor Author

horasal commented Apr 27, 2021

It sounds good so I implemented it: https://github.com/horasal/zellij/tree/widechar_force_render
but panes still messed up... Did I miss something?

@imsnif imsnif mentioned this pull request Apr 28, 2021
@imsnif
Copy link
Member

imsnif commented Apr 28, 2021

It sounds good so I implemented it: https://github.com/horasal/zellij/tree/widechar_force_render
but panes still messed up... Did I miss something?

Unfortunately, you're not missing anything - this happens in main too :D

Since we don't support wide unicode characters yet, we don't properly detect them in order to line wrap inside a pane. So they end up being line-wrapped by the terminal emulator itself.

This issue is super high priority for us to fix, and the only reason I didn't get to it myself yet is that there are other super high priority fixes on my plate before it :)

That being said, I think it should not interfere with this PR... I'm happy you implemented this idea! Is it ready for a review?

@horasal
Copy link
Contributor Author

horasal commented Apr 29, 2021

That being said, I think it should not interfere with this PR... I'm happy you implemented this idea! Is it ready for a review?

I agree with you. This pr should not be blocked by widechar problem. This is ready for a review.

@imsnif
Copy link
Member

imsnif commented Apr 29, 2021

Hey, this is great! I'm good to go with this, but I would prefer to go with your solution of the wide characters and then uncomment the if true line in the render function. What do you think?

@horasal
Copy link
Contributor Author

horasal commented Apr 30, 2021

merge widechar_force_render, and uncomment if true in pane render func.

@imsnif
Copy link
Member

imsnif commented Apr 30, 2021

Thank you very much for your work on this!

@imsnif imsnif merged commit 454ad0e into zellij-org:main Apr 30, 2021
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.

2 participants