Skip to content
New issue

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

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

Already on GitHub? # to your account

Estimate Text Layout using an OffscreenCanvas #664

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jwagner
Copy link

@jwagner jwagner commented Dec 19, 2024

I tried to use plotters in a web worker and ran into a panic in estimate_layout. The reason is fairly obvious, there is no window or document inside of a worker context.

To get plotters to work inside of a web worker I hacked up some code to measure the text size using an OffscreenCanvas.

There are some benefits and drawbacks to this.

I think it should be more resilient than creating a span in the dom and measuring offsetWidth/Height because it is not affected by CSS.

It should be more performant than adding a dom node and measuring the offset properties which cause layout reflows. This is just an educated guess. Didn't benchmark it - takes this claim with a pinch of salt.

I think the main drawback is compatibility. While it is considered to be baseline now, browser support isn't ideal.

There are several ways I see forward. This approach could be used as a fallback when window isn't available or visa versa.

I think it's also an option to just fall back to a really crude approximation along the lines of height = size, width = size * text.len().

Anyway would be glad to get some feedback on this from the maintainers.

@jwagner jwagner force-pushed the estimate-layout-offscreen branch from 243a1e6 to 52ce834 Compare December 19, 2024 11:04
@AaronErhardt
Copy link
Member

Sounds reasonable to me, but I'm not proficient enough to tell which approach is preferable. In the end, both solution seem like a hack to me, and the question is which hack has the better trade-offs. I'd like to hear another opinion on this matter, but unfortunately I'm the only somewhat active maintainer currently.

@jwagner
Copy link
Author

jwagner commented Dec 30, 2024

Thanks a lot for getting back to me and keeping the project afloat @AaronErhardt.

If browser compatibility is the main concern I could also just add a fallback to a regular (non-offscreen) canvas. That way there is (essentially) only one code path and the dom hackery can go. Canvas is supported in practically every browser that supports wasm.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants