Implement a custom rasterizer instead of using tiny-skia #27
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I think it'll be way more fun to have a custom, very limited rasterizer for brushes, without fancy features like transforms, thick lines, and such. Users should get creative with their use of various render primitives, not have a hefty rendering system that does everything for them.
I'm slowly starting to think this maybe isn't the best idea; I think I'd like to pursue a more composable rendering system (like the current one) and for that using tiny-skia seems like the easier option.
Easier does not certainly mean better though, and tiny-skia does have its deficiencies (it's not very good for rate-limiting like we currently do with fuel in our VM…)
Maybe pursuing GPU-based rasterisation would be a fine idea. We'd have to drop the idea of evaluating the brush on the server, but that's arguably good since it will reduce costs in the long run. The challenge would be how to send a change delta efficiently. Can we do asynchronous pixel transfers on the Web?
Alright, action plan.
I'll be removing all the current render commands and shapes and replacing them with one simple
stroke
command.This should be an easy first feature that will allow us to start doing interesting things.
This does exactly the same thing as
stroke thickness color (line from to)
does in the current iteration, but is hardcoded to always render lines.We can rework this or add in filled shapes later.