Earlier quoted context omitted.
This is absolutely not the case for many DAW plugins
Which part isn't the case?
Plugins in DAWs are graphically complex, animate, and exhibit plenty of the issues described about DAWs themselves
Digital Audio Workstation Front End Development Struggles
191–200 of 276 posts
Re: Digital Audio Workstation Front End Development Struggles
#192The article claims that Druid doesn't use damage tracking for rendering, but this is not true, or at least not reasonably so. Druid does track damage regions and pipes this all the way to the OS. The only exception is macOS, where the regions are still tracked but not fully connected to the OS. There is an abandoned PR that even adds the connection.
That said, not using Druid for a DAW project is a fine choice. Doubly so for a new project, as it was correctly pointed out in the article that Druid is now in maintenance mode.
Re: Digital Audio Workstation Front End Development Struggles
#193Earlier quoted context omitted.
Discord and Slack are both nicely optimized web apps but they're not very fast compared to native apps. You can tell that there's a noticeable lag between when you type into discord versus the terminal.
I didn't realise the bar latency had to get over was a comparison to a terminal! I best throw every ide or tool I've ever used in the bin!
Do you have any idea how fast modern CPUs are?
I have used more complex native applications on Windows 95 that had less latency than Discord does, on a 10900k 20-thread CPU.
Modern terminals are quite slow compared to how fast the CPU itself it, because of the myriad of layers it sits upon.
And Discord is extremely slow it's not even funny. Having one single frame of additional lag between click and action, with modern PCs probably means billions of instructions being executed. For a glorified IRC client, to render a screen?
The problem is we all have become complacent and lazy, so we are used to software which is utterly inefficient and slow. You should throw all your IDEs in the bin, if only there was one that felt as snappy as Turbo C++ did 30 years ago.
Re: Digital Audio Workstation Front End Development Struggles
#194Earlier quoted context omitted.
Which part isn't the case?
Plugins in DAWs are graphically complex, animate, and exhibit plenty of the issues described about DAWs themselves
Yes, but a DAW must do that dozens/hundreds of times more and is on screen for the entire lifetime of the program.
I stand by what I said: most plugins have nowhere near the complexity of a DAW. Some do! (Kontakt/Reakt, and so on) but the vast majority only have a small subset of what the DAW needs to display, and only need to do it for a limited number of channels, and only need to do it rarely.
Re: Digital Audio Workstation Front End Development Struggles
#195I'm curious as to why the author thinks that the fltk-rs rust bindings to fltk are "practically unusable." I've been using them and while there is a definite learning curve they seem complete, stable, and performant. Also the author is extremely helpful and responsive!
Re: Digital Audio Workstation Front End Development Struggles
#196I have a feeling desktop development is going to slowly revert back to classic OOP paradigms just like the web world detoured from MPA -> SPA -> SPA+SSR -> back to something that looks a lot like MPA again. Classic toolkits like GTK, Qt, UIKit/AppKit, Swing and JavaFX use OOP to solve some of the problems this article talks about. However, this OOP model seems to be somewhat incompatible with Rust's strict memory saf…
I think we need other UI models instead of everything mature being object-oriented-oriented. Doing UI work in FP (or FRP) is great in many aspects until you need to integrate with these OO models like the DOM, et.al. Direct integration or a first-class VDOM-like model would be a nice step. There’s a tangent issue with all of popular game engines built around objects.
What you're asking for is what Compose does (the new Android toolkit). Being pure FP though does have issues. There's no way to get a reference to anything on the screen, so some tasks that are basic and obvious in an OOP toolkit turn into a strange hack in Compose. For instance to focus a text edit you have to create and memoize a "focus requester", pass the "requester" as a parameter to the TextField function, then "launch an effect" and finally you can use the requester to request the focus.
Compare to an OOP toolkit: call edit.focus() when the UI is first displayed and you're done. The reason you need a requester in Compose is because everything is FP and lacks identity, even though there actually is object identity buried deep inside, it's just hidden from you.
The FP model does have some benefits, but I think OP is right and we'll end up with a less radical mixed approach.
Re: Digital Audio Workstation Front End Development Struggles
#197Earlier quoted context omitted.
Is there somewhere that has a good guide to understanding why this is the case? I'd love to learn more about it. I imagine there's a lot more to it than a gpu's pixel fill rate, which from the marketing should be sufficient but obviously from this discussion is not.
You really don't feel this unless you do graphics programming and then it hits you like a ton of bricks. If you want a beginner's introduction to pixel fill impact, and say, you're a web developer, try picking up a friendly graphics framework like Phaser, LÖVE, or something comparable and writing a shader that's applied to a fullscreen framebuffer, and measure the frametime that it takes to simply draw that as compar…
That really doesn't explain the why though. Why is pixel fill so slow? You'd expect the opposite given the numbers on graphics cards. What's the disconnect here?
Re: Digital Audio Workstation Front End Development Struggles
#198It'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, both on the rendering engine and on the web framework library levels. Yes you need to pay attention to performance, but the premise that "web is slow" has been disproven so many times already. Just because it's really easy to write apps that are slow (and thus…
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…
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.
Re: Digital Audio Workstation Front End Development Struggles
#199Earlier quoted context omitted.
> I'm not sure even operating systems do Oddly enough Windows used to be a lot better at what you describe than it is (in practice) today. I've used old systems where it took 0.5sec to clear the screen, and you could see the color sweep down the monitor from top to bottom. Now THAT is slow. Because of that the OS used a lot of tricks to minimize drawing, such as xoring the caret, and precisely tracking dirty regions…
I think you're right. It used to be practice to limit your invalidation rect/region based on known bound information. Now every developer treats their entire buffer as a cheap throwaway and they couldn't be further from the truth.
It's still done. JavaFX does dirty region tracking for example, e.g. here
https://github.com/openjdk/jfx/blob/master/modules/javafx.gr...
and that's a toolkit that's still relatively modern (it was ahead of its time). For example the UI thread is separated from the rendering thread, so one core can be computing the layout/processing events/doing animations for one frame whilst another core renders another frame to a GL/D3D command stream.
Re: Digital Audio Workstation Front End Development Struggles
#200> Both Javascript and the DOM are slow, there's no changing that. The DOM isn't slow. Adding or removing a DOM node is literally a few point swaps, which isn't much more than setting a property on an OOP language object. What is slow is "layout". When Javascript changes something and hands control back to the browser it invokes its CSS recalc, layout, repaint and finally recomposition algorithms to redraw the screen.…
> Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry you through a lot of things that would break if you were using non virtual DOM frameworks A virtual DOM based framework will not be faster than manual DOM manipulation with either vanilla JS or even JQuery. It certainly makes development easier, and massively re…
And yet, InfernoJS is faster than Svelte while using a VDOM.