New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a low-level renderer #8
Comments
I'd like to help with this. I'm writing an application that is essentially a form of cad and I'd like to use iced as the gui for it. |
What would be the approach here, draw widgets in terms of the low level API directly or create higher level 2d drawing abstractions first that are then used to draw the widgets? I don't know the wgpu API but might seem a bit to low level? Anyway maybe a good start could be something like Lyon? apparently it can render using the wgpu backend still more layers might need to go in the middle. Nical approach is more bottoms up, creating solid foundations, iced is starting from the top, having an opinionated but elegant design that UI developers are already used to and comfortable with. Now we are missing badass APIs that can fit in the middle that solve different use cases and can be used by widget developers in a composable way to create great experiences 😃 |
The approach I have in mind is to build/reuse a flexible 2D renderer abstraction, backed first by
The declarative command list approach is the one I had in mind. This approach works really well with Iced, because it completely decouples the generation of commands (widgets and widget state) from the actual rendering operations (graphics backend). It fits naturally. Additionally, a declarative, side-effect free approach makes everything easier to test, and provides a lot of information to the renderer to perform many optimizations and improve over time.
Coffee uses
I think it's a bit too early to see how this would work. But I don't see why it would be a problem to have different renderer abstractions as long as they are using the same graphics backend, given a layer of coordination (i.e a UI widget providing you access to 3D graphics).
Indeed! This is where the fun begins! |
If I may, for UI type things (as for everything really) it's important to have a look at what your main primitives are (what constitutes 90% of the type of things you'll be rendering). I'm super happy to see lyon used in more places in any case. Keep it up! |
It's probably worth keeping pathfinder in mind as well. |
I have implemented a first version of a very simple I think exploring other options, like |
I'll just name drop WebRender as a higher-level alternative to wgpu. It provides optimized 2D rendering whilst abstracting away the raw GPU concerns. Still need Pathfinder for the vector graphics though. |
feat: various improvements to window commands and event handling
draw cursor for IME editing.
Both the renderer in
coffee
and theggez
one in the examples are using a high-level abstraction. This makes it really easy to build a somewhat simple renderer, but makes interesting features (like scrollables) complicated.I would like to implement a renderer using a lower-level API. This renderer could accept different kinds of configuration, and also support widgets with many styling options.
I am familiar with
wgpu
, and supporting all the platforms natively and also the web sounds great! In any case, I think there are many interesting similar efforts that may be worth investigating and contributing to!The text was updated successfully, but these errors were encountered: