You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 6, 2023. It is now read-only.
I started playing around resizing the terminal and looking what happens. For now I've only fixed a couple of panics with higher resolutions: karolinepauls@bd33c04
However, I could still see some rendering artefacts and I'm investigating some right now. Artefacts appear when the number of characters exceeds 2^16 (resolution over 256x256). 2^16 characters is quite a lot but e.g. tmux continues working fine.
$ git grep ' as u16' shows the lib generally assumes u16.
I haven't fixed the gauge demo is panicking so far because here the root of the problem is using integer percentages instead of floating points:
let width = (gauge_area.width*self.percent) / 100;
Limiting fractional sizes to 0-100 also likely makes scaling choppy.
One way would be to (A) hardcode max resolution to be X:Y where X * Y < 2^16. Another (B) - promote u16 dimensions to u32 (and limit the resolution to 2^32 in case someone's that crazy).
(C) Regarding percentages, I would rather see them as [0, 1] floating points, which would make slicing more precise (3 panes with a ratio of 0.33333333333... will leave a smaller gap than 3 panes with percentage being 33).
I'm looking for some input on that.
The text was updated successfully, but these errors were encountered:
The setup is me rescaling a console window way over what my screen is (and getting frustrated doing so). 2^16 is not that much. At work my console window is stretched across 2 HD screens, which is halfway there.
In order to properly test conditions like that a virtual terminal backend may come in handy.
This issue is a bit about too many things at once, so for now I'll play with the ideas here and then I may come up with some PRs. Otherwise - feel free to split it.
#92 "resolves" artefacts with backends over 2^16 characters.
Percentage remains unresolved (I may look into it but last time I tried to do something, it took me so long that meanwhile you implemented an equivalent :D).
That's great 👍. As you suggested earlier, I think promoting dimensions to u32 might be the next step to cover most use cases. In the meantime, thanks to your work, we have an elegant solution to this problem =).
I started playing around resizing the terminal and looking what happens. For now I've only fixed a couple of panics with higher resolutions: karolinepauls@bd33c04
However, I could still see some rendering artefacts and I'm investigating some right now. Artefacts appear when the number of characters exceeds 2^16 (resolution over 256x256). 2^16 characters is quite a lot but e.g. tmux continues working fine.
$ git grep ' as u16'
shows the lib generally assumes u16.I haven't fixed the gauge demo is panicking so far because here the root of the problem is using integer percentages instead of floating points:
tui-rs/src/widgets/gauge.rs
Line 81 in 56fc434
Limiting fractional sizes to 0-100 also likely makes scaling choppy.
One way would be to (A) hardcode max resolution to be X:Y where X * Y < 2^16. Another (B) - promote u16 dimensions to u32 (and limit the resolution to 2^32 in case someone's that crazy).
(C) Regarding percentages, I would rather see them as [0, 1] floating points, which would make slicing more precise (3 panes with a ratio of 0.33333333333... will leave a smaller gap than 3 panes with percentage being 33).
I'm looking for some input on that.
The text was updated successfully, but these errors were encountered: