Add the code for vello_cpu

[LaurenzV]

Doesn't include the tests yet which will come after this PR. But I verified that the tests pass using this setup.

[DJMcNab]

(the tests are excluded at my request, because we need to make sure that the LFS settings are all done properly)

[tomcur]

This looks good. I put some thoughts inline.

The RenderContext should probably change to having a transform stack (and in the future a clip stack as well), allowing somewhat more efficient pushing and popping of layers, but that's not a blocker for this PR. See e.g. this comment:

The initial API should not be trait based. Like Bintje, I have code in a private branch that stores the transform stack so that is part of the intent of the design. (the code I have is for a tiny-skia backend; I don't think I've published this anywhere. Taking a quick look at the code from Bintje, the logic is similar enough there's not a lot of value in mine). And yes, let's have a separate issue for the medium to longer term API considerations.

As a general note, my preference would be to move away from encoding things in the pipeline as u8 and u32, unless there's a strong reason for doing that. Alpha masks could be encoded as Vec<u8> (being generic over tile height almost for free), and e.g. pixmaps could be Vec<PremulRgba8>. When interfacing with a GPU we can bytemuck and also ensure endianness is correct at that interface boundary.

[LaurenzV]

The RenderContext should probably change to having a transform stack (and in the future a clip stack as well), allowing somewhat more efficient pushing and popping of layers, but that's not a blocker for this PR.

Yeah, that makes sense!

As a general note, my preference would be to move away from encoding things in the pipeline as u8 and u32, unless there's a strong reason for doing that.

Yes, we definitely have to address that once we want to support f32-based rendering, though as mentioned before I would leave that for once the basic structure is set up.

[raphlinus]

Generally looks good, and think in generally we should land things early and then iterate.

I agree with Tom that more precise types for things (colors, chunks of alpha values). Part of the reason why the prototypes use primitive types is bad habits from GPU land. But Tom's suggestion is valid: on the Rust side we should use good types, then depend on bytemuck to bit-reinterpret the types to u32 etc.