\fry strange random behavior

[SSgumS]

Hello

I tested this situation on mpv and aegisub. Both had the issue. So I thought maybe it's from libass itself.

As we can see in the video, the drawing with \fry disappears suddenly. I should mention that this is not consistent between different \fry. With \fry 29 it's ok but when I set it to 30 or 60, it breaks.

In mpv:
https://user-images.githubusercontent.com/25867589/122224932-d3acd600-cec9-11eb-872b-0df9d1ca4a9d.mp4

In Aegisub:

Subtitle file used:
fry.zip

[astiob]

@MrSmile Remember this? Looks like it’s not working too well. :(

[astiob]

Found the better link: #285 (comment)

[astiob]

@SSgumS If you want your rotation to actually look right—and this affects VSFilter, too—you need to make the yellow rectangle smaller. When you rotate it beyond about 29.5°, its left edge gets too close to the camera, so both VSFilter and libass start to distort it. As you can see, libass may even drop it entirely when it gets too large, or when it does show it, e. g. for \fry between 61.2 and 74.5, it takes multiple seconds for every single frame to rasterize it. But again, even ignoring performance and disappearance issues, it simply looks wrong in both VSFilter and libass:

At 65° in current libass, the vertical intersection is not the full height of the red rectangle.

At 65° in VSFilter, the vertical intersection is above the red rectangle.

Generally, at such extreme \fry rotations, the source coordinates of the points that rotate towards the camera should be at most −296.875 relative to the \org point. (In your example, the x coordinate is −600, i. e. half of the 1200 width, as the rectangle is centre-aligned.)

[MrSmile]

This is really a problematic case as it can lead to overlarge bitmaps. I think it's better to not render it at all than to freeze.
I'm planning to implement screen clipping someday, that should solve similar cases for good.

Also for such cases to look right we should implement rational spline rendering (but it would be incompatible with VSFIlter).