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

Open
opened 2024-08-20 19:29:36 +02:00 by liquidev · 2 comments
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.

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.
riki added this to the Backlog project 2024-09-13 20:24:03 +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?
Owner

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.

stroke
  thickness : number
  color : rgba
  from : vec
  to : vec
  -> scribble

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.

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. ``` stroke thickness : number color : rgba from : vec to : vec -> scribble ``` 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.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: riki/rkgk#27
No description provided.