Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance improvements #9

Merged
merged 7 commits into from
Jul 15, 2024
Merged

Performance improvements #9

merged 7 commits into from
Jul 15, 2024

Conversation

Arcus92
Copy link
Owner

@Arcus92 Arcus92 commented Jul 9, 2024

Some changes to improve rendering performance:

  • Only clearing the dirty area with clearRect. This really improves clear performance in Firefox.
  • Faster run-length-encoding by removing callbacks. This doubled the performance from ~5ms to ~2ms per subtitle.
  • Storing rgba values as UInt32 buffer instead of objects.
  • Partial pgs stream encoding while downloading. Early subtitles can already be rendered while the rest of the file is still downloading.

- Avoid using slow callbacks
- Copy and storing the rgba value as one 32bit value instead of four single bytes.
- Store rgba data in one buffer and not objects
@Arcus92 Arcus92 self-assigned this Jul 9, 2024
@Arcus92 Arcus92 mentioned this pull request Jul 9, 2024
@ferferga
Copy link

ferferga commented Jul 9, 2024

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.

… subtitle stream while it's still downloading. All display sets in the completed download range can already be rendered and don't have to wait until the whole file is completed.
@Arcus92
Copy link
Owner Author

Arcus92 commented Jul 11, 2024

@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.

@Arcus92 Arcus92 marked this pull request as ready for review July 15, 2024 16:10
@Arcus92 Arcus92 merged commit 4f342ba into main Jul 15, 2024
1 check passed
@Arcus92 Arcus92 changed the title Performance improvments Performance improvements Jul 15, 2024
@Arcus92 Arcus92 deleted the performance branch November 3, 2024 10:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants