The simplest low-level CPU rasterization library

[dayllenger]

UPD: my implementation is here with some usage demo.

[p0nce]

• ae-graphics have 1px line but they are not that useful, I would have thought a line to be better expressed through a rasterized trapezoid. In particular primitives with int coordinates are not very useful at all imho.
• font glyphs are rendered using bezier curves directly, not through triangulation. How to account for those?

[dayllenger]

1. thin lines occur quite often, they are simpler to specify (imagine a nearly horizontal line, how to make trapezoids for it?) and the simple Wu's algorithm should be faster.
2. This is much more complex, I don't know if we need to reinvent the wheel in this area and go without freetype or stb_truetype. I don't think contours and winding numbers should be covered by this lib.

[rikkimax]

Splines should be mentioned.

I don't think that these more complex lines can be flattened out without causing problems (cpu usage / lines instead of pixels) outside the pipeline.

Also draw pixel too.

One thing to note is that the plot function is meant to be hidden from the user. If its on the cpu you would probably give it a an ImageBuffer, if its on GPU you may expect it to return a texture id or something as far as my understanding is concerned.

[dayllenger]

If we put splines there, we'll need to consider caps, joins, dashes, basically put the entire stroke renderer. Maybe it should be done, if an external impl outputs too many trapezoids.

Pixel drawing is literally the plot function. Plot function is chosen by someone who knows the format of the surface and the brush type (gradient, pattern, etc.).
It is not for GPU, it is just several simple CPU procedures.

[GooberMan]

Can we stop making claims that drawing graphics is not for the GPU?

If you're mixing CPU and GPU rendering in runtime code, you'll absolutely tank mobile performance right now. Any code where the CPU is pushing pixels is not future-proof.

CPU rendering should only be considered as one thing: a reference implementation. Rendering on hardware without GPU will likely require a specialised implementation of any API anyway.

(You can probably see where my comments are going to go in the future on this topic...)

[GooberMan]

As for a comment on the API, if this is going to be in D then it should be far more towards current D idioms. ie:

Line( BeginPoint, EndPoint ).Plot!Basic;
Line( BeginPoint, EndPoint ).Plot!AntiAliased;

[dayllenger]

Can we stop making claims that drawing graphics is not for the GPU?

I'm saying that this particular lib renders on CPU, that's it.

mixing CPU and GPU rendering in runtime code

I am not, this code is only for CPU backend.

CPU rendering should only be considered as one thing: a reference implementation

And as a fallback, when no GPU is available.

Line( BeginPoint, EndPoint ).Plot!Basic;

My idea is that you pass some geometry to a function, and it invokes a callback. Caller should set pixels in this callback in a way he wants. Why do we need something over free functions in such low-level API?