Closed LaurenzV closed 4 months ago
[gsubgpos] Optimize set-digest initialization | im not sure about these, but as far as I can tell we don't have anything related to digest, right? Is this only necessary for the whole accelerators story?
Yes, we do not have hb_set_digest_t
. Don't remember why.
[gsubgpos] Skippy-iter: Prefer correctness to performance | I did translate those, but I'm not sure if the casting is optimal, would like to get some feedback on that
Not gonna lie, as long as tests are passing - I'm fine with it.
[COLR] Apply variations in get_extent | from what I can tell harfbuzz always floors in this case? should we do the same or just use the round function as I did?
We cannot floor/ceil/round in ttf-parser because of no_std
. So as long as it doesn't affect tests - it's fine.
Afaik we have a couple of "failing" tests already due to different rounding. This is sort of inevitable. Float precision is as an implementation detail.
Okay! Then I guess this should be it (unless I should change the 1 - 1 thing)!
Looking at the commit history it seems like a lot of future commits are about "irrelevant" stuff (e.g. WASM API and the draw API), so I'm optimistic, but I don't want to jinx it either.
[gsubgpos] Optimize set-digest initialization | im not sure about these, but as far as I can tell we don't have anything related to digest, right? Is this only necessary for the whole accelerators story?
Yes, we do not have
hb_set_digest_t
. Don't remember why.
That object is worth porting, since it's a major optimization. It's not too much effort.
That object is worth porting, since it's a major optimization. It's not too much effort.
How about I open an issue for it, so we don't forget about it? The thing is that right now I think the main priority (at least for me) is to get the current code and logic we have synced up with the newest harfbuzz, because what matters most for rustybuzz is correctness. Once we are synced up, we can always work on porting the other optimizations / missing features to rustybuzz, right? 😄
But I will let @RazrFalcon decide.
That object is worth porting, since it's a major optimization. It's not too much effort.
How about I open an issue for it, so we don't forget about it? The thing is that right now I think the main priority (at least for me) is to get the current code and logic we have synced up with the newest harfbuzz, because what matters most for rustybuzz is correctness. Once we are synced up, we can always work on porting the other optimizations / missing features to rustybuzz, right? 😄
Sounds good to me. I might even work on it as a way to find my way around Rust!
I do not mind adding hb_set_digest_t
, as long as someone is willing to implement it.
@LaurenzV Did you figure out the COLRv1 clipping thing?
Yeah, I just forgot that the test font doesn't contain any actual emojis but only other Unicode codepoints. 😅 It works as expected with the right input.
Luckily for us, lots of commits that don't apply to us! But a couple of things I wasn't 100% sure about, again: