Implement a custom rasterizer instead of using tiny-skia #27

New issue

Open

opened 2024-08-20 19:29:36 +02:00 by liquidev · 1 comment

liquidev commented

2024-08-20 19:29:36 +02:00

(Migrated from github.com)

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.

liquidex added this to the Backlog project 2024-09-13 20:24:03 +02:00

liquidex commented

2024-10-25 21:59:19 +02:00

Owner

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?

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?