You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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
(orFace
) 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 theStore
type is generic over an inner type which does include the Plan and theFont
. 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 exampleshape_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?The text was updated successfully, but these errors were encountered: