alexandruica / verg Goto Github PK

An enum that would probably contain options for:

• RGBA
• RGB
• CMYK
  We should also provide some options regarding the color space, so possibly another enum for:
• Gamma(value)
• Possibly others (not a high priority)

Currently a Shape is a Vec<Primitive>, and it's not ideal. We should make an API that kind of looks like turtle:

Shape {
    start: (0, 0),
    data: vec![
        LineTo{ 120, 350 },
        QuadraticTo { ... },
    ],
}

Path drawing operations and gradients should take an additional matrix that describes affine transformations (like rotation, scaling and translation).

It would be a good idea to refactor some stuff, mainly:

• Provide a few default colors in color.rs (for a start, the ones used in the integration tests should be enough)
• Remove unused stuff in geometry.rs. Since I've changed the drawing algorithm for rendering lines, a lot of stuff in geometry.rs is left there unused, all of that should be removed
• In canvas.rs there are a lot of functions that are unused: remove them. Also, draw_shape is a bit of a mess, it would probably a good idea to separate the code for rendering lines and the code for filling

What we should do instead is just store the maximum number of channels (4) and let the user decide what he wants. That means offering conversions.

Start by describing the line rendering algorithm, and how the library functions as a whole.

Implement the algorithm behind AGG. At first it doesn't have to be fancy, just render lines. For correct rendering, I should probably consider color spaces and alpha compositing right from the start

Blocked by:

• #5
• #4

This could be added as a simple post-processing effect callback that takes pixels as input. That would allow a custom processing effect really easily. All calculations of colors (for example: gradients) will be done in linear space, only when saving the image will this callback be applied.

Currently the tests are only run, they are not "checked" for validity automatically. I'd want to run SHA-1 (or something like it) on the resulting image of every test and save it. After that, every test would check its hash against the saved one, checking if it's the same. This way I can track changes in the library that affect rendering.

Practice writing them in Haskell to have a clearer view. Haskell implementations should be clear enough to borrow from for the Rust version.

Currently the third term in the Cubic Bezier curve expansion is not computed correctly (should be t * t not t * 2.0.

At first just focus on getting the title page right, setting up language-specific stuff, setting up code showing for rust, setting up the bibliography etc.

Currently the alpha blending method is hardcoded to 1 - src.alpha, it would be great if the library would provide a few blending functions (like the Porter-Duff ones), and allow for a custom blending function as well.

See if it's even possible considering the line drawing API that we have.

We should test more thoroughly. We should probably add tests with more complex polygons:

• A hexagon at the very least
• A glass of water with a lemon, something like this one
• A boat, maybe like this one
• Render some glyphs, similar to what I've done here, maybe write verg and possibly use rustybuzz for shaping (unlikely)

Follow the algorithm presented here and render a simple triangle for the start. Maybe add a post-processing ability to take into account color spaces. Ideally we should also take into account alpha compositing but it's ok if it's not fully correct for now.

• #7
• #9
• #10

It should be pretty easy to port what I've done here, since the algorithm powering it is identical to the one used in verg. I could also borrow the glyph renderer and write some tests that use glyphs.

• #18
• #20
• #28
• #24
• #25
• #22
• #11
• #8
• #27
• #26

• Linear gradients
• Radial gradients
• Conic gradients

Pay a bit less attention to details like integer overflow and not allocating at all. It's not that they aren't useful, but it would take a lot more time than I would want to if I want to take everything into consideration.

• Make a main branch which will be the branch where all changes will be progressively merged into
• Document the commit structure(maybe even provide a sample hook that checks commit formatting), PR/issue templates, branch naming, git workflow
• Set up rust with cargo
• Set up actions for automatic checking of formatting, running clippy, code coverage, running tests
• Set up documentation generation

Currently, in intersect_line_with_grid() we create new Vecs on_horizontals and on_verticals each time we call the function. That's not needed, we could just reuse a Vec in canvas that grows as it's needed (or, of course, we could give it a big capacity from the beginning and we could avoid reallocating at all!).