Fix typos.

This commit is contained in:
Bruce Mitchener 2024-02-09 16:43:12 +07:00
parent 944ce63d8f
commit 433fb9d3ca
5 changed files with 6 additions and 6 deletions

View File

@ -42,7 +42,7 @@ In the previous encoding, every path segment was encoded independently; the segm
This encoding fixes that. Bit 2 of the tag byte indicates whether the segment is the last one in the subpath. If it is set, then the size encompasses all the points in the segment. If not, then it is short one, which leaves the offset for the next segment pointing at the last point in this one.
There is a relatively straightforward state maching to convert the usual moveto/lineto representation to this one. In short, the point for the moveto is encoded, a moveto or closepath sets the end bit for the previously encoded segment (if any), and the end bit is also set for the last segment in the path. Certain cases, such as a lone moveto, must be avoided.
There is a relatively straightforward state machine to convert the usual moveto/lineto representation to this one. In short, the point for the moveto is encoded, a moveto or closepath sets the end bit for the previously encoded segment (if any), and the end bit is also set for the last segment in the path. Certain cases, such as a lone moveto, must be avoided.
### Bit magic

View File

@ -20,7 +20,7 @@ This roadmap is in roughly chronological in order of when we expect to complete
In addition, there are a few optional aspects to the roadmap, which will be implemented if there is demand from users or motivation from contributors:
* Native renderering back-ends, to reduce the overhead of WebGPU, especially runtime shader compilation.
* Native rendering back-ends, to reduce the overhead of WebGPU, especially runtime shader compilation.
* A solution to conflation artifacts, to improve rendering quality for some classes of vector art.
* Subpixel RGB rendering, to improve rendering quality on low-dpi LCD screens.
* High Dynamic Range (HDR) rendering, to exploit capabilities of new displays.
@ -111,7 +111,7 @@ Taking that idea to the next step, we can make the scene encoding format part of
Another potential reason to make the encoding part of the interface is so assets can be stored in encoded form, saving the cost of re-encoding. Our vector path encoding is *good,* as it's been carefully designed to minimize both the cost of generating it CPU-side, and consuming it GPU-side. One data point to support that is that our encoding of the 14MB paris-30k SVG file (as included in [Forma]) is about 12MB. And that's with 32 bit coordinates. For pre-encoded assets (or other special cases like font glyphs), it makes sense to use 16 bit coordinates instead, for about a 2x additional saving.
Thus, making the encoding part of the public, documented interface could open up some interesting possibilites. Obviously it's also too early to freeze the format, as we'll want to continue to iterate it to make it more efficient and add more capabilities, but likely a "semi-stable" approach, perhaps versioned stable releases, could work well.
Thus, making the encoding part of the public, documented interface could open up some interesting possibilities. Obviously it's also too early to freeze the format, as we'll want to continue to iterate it to make it more efficient and add more capabilities, but likely a "semi-stable" approach, perhaps versioned stable releases, could work well.
With [vello#239] we already expose a good chunk of the encoding, and encourage people to experiment with that as we decide what to stabilize and how.

View File

@ -69,7 +69,7 @@ pub struct Arguments {
#[arg(help_heading = "Render Parameters")]
#[arg(long, global(false), value_parser = parse_color)]
/// The base color applied as the blend background to the rasterizer.
/// Format is CSS style hexidecimal (#RGB, #RGBA, #RRGGBB, #RRGGBBAA) or
/// Format is CSS style hexadecimal (#RGB, #RGBA, #RRGGBB, #RRGGBBAA) or
/// an SVG color name such as "aliceblue"
pub base_color: Option<Color>,
#[clap(subcommand)]

View File

@ -107,7 +107,7 @@ struct MainPassCube;
pub struct VelloTarget(Handle<Image>);
#[derive(Component)]
// In the future, this will probably connect to the bevy heirarchy with an Affine component
// In the future, this will probably connect to the bevy hierarchy with an Affine component
pub struct VelloFragment(SceneFragment);
#[derive(Component)]

View File

@ -88,7 +88,7 @@ impl<'a> SceneBuilder<'a> {
Self { scene }
}
/// Pushes a new layer bound by the specifed shape and composed with
/// Pushes a new layer bound by the specified shape and composed with
/// previous layers using the specified blend mode.
pub fn push_layer(
&mut self,