Not a bug, just wanted to pass on the typesetting that someone reported that they had trouble playing in real time
This type of script is an example of worse-case for xy-VSFilter, since the font has an extremely complex outline
and GDI becomes bottlenecked.
Unfortunately Windows is not open source
, so this cannot be easily optimized as long we use built-in font handling.
On the original script we are ~3x faster than regular VSFilter, but because of the font used, Libass ends up 2x faster than xy-VSFilter:
Core i5-3570K @4.4Ghz
Libass: 110 fps avg | ??fps min
xy-VSFilter: 65fps avg | 30fps min
VSFilter: 24fps avg | 10fps min
Replace with a lightweight font like Arial in the script and everything changes. We maintain a ~3x faster lead over regular VSFilter, but now xy-VSFilter has a ~10% lead over Libass as well.
Core i5-3570K @4.4Ghz with font changed to Arial
xy-VSFilter: 170fps avg | 85fps min
Libass: 155 fps avg | ??fps min
VSFilter: 65fps avg | 30fps min
Hint: The more complex and numerous the holes, gaps, or notches in a font outline, the slower it will render.
Examples:      
Only with static typesetting performance will be acceptable for such fonts using xy-VSFilter (along a pre-buffering video renderer like EVR-CP or madVR).
I hope script authors will learn to avoid these and similar overly complex fonts when softsubbing multiple lines of motion tracked typesetting or complex karaoke.