5 ms·

It's kind of funny how the author dismisses web technologies while complaining about redundant rerenders in Rust GUI libraries. This is all solved in browsers,

• andrewmcwatters 3y ago
  The amount of effort it takes to create high-performance applications in a web environment is significant, though, and the benefits you get simply working in a faster language in a desktop environment are lost on most web developers, I think, simply because most of them don't actually do any desktop or graphics API work. They simply wouldn't know. Also UI compositors are not a solved space. If they were, people would absolutely not being using Electron. But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they?
  • rahkiin 3y ago
    Please, if someone has just that, let me know. It would be excellent for games. I do believe there are implementations of flexbox in rust.
    • andrewmcwatters 3y ago
      Yeah, it's a problem space I'd like to try to tackle again some day. Yoga et al. aren't enough. I think people are dying for a web-based compositor in other host language environments, but don't know how to elucidate this concept because they don't know anything else.
    • fit2rule 3y ago
      [dead]
  • suby 3y ago
    Right. The point of wanting to avoid redraws is for performance. Sure, you avoid redundant redraws in web browsers, but it defeats the point because the browser is slow compared to native, even with those avoided redraws.
  • text0404 3y ago
    i mean, people have done some pretty impressive stuff with React and threejs: https://codesandbox.io/s/i2160 https://codesandbox.io/s/i2160. i work in FE with 3D engineers with graphics and game development backgrounds who are at the forefront of the field, working on browser-based applications. we tried desktop apps and found the browser to be a better balance for performance, compatibility, and desired features (data streaming, webgl, React for turning incredibly complex state into 3D/UI) without being too low level. we can also deploy updates easily, without excessive build times, with little to no interruption to our users. edit: another neat one: https://deck.gl/examples/trips-layer https://deck.gl/examples/trips-layer
  • chrismorgan 3y ago
    > But no one is saying, "Hey I have a CSS 2.1 compliant rasterizer and compositor that you can use in your C++ or Rust environment!" are they? There’s actually quite a lot of interesting work going on in that general space, has been in various forms for some years. A couple that immediately spring to mind: • Azul <https://azul.rs/ https://azul.rs/> builds on WebRender, as used in Firefox. I haven’t looked at it for a few years, but it looks to have grown quite interesting now. • Blitz <https://github.com/DioxusLabs/blitz https://github.com/DioxusLabs/blitz> is based on from-scratch implementations of CSS layout and rendering, and wgpu rendering. It’s not usable yet, but is a very interesting concept. If one happens to be familiar with React Native: it’s kinda like that, or React Native Web.
    • ricardobayes 3y ago
      React Native Web is a bit like scratching your left ear with your right arm :)
      • chrismorgan 3y ago
        Actually, forget the React Native Web thing, I think I was mixing it up with something from a few years back that was more the other way round (running React web stuff on React Native, not running React Native on web). React Native Web… eh, it has a potential place. Maybe like scratching your left ear with your right arm, because your left arm is partially paralysed, or something!
  • mike_hearn 3y ago
    Technically, you could ship a minimal link of a JVM and use JavaFX. It has a compositor, a CSS 2.1 rasterizer, layout managers and renders to D3D or OpenGL surfaces. I think they're adding Metal at the moment. The weakness is interop with C/C++. There's a new Java FFI in the works that makes that a lot better by auto-generating bindings from header files and avoiding JNI, but it hasn't shipped as stable yet. It's usable. You just have to accept that the API might change a bit. You can also compile the whole thing to a native library that doesn't use a typical JVM at all. Memory usage and startup time is a lot better if you do that. You can also expose functions natively to C, or bind to C natively, using a different approach. If I were to do use that approach I'd write a generic binding layer that lets you connect JavaFX observables to their C++ or Rust-side data structures. FX has an architecture that's very based on observable variables, which all have a uniform API, so if you can control those from the native side then you can do anything. Either updating state objects that are then in turn connected to UI objects, or directly updating UI.
• geodel 3y ago
  > but the premise that "web is slow" has been disproven so many times already. No it is not. Though it seems proven that even with very powerful hardware users in general have been pushed to minimal expectations. So GUIs that take seconds to start or respond on multi Ghz processors and multi GB RAMs are considered fast now. This argument is web GUI is fast is more of "It's been proven multiple times meal kits are cheaper than buying groceries from store". Yeah, someone can find really cheap meal kits if they spend many hours on hunting a deal. But in general case grocery in store is plain cheaper for most of reasonable shoppers.
  • text0404 3y ago
    you're still arguing about the usage of modern web technology, not its actual performance. > No it is not. Though it seems proven that even with very powerful hardware users in general have been pushed to minimal expectations. So GUIs that take seconds to start or respond on multi Ghz processors and multi GB RAMs are considered fast now. ok, so php is slow now? statically rendered sites have somehow become larger than they used to be? the web is fast. just because some developers don't know how to leverage it properly doesn't make it less fast.
  • jupp0r 3y ago
    Define fast. Do you care about frame rates? input latency? startup times? memory usage? There are trade offs, but if you care about high frame rates and low input latency, web apps can totally deliver that. Look at https://lighttracer.org/app.html https://lighttracer.org/app.html, for example.
    • zigzag312 3y ago
      I tried that app expecting responsive app, but the viewport lags significantly, and when rendering, the whole UI lags.
    • jcelerier 3y ago
      I tried opening the link and did not even have the patience to wait until "compiling shaders" was done. When I saw the buttons slowly coming up one at a time I literally laughed. Is this supposed to be a remotely good example?
• usernew 3y ago
  Alright, here's I want you to do. It'll be interesting and fun, you'll make something cool, it's free, and then you'll come back and look at your comment and reply with a "/s." Download pirated copies of protools and melodyne, and a bunch of virtual instrument libraries from torrents. Download a midi file for a song you like, dump it into protools. Record yourself singing, right on the PC or headset mic - no need to hit the right notes. Dump the voice instrument and your voice recording into Melodyne and drag the voice to match the notes on the voalc tone track. Now set up a link from your Melodyne track into a protools track. Then go wild, play around, apply filters, do fun stuff. You might get stuck in the fun for a week and it'll keep you awake late. Once you're done, think about doing all that on a web page or a web page pretending to be a local app. Then reread your comment. Oh by the way, you will need to install a new raw driver for your soundcard. You see, something like a 5ms audio latency you get from you normal windows sound driver, is too slow. Give some thought on how slow doing anything in JS is going to be, if a native hardware driver is too slow.
  • text0404 3y ago
    the article is about the _UI_ for a DAW, not the core engine. the UI isn't concerned with audio analysis or applying filters or raw drivers for soundcards. it's just a visual representation of state.
  • jupp0r 3y ago
    Until last year, I worked on a team that built an electron app for video conferencing with a double digit million user base. We did audio processing (mixing, RNN noise reduction) via WebAudio in WASM. This is in production right now as far as I know and adds very little latency. That being said, this is about GUI. No reason not to do as much native processing as your heart desires outside of your GUI layer.
    • TheOtherHobbes 3y ago
      A DAW is going to be doing far more audio processing on tens or hundreds of channels simultaneously, while playing back some of the audio from disk, some from memory, some from live inputs, and also receiving, processing, and recording/playing MIDI events. And hosting both the audio and GUIs of third party plugins.
• outsomnia 3y ago
  Yeah. The OP should spend a day or two making HTML5 prototypes for the key aspects and see if it's really true that it's "slow". The UI is not the hot code, it's the audio mixing. So long as the audio mising is faultless, it doesn't matter too much if it takes an extra video frame to update the dB display. Because there are thousands of people working to maintain the code in the browser stack every day that are on his side then.
  • richrichardsson 3y ago
    I can assure you that users complain when the GUIs of DAWs start to run below 30fps, and really the expectation these days is that "performant" GUIs run at 60fps.
    • outsomnia 3y ago
      I am suggesting confirming if it is actually "slow" for the "key aspects". You and the OP are just assuming it can't do whatever it is at "30fps"... if you're right, it will only take ten minutes if it's so bad, or an hour or two if it's subtle, to actually confirm whatever the worst thing is. The "extra frame" I was thinking of is graphics pipeline latency, not redraw time.
      • richrichardsson 3y ago
        Well now you're assuming what I'm assuming, which is fair enough because I assumed by your comment that you were saying the UI responsiveness isn't really a concern in DAWs. It's definitely a secondary concern, but people are accustomed to buttery smooth UIs and complain when they're not. That said, I'd argue that even latency is still a concern for things like meters. If they are noticeably out of sync with what you hear then users will again complain.
• lelanthran 3y ago
  > but the premise that "web is slow" has been disproven so many times already. That's news to me. Do you have a link comparing local non-electron apps with local electron apps? I mean, a gui chat app I wrote a while back using libpurple(or something with that name, could have been libpigeon), without even trying, started up and loaded all cached chats faster than I could measure at the time (under 10ms). None of the current electron-based chat apps I use right now take less than 5s even on hardware (M1 MB) that is literally 15 years ahead.
  • jupp0r 3y ago
    Is latency of loading the app really relevant in the digital audio workstation use case? (no). As long as you get good frame rates while the GUI is running and latency is reasonably low, startup performance is not that important.
    • lelanthran 3y ago
      I was responding to this: > but the premise that "web is slow" has been disproven so many times already So, yeah, startup duration absolutely counts. More to the point, even while using (for example) slack you still see +500ms latencies while doing things like typing Native chat apps had instant (sub 10ms) responses. But, you made the claim that web being slow has been disproven, which really is news to me, so I want to see benchmarks you are referring to.