5 ms·

How practical would it be to produce a 2D UI using a framework built on these kinds of APIs? I'm wondering if there's a future down the road for multi-platform

How practical would it be to produce a 2D UI using a framework built on these kinds of APIs? I'm wondering if there's a future down the road for multi-platform desktop apps with the convenience of Electron-like development and distribution, but where the native clients are able to be much thinner than a whole browser.

kvark 8y ago
There is an imgui port to wgpu-rs in progress - https://github.com/unconed/imgui-wgpu-rs https://github.com/unconed/imgui-wgpu-rs . I don't know how feasible it would be to compile it to WASM later on, we'll see.
alex_duf 8y ago
What you want is pretty much HTML isn't it?
bluejekyll 8y ago
Webrender might be the abstraction you want. I don’t know anything about this, but node wrappers for webrender: https://github.com/cztomsik/node-webrender https://github.com/cztomsik/node-webrender And even a demo app: https://github.com/cztomsik/slack-app/blob/master/README.md https://github.com/cztomsik/slack-app/blob/master/README.md
flohofwoe 8y ago
There's no need to tie the 2D UI framework to the underlying rendering API. If you look at immediate-mode UI systems like Dear ImGui, those provide vertices, indices and a command list for rendering in each frame, and it's very easy to render those commands through all existing 3D APIs. For instance here is an example of such a render function, it's just 50 lines of C, implemented on top of slim cross-platform headers with support for Windows, Linux, macOS, iOS, Android and WASM: https://github.com/floooh/sokol-samples/blob/0576ed914290a352e2f4c56c6b1577a77977f4cf/sapp/imgui-highdpi-sapp.cc#L270-L319 https://github.com/floooh/sokol-samples/blob/0576ed914290a35... (this is from this demo which is 513 KBytes all in all: https://floooh.github.io/sokol-html5/wasm/imgui-highdpi-sapp.html https://floooh.github.io/sokol-html5/wasm/imgui-highdpi-sapp...) With such a bloat-free UI system you can create statically linked single-exes with embedded font data and shaders in a few hundred KBytes, and people are starting to use this for "proper" desktop tools too (not just as embedded tool UIs for games etc)
unconed 8y ago
Not very. There is a huge difference between graphics rendering and interactive UI. By the time you add proper cross platform text rendering, a proper layout system, image/video/audio (incl. multirate streaming), resolution scaling, accessibility, compositing, animation, etc. you won't have such a thin client anymore. Plus you'll probably want cross-platform consistent networking, storage and security too. Electron is so big because it reinvents every possible wheel in exactly this way to provide maximum consistency. Plus, you will have to deal with the fact that while you can push large amounts of computation out quickly to the GPU, reading back the results to CPU involves long latencies and scheduling issues. It often results in a loss of the kind of generality people take for granted in pure CPU programming, from little things like not being able to printf() in the middle of a program, to larger things like having to manually hook up every function call in GPU land by submitting a detailed description of your specific desired calling convention in triplicate (i.e. uniforms, varyings and attributes). The alternative model is platform specific front-ends backed by a mostly universal back-end library. Used successfully by Transmission, VLC, and others. All the conveniences of being tailored to each platform in terms of UX and integration, but with the same basic broad functionality. But few companies will want to pay for 2x the devs, while in the open source world in practice the various platforms diverge so much they almost feel like different apps entirely. Still, it is much preferable over a 300MB+ hog that can't display more than 2 screenfuls of chat.
kuwze 8y ago
This might be of interest to you[0] [0]: https://github.com/PistonDevelopers/conrod https://github.com/PistonDevelopers/conrod
- mrec 8y ago
  I think Conrod and other IMGUIs are intended more for games than for desktop apps.
msvan 8y ago
There is this: https://github.com/revery-ui/revery/blob/master/README.md https://github.com/revery-ui/revery/blob/master/README.md
pcwalton 8y ago
> I'm wondering if there's a future down the road for multi-platform desktop apps with the convenience of Electron-like development and distribution, but where the native clients are able to be much thinner than a whole browser. I sure hope so! It's no secret that I've been hoping that someone will put together all the pieces we've been developing—WebRender, Pathfinder, gfx-rs, font-kit, skribo, etc.—and create a lightweight UI framework for Rust. None of us have the time to do so, but all the pieces are there…
- steveklabnik 8y ago
  I'm excited for Druid, personally.
  - markdog12 8y ago
    I'm guessing that's https://github.com/xi-editor/druid https://github.com/xi-editor/druid stemming from https://raphlinus.github.io/rust/2018/12/16/rust-2019.html https://raphlinus.github.io/rust/2018/12/16/rust-2019.html?
    - steveklabnik 8y ago
      Yes, sorry!
doctorpangloss 8y ago
Not practical compared to any UI framework people actually use. It’s probably been a decade now that all software that can be written by normals has already been written. Projects like this thrive because as opposed to fulfilling some user’s need, they are very intellectually stimulating to work with and thus make programming fun again. A program that isn’t joyful to write never gets written.
ex3ndr 8y ago
Native UI usually built on top of such API and can be optimized better.
chadcmulligan 8y ago
One of the usual problems with this is font rendering, this project seems to use free type like most others. This still has patent issues https://www.freetype.org/patents.html https://www.freetype.org/patents.html which limit some of the rendering. To me it never renders as fast or as well as native solutions, though its been a while since I've looked at it.

kvark 8y ago

There is an imgui port to wgpu-rs in progress - https://github.com/unconed/imgui-wgpu-rs https://github.com/unconed/imgui-wgpu-rs . I don't know how feasible it would be to compile it to WASM later on, we'll see.

alex_duf 8y ago

What you want is pretty much HTML isn't it?

bluejekyll 8y ago

Webrender might be the abstraction you want. I don’t know anything about this, but node wrappers for webrender: https://github.com/cztomsik/node-webrender https://github.com/cztomsik/node-webrender And even a demo app: https://github.com/cztomsik/slack-app/blob/master/README.md https://github.com/cztomsik/slack-app/blob/master/README.md

flohofwoe 8y ago

There's no need to tie the 2D UI framework to the underlying rendering API. If you look at immediate-mode UI systems like Dear ImGui, those provide vertices, indices and a command list for rendering in each frame, and it's very easy to render those commands through all existing 3D APIs. For instance here is an example of such a render function, it's just 50 lines of C, implemented on top of slim cross-platform headers with support for Windows, Linux, macOS, iOS, Android and WASM: https://github.com/floooh/sokol-samples/blob/0576ed914290a352e2f4c56c6b1577a77977f4cf/sapp/imgui-highdpi-sapp.cc#L270-L319 https://github.com/floooh/sokol-samples/blob/0576ed914290a35... (this is from this demo which is 513 KBytes all in all: https://floooh.github.io/sokol-html5/wasm/imgui-highdpi-sapp.html https://floooh.github.io/sokol-html5/wasm/imgui-highdpi-sapp...) With such a bloat-free UI system you can create statically linked single-exes with embedded font data and shaders in a few hundred KBytes, and people are starting to use this for "proper" desktop tools too (not just as embedded tool UIs for games etc)

unconed 8y ago

Not very. There is a huge difference between graphics rendering and interactive UI. By the time you add proper cross platform text rendering, a proper layout system, image/video/audio (incl. multirate streaming), resolution scaling, accessibility, compositing, animation, etc. you won't have such a thin client anymore. Plus you'll probably want cross-platform consistent networking, storage and security too. Electron is so big because it reinvents every possible wheel in exactly this way to provide maximum consistency. Plus, you will have to deal with the fact that while you can push large amounts of computation out quickly to the GPU, reading back the results to CPU involves long latencies and scheduling issues. It often results in a loss of the kind of generality people take for granted in pure CPU programming, from little things like not being able to printf() in the middle of a program, to larger things like having to manually hook up every function call in GPU land by submitting a detailed description of your specific desired calling convention in triplicate (i.e. uniforms, varyings and attributes). The alternative model is platform specific front-ends backed by a mostly universal back-end library. Used successfully by Transmission, VLC, and others. All the conveniences of being tailored to each platform in terms of UX and integration, but with the same basic broad functionality. But few companies will want to pay for 2x the devs, while in the open source world in practice the various platforms diverge so much they almost feel like different apps entirely. Still, it is much preferable over a 300MB+ hog that can't display more than 2 screenfuls of chat.

kuwze 8y ago

This might be of interest to you[0] [0]: https://github.com/PistonDevelopers/conrod https://github.com/PistonDevelopers/conrod

mrec 8y ago
I think Conrod and other IMGUIs are intended more for games than for desktop apps.

msvan 8y ago

There is this: https://github.com/revery-ui/revery/blob/master/README.md https://github.com/revery-ui/revery/blob/master/README.md

pcwalton 8y ago

> I'm wondering if there's a future down the road for multi-platform desktop apps with the convenience of Electron-like development and distribution, but where the native clients are able to be much thinner than a whole browser. I sure hope so! It's no secret that I've been hoping that someone will put together all the pieces we've been developing—WebRender, Pathfinder, gfx-rs, font-kit, skribo, etc.—and create a lightweight UI framework for Rust. None of us have the time to do so, but all the pieces are there…

steveklabnik 8y ago
I'm excited for Druid, personally.
- markdog12 8y ago
  I'm guessing that's https://github.com/xi-editor/druid https://github.com/xi-editor/druid stemming from https://raphlinus.github.io/rust/2018/12/16/rust-2019.html https://raphlinus.github.io/rust/2018/12/16/rust-2019.html?
  - steveklabnik 8y ago
    Yes, sorry!

doctorpangloss 8y ago

Not practical compared to any UI framework people actually use. It’s probably been a decade now that all software that can be written by normals has already been written. Projects like this thrive because as opposed to fulfilling some user’s need, they are very intellectually stimulating to work with and thus make programming fun again. A program that isn’t joyful to write never gets written.

ex3ndr 8y ago

Native UI usually built on top of such API and can be optimized better.

chadcmulligan 8y ago

One of the usual problems with this is font rendering, this project seems to use free type like most others. This still has patent issues https://www.freetype.org/patents.html https://www.freetype.org/patents.html which limit some of the rendering. To me it never renders as fast or as well as native solutions, though its been a while since I've looked at it.