Comments (7)
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).
In general for UIs these are mostly text, axis-aligned (potentially rounded) rectangles filled with a simple pattern (solid color, image, gradient), borders and maybe shadows. Lyon isn't the most straightforward or optimized way to deal with these simple (but important) primitives. I think lyon can help with some of the other 10% of fancier primitives, but I'd suggest designing around the common 90% first.
I'm super happy to see lyon used in more places in any case. Keep it up!
from iced.
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.
from iced.
It's probably worth keeping pathfinder in mind as well.
from iced.
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?
Some time ago I read discussions(like here) about this kind of stuff and the need for 2d drawing APIs, I have little idea about low level graphics programming but what I got from @nical creator of lyon
(btw dependency in ggez
) is that games and UIs might have different needs on how they draw 2d.
iced
would be mainly used for UIs but it would still be good to consider both cases by allowing widgets that have different renderer to be composed but hopefully share a common ground? For example I'd like to create a map widget and render tiles in a 2d/3d surface, the kind of APIs needed seem to be closer that of a game but mixes dialogs and is embedded on a normal UI, creators of such a widget usually bundle a lot of code because they create things in terms of the low level API when it seems there could be several things to be shared with the UI rendering code(e.g. text!).
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 😃
from iced.
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?
The approach I have in mind is to build/reuse a flexible 2D renderer abstraction, backed first by wgpu
. Widgets shouldn't have to deal with pipeline setup and shaders unless strictly necessary.
Some time ago I read discussions(like here) about this kind of stuff and the need for 2d drawing APIs,
The declarative command list approach is the one I had in mind. Widget::draw
would only record renderer commands, completely side-effect free. Then Renderer::flush
would compare last frame commands with the new ones, perform diffing and rerender only what is necessary.
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.
but what I got from @nical creator of lyon(btw dependency in ggez)
Coffee uses lyon
too! It's great, and it is definitely something we could use to generate meshes.
it would still be good to consider both cases by allowing widgets that have different renderer to be composed but hopefully share a common ground? For example I'd like to create a map widget and render tiles in a 2d/3d surface
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).
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
Indeed! This is where the fun begins!
from iced.
I have implemented a first version of a very simple wgpu
renderer in #22. As always, feedback is greatly appreciated.
I think exploring other options, like pathfinder
and piet
, and contributing to them could be a faster way to get a more feature-complete renderer while the wgpu
one matures.
from iced.
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.
from iced.
Related Issues (20)
- Crash on raspberry pi when using wgpu feature
- Container shadows are inconsistent between `wgpu` and `tiny-skia` with custom theme HOT 2
- Dynamic Window Size HOT 2
- Running the example from README.md: "cannot find function `run` in crate `iced`" HOT 4
- Input widget should not copy or cut if secure
- Scrollable content remains at the top of a scrollable
- My text() os not updated when clicking Theo button in FydeOS 18.0 HOT 3
- Pane Grid `PickList` does not work when `Responsive` is present in Pane's controls
- 0.12.1 Failing to compile when included as dependency HOT 1
- Cannot use mousewheel without shift to scoll a horizontal-only scrollable. HOT 2
- Problem rendering texts in PopOS 22.04
- GLIBC_2.29 not found in Deepin 20.9 HOT 1
- Application does not start on Windows 10 pro 64 bits HOT 2
- Shell opens along with the iced application in Windows 11 Pro HOT 2
- TextInput value overflow with tiny-skia backend
- web-sys dependecy resolution HOT 1
- image ferris cannot be loaded in tour example under wasm target
- MouseArea does not report mouse wheel events.
- Nix shell expression out of date in `DEPENDENCIES.md` HOT 1
- Nested scrollable behaviour
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iced.