-
Notifications
You must be signed in to change notification settings - Fork 27
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
[skrifa] floating point COLR #697
Conversation
Internal interface for color outline loading in full floating point.
Thanks for this - the fact that FreeType returns rounded values is the bug in FreeType at the moment that @tursunova is in the process of fixing - so it's a bit hard to tell how war the fixed computation would be off. I am a bit concerned about the code duplication - if it's COLR related, could we perhaps shift read_fonts to do this in floats right away? I don't think we have a huge legacy there from FreeType (rather, we have bugs that we need to fix, like https://bugs.chromium.org/p/chromium/issues/detail?id=1473020 |
I am also curious to see how the issue will be resolved in FreeType and how big the diffs might be. re duplication: if we go this route, my intent was to just remove this functionality from read-fonts. I think your new |
- remove fixed point ColrInstance code from read-fonts - remove color paint debug printing module from skrifa
skrifa/src/scale/colr/instance.rs
Outdated
@@ -0,0 +1,653 @@ | |||
//! COLR table instance. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about putting this in skrifa/src/colr/instance.rs
? Or skrifa/src/color/instance.rs
- My thinking is: We're not really scaling here, mostly applying variations. And then ColorPainter
can go in the same directory when it is ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems reasonable but the details are a bit tricky. I’m thinking forward to adding bounding box computation which will require the scaling code. As of now, the “metadata level” types don’t have any dependencies on the scale module and I find that to be a clean separation. I suppose we can maintain that by just taking a closure for computing per glyph bounding boxes. Let me put together a quick proposal for this API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just arrived at the same question - when looking at bounding box computation. Taking transforms into account we'd arrive at implementing a full matrix transform library - which we already have in Skia. So I don't think we need to necessarily replicate that now. My approach now is a basic BoundsPainter
that does mostly nothing for the fills, just keeps track of a matrix, and retrieves the tight contours of path along the way. The ingredients already exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#702 is a proposal for this that tries to fit it into the current design for metadata access. I see your point about the matrix library, but it seems like ColorPainter
needs the struct regardless as a parameter for transform callbacks. I believe your code already has the constructors for translate/rotate/skew, so we'd really only need to add mat * mat
and mat * point
operators to make this work.
skrifa/src/scale/colr/instance.rs
Outdated
} | ||
|
||
#[derive(Copy, Clone)] | ||
enum DeltaTy { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does Ty
mean Type? Is that a convention we're using. Can we spell it out? DeltaType
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, yes. Since type
is a reserved word in rust, this is fairly idiomatic and I follow it by habit but I’m happy to spell it out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
skrifa/src/scale/colr/mod.rs
Outdated
@@ -0,0 +1,6 @@ | |||
mod instance; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In line with the comment above, move this to src/colr/mod.rs
?
/// | ||
/// This requires a type parameter specifying the type of target value for the | ||
/// delta. | ||
pub fn compute_delta_f32<T: ItemDeltaTarget>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to add some standalone file level tests for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have a reference for correctness here so I added a sanity test to ensure that the floating point results are within a reasonable margin to the delta produced by the FT compatible computation. Specifically, it ensures that either the rounded or truncated floating point delta matches the FT compatible delta. We have to account for both because fractional accumulation can push us to either side of the 0.5 boundary in some cases.
- renamed DeltaTy -> DeltaType - add sanity test for floating point delta computation
Expose a color outline API in top level metadata rather than in the scale module.
- add version() method to ColorOutline - remove maxp lookup and change iterator to use max glyph in COLR table - remove glyph_id from ColorOutline and change iterator to return (GlyphId, ColorOutline) tuple
As requested, this is the floating point refactor extracted from #697. * add methods to IVS to compute scalars/deltas in f32. * move `ColrInstance` from read-fonts to a private module in skrifa and update it to produce results in f32.
Can we close this, is this superseded by #725? |
Yep! |
Internal interface for color outline loading in full floating point.
This copies
ColrInstance
& co from read-fonts to skrifa and updates it to process all values/deltas in floating point. Additionally, adds methods toItemVariationStore
to compute scalars/deltas in floating point. It's f32 all the way down.This doesn't remove the code in read-fonts and also contains a module for printing the paint graph so it's not ready to merge.
Printing the graph for a glyph:
For the COLRv1 test font, glyph 94 (radial_horizontal_gradient_extend_mode_pad) with all coords set to -0.6021 loads as follows with skrifa maintaining fractional values from deltas:
freetype:
skrifa: