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

investigate offscreen canvas usage #4741

Open
jerch opened this issue Aug 31, 2023 · 4 comments
Open

investigate offscreen canvas usage #4741

jerch opened this issue Aug 31, 2023 · 4 comments
Labels
area/addon/canvas area/addon/image type/enhancement Features or improvements to existing features

Comments

@jerch
Copy link
Member

jerch commented Aug 31, 2023

Safari finally added offscreen canvas support in v16.4 (released around April 23), at least with bitmaprenderer and 2D context support.

It might be worth to check, if we can free some mainthread cycles by using offscreen canvas in the canvas renderer and in the image addon. The webgl renderer is prolly not worth it (not high in the CPU books, also not yet supported by Safari).

@jerch jerch added type/enhancement Features or improvements to existing features area/addon/canvas area/addon/image labels Aug 31, 2023
@Tyriar
Copy link
Member

Tyriar commented Aug 31, 2023

Related: #1515

If I remember right the thinking here was it would be better to move the parsing out to a worker and share memory, rather than the renderer as it's already just a small part of the work.

The webgl renderer is prolly not worth it

I treat webgl as the ideal case, so if that's fast it's not worth trying to move the canvas renderer over. Also I'd still like to remove the canvas renderer, the only reason it wasn't cut before was because iOS needed it to avoid falling back to DOM. This is less and less relevant as time goes on as the DOM renderer is much faster and Safari decided to add webgl2 support.

@Tyriar
Copy link
Member

Tyriar commented Aug 31, 2023

Asking a worker to draw glyphs may be a useful way to offload work.

@jerch
Copy link
Member Author

jerch commented Aug 31, 2023

Also I'd still like to remove the canvas renderer, the only reason it wasn't cut before was because iOS needed it to avoid falling back to DOM.

I kinda thought the same during the DOM renderer revamping. The canvas renderer is actually now the slowest on my system for typical terminal content (well the DOM renderer still degrades in perf rather quick for lots of styling due to span element "pressure"...). Imho

If I remember right the thinking here was it would be better to move the parsing out to a worker and share memory, rather than the renderer as it's already just a small part of the work.

Indeed getting the parser off the mainthread would show a much bigger impact, hmm. Well that prolly needs some careful module/code design to get properly done (like splitting addons into parser/buffer/worker and frontend/renderer/DOM-related parts) 😅

@Tyriar
Copy link
Member

Tyriar commented Aug 31, 2023

Alternatively run everything in a worker with offscreen canvas, that wouldn't work with switching back to dom though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/addon/canvas area/addon/image type/enhancement Features or improvements to existing features
Projects
None yet
Development

No branches or pull requests

2 participants