Canvas should support the alpha channel.

• outline_rect(x, y, w, h, color)
• outline_circle(x, y, r, color)
• thick_outline_rect(x, y, w, h, thickness, color)
• thick_hline(y, x1, x2, thickness, color)
• thick_vline(x, y1, y2, thickness, color)
• outline_ellipse(x, y, a, b, color)
  This list will expand

It is difficult to test rasterizing methods, since it's difficult to tell if rendering is valid or not.

One method would be to generate test images with an external app. This may be more problematic than what it's worth, because there can be slight differences in how the external app renders a shape vs how we render one. Slight differences does not invalidate our results, since there are many algorithms the one can use to render a certain shape. Implementation details can also change a few pixels (truncation, rounding and casting errors, accumulation of small inaccuracies)...

An other method is to simply generate our own test images and test against them when we make a change. This method is used by the olive.c project.

Writing a ppm file is currently painfully slow. An obvious improvement on the user-side is to use a BufWriter, but even then saving an image feels really sluggish.

The main problem is the sheer number of individual writes (this is why using a BufWriter helps a ton).
The data needs to be written to the writer at once (or in larger chunks). The easiest way to do this is preparing the data in ram before writing.

Unit tests should be written where we mainly test for whether a method panics or not.
Since most of methods/functions implemented does not return anything we cannot test their validity.

In a following issue I'll contemplate the idea of implement a kind of testing that olive.c has.

A higher level helper API that can make code more readable (but a tad less efficient).

By providing types such as Rect, Line, Circle ... that may implement a Draw trait, the users code could be made more readable.

The philosophy behind the methods of Canvas is generality. No Point, Vec, ... structs nor the use of tuples, just plain values.
This can be great, because these values can come from anywhere.

For example:

use vason::{Canvas, Color};

// User's own struct or one from an other lib
struct Point {
  x: i32,
  y: i32,
}

fn main() {
  let mut buffer = vec![0u32; 256*256];
  let mut canvas = Canvas::new(&mut buffer, 256, 256);

  let p1 = Point {x: 10, y: 23 };
  let p2 = Point {x: 102, y: 78 };
  let p3 = Point {x: 16, y: 53 };

  canvas.thick_outline_triangle(p1.x, p1.y, p2.x, p2.y, p3.x, p3.y, 5, Color::BLUE);
  ...
}

As you can see, the canvas's method can be called without transforming the data. (You just need to "explode" it)

But let's consider an other case:

use vason::{Canvas, Color};

fn main() {
  let mut buffer = vec![0u32; 256*256];
  let mut canvas = Canvas::new(&mut buffer, 256, 256);

  canvas.thick_outline_triangle(10, 23, 102, 78, 16, 53, 5, Color::BLUE);
  ...
}

In cases like these (especially if you write a lot more of these lines) it can be hard to tell which number represents what.

Descriptor API

With the descriptor API we could make code more readable, when the user doesn't need to interact with foreign types too uch, and when the performance impact does not matter as much.

use vason::{Canvas, Color, descriptor::Triangle};

fn main() {
  let mut buffer = vec![0u32; 256*256];
  let mut canvas = Canvas::new(&mut buffer, 256, 256);

  let tri = Triangle {
    p1: (10, 23),
    p2: (102, 78),
    p3: (16, 53).
    thickness: Some(5),
    color: Color::BLUE,
  }

// Maxbe with a builder-api
let tri = Triangle::new( (10, 23), (102, 78), (16, 53) ).with_thickness(5).with_color(Color::BLUE);

 canvas.draw(&tri);
 // Or
 tri.draw_to(&mut canvas);
  ...
}

This API besides making the code more readable also serves as an abstraction over the numerous method variants of canvas (fill_, outline_, thick_, thick_outline_).

This API could also motivate the canvas methods to be even more specialized thus more performant.
The user could have a lower and also a higher level access to the library's features.

• fill_triangle(x1, y1, x2, y1, x3, y3, color)
• thick_line(x1, y1, x2, y2, thickness, color)
• fill_rotated_rect(???)

Canvas should provide at least the following methods:

• fill_rectangle(x, y, w, h, color)
• fill_circle(x, y, r, color)
• line(x1, y1, x2, y2, color)

This list will be expanded later

Coordinates should be represented with i32, sizes with u32 i32 as well and colors with generic types that implement Into<Color>.

I've been editing this issue a lot. (why comment? I'm alone...) Trying to come up with a simple way to represent coordinates and sizes.

First, I though it would be nice to use signed types for coordinates and unsigned ones for sizes. It makes sense after all. The problem is with the implementation. It's really janky full of type conversions and thus warnings. The more intuitive and "proper" (with regards to parameter types) the API is, the more janky is the implementation.

The default behavior of drawing methods in case of invalid argument is not drawing anything (or not drawing a specific part of the shape). This makes total sense, so it is way easier to expand upon these cases rather than to restrict the API and do a messy implementation.

The crate should provide better, clearer and more impressive examples.

I'd like to introduce a Logo-like "turtle geometry" API to the library.

This would be kind of an unique way to use the library in contrast with other similar rasterizers. It could possibly make for a more fun experience.
After all, this entire project is just for fun...

Let this API be known as the pen API.

As the feature set grows, I'm thinking about splitting this crate into multiple features.

Features:

• Pen-API
• Descriptor-API
• PPM

This would be due by the time the Descriptor-API is ready.

Add color formats to play nicely with various buffers .
Color formats must be still representable with u32's

Methods, functions and types should be properly documented.