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

chore: replace big_text with hardcoded logo #1203

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Conversation

joshka
Copy link
Member

@joshka joshka commented Jun 26, 2024

big_text.rs was a copy of the code from tui-big-text and was getting
gradually out of sync with the original crate. It was also rendering
something a bit different than the Ratatui logo. This commit replaces
the big_text.rs file with a much smaller string representation of the
Ratatui logo.

big_text.rs was a copy of the code from tui-big-text and was getting
gradually out of sync with the original crate. It was also rendering
something a bit different than the Ratatui logo. This commit replaces
the big_text.rs file with a much smaller string representation of the
Ratatui logo.
@orhun
Copy link
Sponsor Member

orhun commented Jun 26, 2024

Q: Why not use tui-big-text instead of big_text.rs? Is it because we want to avoid a dependency?

@joshka
Copy link
Member Author

joshka commented Jun 26, 2024

Q: Why not use tui-big-text instead of big_text.rs? Is it because we want to avoid a dependency?

tui-big-text depends on ratatui from crates.io. Afaik, it's not possible to compile a version that works with the version compiled from source when compiling examples as the widget traits don't match even though they are the same.

P.s. This is not quite ready to merge. The GIF file size needs to under 10MB to make it possible for it to show in the readme. Intuitive things that would seem to make things smaller often don't (e.g. reducing the total time increases the file size), so it's a fun optimization problem of getting the timing of the destroy function timing and vhs script timing right.

@kdheepak
Copy link
Collaborator

I think number of pixels that change in a gif affects the size. Maybe decrease the randomness a tad? Alternatively, you can record a .mov and that will render on github.

@joshka
Copy link
Member Author

joshka commented Jun 27, 2024

I think number of pixels that change in a gif affects the size. Maybe decrease the randomness a tad? Alternatively, you can record a .mov and that will render on github.

Yep, this is one of the parameters I've been tweaking and which also has non-linear behavior
The problem is not how to make this work, it's finding the motivation to sit and repeatedly tweak things until they're just right with each iteration taking ~60s to edit, run, evaluate. "Just right" in this context is a GIF that is

  • 15-30s
  • <10MB
  • animation is subjectively not too fast (to not be too jarring)
  • has to end with the text fully visible
  • should not start immediately

I don't like MOVs in this context as they tend to break (with a can't render error) on github often for some reason. That said, this might be a valid fall back position.

I'd suggest running VHS locally vhs examples/vhs/demo2-destroy.tape and checking whether the output looks good enough (I changed the Ratatui text color to white from Red).

demo2-destroy

Note the other thing I noticed is that there's a bit of extra space on the top and bottom of the frame. Not sure exactly what caused that however. Could be anything from OS update, font installation, ttyd change, vhs change, ?

@joshka joshka added the Status: Revision Needed PR changes requested label Jun 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Revision Needed PR changes requested
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants