Skip to content
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

Post 742 (color!) followups #749

Open
9 tasks
waywardmonkeys opened this issue Nov 28, 2024 · 0 comments
Open
9 tasks

Post 742 (color!) followups #749

waywardmonkeys opened this issue Nov 28, 2024 · 0 comments

Comments

@waywardmonkeys
Copy link
Contributor

waywardmonkeys commented Nov 28, 2024

Once #742 lands, there some stuff that we should fix up and improve and I don't want to keep expanding the scope of #742:

  • Remove ColorF64: A first pass wouldn't use the good gradient interpolation yet, just use DynamicColor instead.
    This is complicated by the fact that gradients and non-gradient color data are being written in different byte orders.
  • Actually do gradients.
  • Use a consistent byte order for color data being sent to the GPU?
  • vello_encoding::RenderConfig::new doesn't need to take a reference to the base color, nor does it have to use peniko::Color.
    Instead, it can perhaps use impl Into<DrawColor> and simplify calling code as that allows a variety of color types to be used.
    This would probably not change a lot though since we don't want to use DrawColor in RenderParams from the main vello crate.
  • Switch more example code from using Color::from_* or Color::new to using colors from color::palette::css where the actual color doesn't really matter.
    Notably, some of the examples should be able to entirely stop using peniko::Color.
  • pico_svg's parse_color has some fallback for rgb(...) syntax that is probably not needed anymore.
    pico_svg: Simplify color parsing. #753
  • Consider changing some to_u32 methods in color to be to_be_u32 and to_le_u32 or some other naming and making it more clear up through the stack.
  • DrawColor has an comment about the endianness, so when fixing things above, make sure that this is corrected.
  • Why does the blurred rounded rect code only support a color as a brush and not impl Into<BrushRef<'b>>?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant