Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Updating the SKFont members #1101
So far, the
Previously it was all arrays and allocations. I am now trying to have the option to use arrays if need be, but more provide the option to have zero-allocation code.
Looks very promising. I think we should use SKFont in combination with SKTextBlobBuilder from the beginning to make sure both work well with each other and are easy to use.
Passing a string to SKFont to get corresponding glyphs always needs to allocate. Being in control of the allocation is always a good option.
Sometimes users just want the data and don't want to deal with creating buffers and sometimes reusing a buffer is the best perfoming option. Not easy to design an API around these requirements.
Will add more comments in a bit.
Your overloads let you pass a pre-allocated buffer and also provide a way to let SkiaSharp allocate everything for you. All variants cover most possible scenarios.
In general, if SkiaSharp allocates it should return an array if the consumer of the API allocates a buffer the parameter should be of type Span.
So I think we agree here.
In general, we will not work with these methods directly and instead
Both need to have some font fallback to produce desired results.
After the mapping step, we have to look for unmapped characters and match a fallback font for each range that wasn't mapped. Each sequence of mapped character is added to a SKTextBlobBuilder. The build SKTextBlob is then used to draw the glyphs.
SKTextBlobBuilder should be used to allocate the buffer it will allocate anyways so we should reuse this buffer.