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

Caching ShapePlan and the Wasm Module/Linker #9

Open
asibahi opened this issue Jul 28, 2024 · 1 comment
Open

Caching ShapePlan and the Wasm Module/Linker #9

asibahi opened this issue Jul 28, 2024 · 1 comment

Comments

@asibahi
Copy link
Contributor

asibahi commented Jul 28, 2024

Hello.

One of the improvement paths for ruatybuzz is to figure out how to cache the shape plan so it is used between calls.

Ive been reflecting on this and the way I think it makes sense is to somehow embed it into the Font (or Face) object. However, plans as far as I can tell are not unique per font, for example if you want to have different runs with different features turned on (including variable axis) , each feature set would require its own plan.

The other thing is the Linker/Module of the wasm shaper. I tried caching the Linker somehow, where I tried to embed it into the ShapePlan, as it were, but I ran into a lot of circular references, as the Store type is generic over an inner type which does include the Plan and the Font. Context here.

Caching the wasm module and linker would be necessary if one were to use the module for more than the shape function. For example shape_justify`

I do not think this (either caching) can be done without some architectural changes to the API and structure of the code. Are references allowed to be 'static ? Or should everything be embedded into the Font somehow? And if they're embedded in the font how is the circular reference solved in the wasm linker?

@dfrg
Copy link
Collaborator

dfrg commented Jul 28, 2024

We will definitely be making significant changes to the font representation and I have some ideas but haven’t fleshed them out yet.

Most notably, I want to disentangle the allocations of cached state from the font data lifetime. In skrifa, we just keep font data separate from cached state (see our FontRef and HintingInstance types) and leave it to the user to keep them in sync. I imagine we’ll do something similar here as we expect these libraries to be used together and using the same patterns makes sense.

I don’t know exactly what this means for shape plans and wasm. The main goal is to keep most of these types immutable so that they’re usable in multithreaded contexts without synchronization. Maybe we can also provide an “easy mode” API that handles caching and synchronization for you but my preference is for that not to be the only API.

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

No branches or pull requests

2 participants