You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed quite a few comments mentioning a future refactor to an ECS based design, which I think would be great to bring back! The ECS paradigm seems to fit us well here by making it easy to parallelize our state management and render pipeline.
I think bevy_ecs would be the perfect fit for us, especially since we may be able to integrate with their Accesskit, and Winit support (among other things).
Outline
This sounds like a major change so just to outline the steps I think we could take:
Systems can access these components in parallel, running multiple parts of a render at the same time
Finally we may be able to replace our rendering logic with systems, potentially simplifying the crates here and increasing performance. This I imagine could be a longer term goal, but one I think that would come with major benefits.
Sharing more with Bevy
By using the UICamera with custom UINodes we design for the web we could share code for accessibility, rendering, and running shaders.
Another option could be to use bevy_vello as our canvas, letting us re-use more code we currently have
I'm open to potentially switching to an ECS, but I'm a little wary of it:
It's a bit architectural shift which probably wouldn't be very easy to undo
We shouldn't just assume that it will be better. It may well have performance issues and other complexities we haven't anticipated.
A lot of the benefits of ECS (e.g. parallel processing) don't really apply to tree-traversals which are what Blitz is mostly doing.
I suspect it won't ever make sense to go down the full bevy_ui route. Blitz's DOM is considerably more capable at rendering HTML than bevy_ui, and bevy probably won't want to take on all the legacy code required to implement that. I think we should continue down a route of modular crates where it makes sense (winit, taffy, parley, cosmic-text, accesskit, wgpu, vello, etc - and maybe bevy_ecs), but not attempt to share glue code where we may well want to diverge on the implementation.
I've noticed quite a few comments mentioning a future refactor to an ECS based design, which I think would be great to bring back! The ECS paradigm seems to fit us well here by making it easy to parallelize our state management and render pipeline.
I think
bevy_ecs
would be the perfect fit for us, especially since we may be able to integrate with their Accesskit, and Winit support (among other things).Outline
This sounds like a major change so just to outline the steps I think we could take:
bevy_ecs::World
, usingbevy_hierarchy::Children
to maintain the document hierarchyNode
struct with a series of components:Hidden
andHovered
can be attached to a node dynamicallyblitz/packages/blitz-dom/src/node.rs
Lines 72 to 73 in caa3bbf
Finally we may be able to replace our rendering logic with systems, potentially simplifying the crates here and increasing performance. This I imagine could be a longer term goal, but one I think that would come with major benefits.
Sharing more with Bevy
UICamera
with customUINode
s we design for the web we could share code for accessibility, rendering, and running shaders.bevy_winit
andbevy_a11y
could work well with an ECS-based node hierarchyThe text was updated successfully, but these errors were encountered: