6 ms·

i wonder when we'll see some good UI frameworks that eschew CSS/HTML in favour of writing pixels directly to the screen

deleted 6y ago
[deleted]
TazeTSchnitzel 6y ago
Qt has already been compiled to run in the browser, and that's a very well-known high-quality UI framework from C++ land. http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos/ http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...
- strbean 6y ago
  My first reaction to parent was "what toolkit would be great to target WASM with", second was "let's scan the replies..." Qt in browser gets me excited :)
pjmlp 6y ago
Here is one, https://platform.uno/ https://platform.uno/
bob1029 6y ago
I have started working on something along these lines. I don't write pixels directly to the screen and I am continuing to use the browser and all of its capability, but I have abstracted the client viewport as a 2d surface that I can set arbitrary pixels on from the server. There is a tiled diff mechanism w/ JPEG compression in between client and server for more efficient real-time update of dirty parts of the view. 100% of client events are processed server-side. All the client browser does is display whatever tile it is told to as quickly as possible. Biggest advantage is response time on complex views, followed by the ability to guarantee pixel-perfect presentation on any device capable of websockets and jpeg decoding. Caching of content is on a final tile basis rather than full viewport. This increases the hit-rate substantially, as tiles are not at fixed pixel boundaries, but rather aligned with logical UI elements. Fixed sized elements will more likely produce the same final tile(s) with equivalent SHA256 regardless of client device. Hashing is performed in terms of the UI element's properties (dimensions, size, text, color, etc), so cache lookups can be made along these lines. Biggest downside is latency - This approach has a similar practicality envelope as Google Stadia, et. al. WRT distance from datacenter. 2nd biggest downside is the fact that this technique is fundamentally incompatible with classic web development ideologies and requires new ways of thinking about solving problems. I personally find this last point to be a benefit, but I recognize it would prevent wider adoption in the community.
- taejavu 6y ago
  I pray you’ll never need to display blocks of text, or do anything with text input. Font rendering and text editing are no joke, and browsers do it well with HTML + CSS. Latency might be the biggest downside for your specific use case, but I’d urge anyone tempted to roll their own browser renderer to properly consider text-related concerns first.
  - bob1029 6y ago
    I currently use System.Drawing to produce text segments. I am not attempting to replace HTML/CSS or pass the Acid3 test. I am just going for something that would be sufficient for purposes of building highly-responsive internal business dashboards and other utilitarian applications where predictable and fast layout is more important than arbitrary style support.
tl 6y ago
It's more likely that some good non-web UI frameworks will write WASM-based backends, so that your pre-existing code works in a browser box with all of the good and bad that came with Java, Silverlight, etc...
frou_dh 6y ago
When developers get creative with fully custom GUI drawing then the user is often rewarded with dodgy text rendering.
nahuel0x 6y ago
Flutter is basically this.
IggleSniggle 6y ago
Isn’t this basically what Flutter is?
Latty 6y ago
Sounds like an accessibility nightmare.

deleted 6y ago

[deleted]

Qt has already been compiled to run in the browser, and that's a very well-known high-quality UI framework from C++ land. http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos/ http://vps2.etotheipiplusone.com:30176/redmine/projects/emsc...

strbean 6y ago
My first reaction to parent was "what toolkit would be great to target WASM with", second was "let's scan the replies..." Qt in browser gets me excited :)

pjmlp 6y ago

Here is one, https://platform.uno/ https://platform.uno/

bob1029 6y ago

I have started working on something along these lines. I don't write pixels directly to the screen and I am continuing to use the browser and all of its capability, but I have abstracted the client viewport as a 2d surface that I can set arbitrary pixels on from the server. There is a tiled diff mechanism w/ JPEG compression in between client and server for more efficient real-time update of dirty parts of the view. 100% of client events are processed server-side. All the client browser does is display whatever tile it is told to as quickly as possible. Biggest advantage is response time on complex views, followed by the ability to guarantee pixel-perfect presentation on any device capable of websockets and jpeg decoding. Caching of content is on a final tile basis rather than full viewport. This increases the hit-rate substantially, as tiles are not at fixed pixel boundaries, but rather aligned with logical UI elements. Fixed sized elements will more likely produce the same final tile(s) with equivalent SHA256 regardless of client device. Hashing is performed in terms of the UI element's properties (dimensions, size, text, color, etc), so cache lookups can be made along these lines. Biggest downside is latency - This approach has a similar practicality envelope as Google Stadia, et. al. WRT distance from datacenter. 2nd biggest downside is the fact that this technique is fundamentally incompatible with classic web development ideologies and requires new ways of thinking about solving problems. I personally find this last point to be a benefit, but I recognize it would prevent wider adoption in the community.

taejavu 6y ago
I pray you’ll never need to display blocks of text, or do anything with text input. Font rendering and text editing are no joke, and browsers do it well with HTML + CSS. Latency might be the biggest downside for your specific use case, but I’d urge anyone tempted to roll their own browser renderer to properly consider text-related concerns first.
- bob1029 6y ago
  I currently use System.Drawing to produce text segments. I am not attempting to replace HTML/CSS or pass the Acid3 test. I am just going for something that would be sufficient for purposes of building highly-responsive internal business dashboards and other utilitarian applications where predictable and fast layout is more important than arbitrary style support.

tl 6y ago

It's more likely that some good non-web UI frameworks will write WASM-based backends, so that your pre-existing code works in a browser box with all of the good and bad that came with Java, Silverlight, etc...

frou_dh 6y ago

When developers get creative with fully custom GUI drawing then the user is often rewarded with dodgy text rendering.

nahuel0x 6y ago

Flutter is basically this.

IggleSniggle 6y ago

Isn’t this basically what Flutter is?

Latty 6y ago

Sounds like an accessibility nightmare.