[consistent] Some pages not rendering

[1seco]

Platform: macOS 14.7 aarch64

Note: Sorry for the lack of a video, my network has been unfriendly lately.

1. After loading many pages (~50+ ish in my case) a collection of pages from the first page do not render, unless the window is resized or there is some other miscellaneous update to the display.

• The number of pages not rendering seem to be really consistent. ~12 for 50 pages

2. If I go through the pages extremely fast, then after some point, pages no longer render. But after another point, they do render. The solution is exactly the same as 1. This issue usually takes rendering a lot more pages than issue 1.

• I have not measured consistency here

---

Pages Loaded/traversed
0------------------------------------------------------> pg50
[ Empty pages/blank (~12)][       rendering pages        ]

Pages Loaded/traversed
0------------------------------------------------------------------------------------------------------------> pg160
[very few rendering (~3][                      Lots not rendering                     ] [     rendering pages    ]

[itsjunetime]

Yeah, I also notice this every once in a while, but it's not consistent for me, so I haven't been able to pin down what exactly is happening.

Could you share some more details about your environment and how you trigger this? E.g. what terminal are you using, does this only happen on a specific PDF, do you set it to fullscreen or invert, are you pulling from git main, etc? Any information would be appreciated.

As a sidenote, I feel like maybe I should add some logging and make it possible to output logs to a specific file or something like that for these debugging purposes. Maybe I'll make that a priority if this issue proves difficult to debug.

[1seco]

The way I triggered all of this is by literally spamming the left(k) until a certain page number. The speed at which I navigate back to the first few pages doesn't seem to matter. I am using Kitty on macOS. Both fullscreen and half(one page only) can have this issue. The update of window size can fix it though. I am pulling it from git main since there isn't a homebrew package that I can use.

[1seco]

I should be able to make some recordings in a while, about half a day.

[itsjunetime]

Ok, so I've looked into this a bit and I've been able to reproduce it as well. It seems like it may be a kitty-specific problem. I've found that if, in ratatui-image, we re-transmit the image data to the terminal each time we render an image, this problem goes away (but tdf does get much slower). I think this problem also only start popping up once we have a certain number of images rendered, like 40 or so. Maybe The kitty image protocol defines a certain number of image data that's allowed to be kept in memory?

I'm going to read over some more documentation about it today (https://sw.kovidgoyal.net/kitty/graphics-protocol/) and see if I can sus it out.

[itsjunetime]

In order to avoid Denial-of-Service attacks, terminal emulators should have a maximum storage quota for image data. It should allow at least a few full screen images. For example the quota in kitty is 320MB per buffer. When adding a new image, if the total size exceeds the quota, the terminal emulator should delete older images to make space for the new one. In kitty, for animations, the additional frame data is stored on disk and has a separate, larger quota of five times the base quota.

ah, ok. So there is a limit, and it offloads images once you get past that limit (which tdf does quite easily). We can definitely work around this (essentially just implement a slightly lower limit in tdf so we never hit the terminal limit) but it take some time. I took a quick shot at it just now, but tdf (as of right now) isn't good at limiting how much it renders and requesting re-rendering when needed, which gets in the way.

[itsjunetime]

Ok, this should be good now, as of merging #74 . If it is still present, let me know and we can re-examine.