-
Notifications
You must be signed in to change notification settings - Fork 72
Split the Renderer into a Path and Mesh Renderer #386
Copy link
Copy link
Closed
Labels
enhancementAn improvement for livesplit-core.An improvement for livesplit-core.featureA new user visible feature for livesplit-core.A new user visible feature for livesplit-core.performanceAffects the performance of the code.Affects the performance of the code.priority: highThis is a high priority issue.This is a high priority issue.renderingThe issue or pull request is affecting the rendering.The issue or pull request is affecting the rendering.
Metadata
Metadata
Assignees
Labels
enhancementAn improvement for livesplit-core.An improvement for livesplit-core.featureA new user visible feature for livesplit-core.A new user visible feature for livesplit-core.performanceAffects the performance of the code.Affects the performance of the code.priority: highThis is a high priority issue.This is a high priority issue.renderingThe issue or pull request is affecting the rendering.The issue or pull request is affecting the rendering.
Turns out that there's a lot of APIs that like rendering paths instead of meshes, such as: (tiny-)skia, pathfinder, svg, Direct2D, HTML Canvas, piet + druid and possibly cairo and core graphics. Since we internally also work mostly with paths, supporting these APIs directly probably makes sense.
I already experimented with this and for some reason if we use a tiny-skia backend (entirely software rendered) it somehow ends up being faster than wgpu. And considering Direct2D offers basically the same capabilities, but is apparently GPU accelerated, we could probably speed it up even further. So that really begs the question why we would need wgpu at all. So we definitely want to split up our renderer and then experiment more.