Closed Arcus92 closed 1 month ago
Can you try also the following?
Please bear with me since this is a quick glance into the code and I might be missing a seemingly obvious point.
@ferferga Thank you very much for your suggestions. I appreciate your support, but please don't feel forced to work on this project. Anyway, the current performance is not bad at all. I'm currently optimizing milliseconds.
The latest commit allows the render to partial consume the pgs steam. It can render all completed subtitles downloaded to this point. Even if the subtitle file is large and takes some time, you will be able to see the early subtitles already. I guess this addresses the most critical issue.
Precompute subtitles a few or 5 seconds ahead.
Yes, that's a topic still on my list.
Separate offscreencanvas worker to another worker.
Moving image data between workers creates a large memory allocations. Not sure if these are worth the few milliseconds building the subtitle. This is properly addressed by preparing the image data for the next subtitles in advanced.
Wrap renderAtIndex in an animation frame
I added this. Couldn't measure any difference so far, but I'll keep it in.
Is necessary to find the target window in every loop? See https://github.com/Arcus92/libpgs-js/blob/main/src/pgsRendererInternal.ts#L145 Is this special handling of the window target necessary?
A window
is just a screen position for the subtitle graphic. In theory you can render multiple images on one frame and therefore the can be multiple windows. The composition specifies the target position by the windowId
. This is very rarely used. Most of the time you have one composition and one window, so the loop is run just once. Also this is called once per subtitle frame.
Some changes to improve rendering performance:
clearRect
. This really improves clear performance in Firefox.