Setting row limit causes recording to jump/glitch
Utagai opened this issue · 5 comments
I was able to produce a minimal working test case with this asciicast.
This test case simply redirects some garbage from /dev/random into a text file and outputs the octal dump via od (to avoid potentially introducing Unicode bugs). Afterwards, it prints some echo statements.
I then converted this to a gif with the command:
asciicast2gif -w 80 -h 25 https://asciinema.org/a/st5CY0WipJ1S85VkUNjK2HdXb.json cast.gif
The GIF that is then produced by asciicast2gif however, seems to break once the row-limit of 25 is exceeded, and bugs out. It fails to include the echo statements because it seems to get stuck and drop frames. This kind of bug was discovered when I was trying to make my own personal cast:
I am running this on Ubuntu 16.04, and the dependency of ImageMagick is satisfied. Of giflossy/gifsicle, I am using gifsicle, which I compiled from source from its GitHub repository.
My guess is that I'm doing something wrong, most likely something with my dependencies, but I'm not sure where to start looking.
Hey @sickill, I just realized I probably should have included that information!
I am using whatever I got from using npm install --global asciicast2gif, which seems to be asciicast2gif@0.2.0.
If I remember correctly, -h 25 just clips the height of the gif to 25 rows, starting from the top. It doesn't resize the virtual terminal, and doesn't re-interpret text/ascii sequences for the new terminal size. So what you observe is most likely expected. I'll double check the code.
@sickill Interesting. I'm not sure I am convinced however. Taking the original GIF I posted as an example, from what I can tell there is definitely a scrolling behavior to how -h 25 works. Even in the other GIFs I see (that are correct), when terminal output breaks past the row limit, it basically keeps scrolling (focus follows scroll, I believe is the term for this, aka, when you are printing a lot and the terminal auto-scrolls to the bottom).
In the original GIF, after the od command, you can see that the original beginning of the terminal output
is gone (e.g., try looking for the timeout command after the od is ran, it's gone because it was pushed away as the cast scrolled to the bottom of od output). This implies to me that things are scrolling past. Furthermore, in the original cast that led me to discover this problem, I also noticed things were scrolling down, they just started scrolling down in a wrong/glitched way.
Finally, if this is correct and I'm just misinterpreting the GIFs I'm seeing, then how can I get a cast that has many rows of output to display with only 25 rows? Or is this not in asciicast2gif's functionality?
Let me know what you find.
Closing as asciicast2gif is dead. Try https://github.com/asciinema/agg instead.