Ideally yes. This is a failing of the egui toolkit, not necessarily a failing of the people using it. The whole point of a high-level toolkit like this is that you shouldn't have to worry about how things are being rendered.
However, it is still important to counter claims that egui is making if the people using the toolkit are parroting those claims.
> Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?
I don't think I've ever built a web GUI in Rust so I have no idea what the ecosystem looks like. To my detriment, I tend to build most of my UIs from scratch. I can promise that it is possible to have performant UIs with a lot of embedded charts (like this demo has) using the DOM, but I have no idea what Rust framework devs have been getting up to or publishing.
There's also a little bit of a catch-22 here because yes, any time you introduce the DOM, you are going to lose some performance. That doesn't mean that you're going to lose so much performance that the demo above would be stuttery or wouldn't work. But if you're just measuring "how many quads can I refresh on the screen", that's kind of missing the point that you really shouldn't be refreshing thousands and thousands of quads of information in a UI at 60fps. That's not a thing that most interfaces should be doing in the first place.
And if you are genuinely changing thousands of boxes of information on a screen at the same time, kind of by definition that isn't accessible period. There is no way to present that volume of informational change to a screen reader in a way that will be understandable. But a lot of people when building UIs tend to think they're in the rare cases where they need that level of performance and so they need to sacrifice that accessibility, when in reality what they actually have is a giant list of charts and aside from the actual chart rendering, there's nothing particularly expensive going on.
Ideally yes. This is a failing of the egui toolkit, not necessarily a failing of the people using it. The whole point of a high-level toolkit like this is that you shouldn't have to worry about how things are being rendered.
However, it is still important to counter claims that egui is making if the people using the toolkit are parroting those claims.
> Can you recommend an alternative to egui that let's you write entirely in Rust and get the performance of egui but still maintain some level of accessibility?
I don't think I've ever built a web GUI in Rust so I have no idea what the ecosystem looks like. To my detriment, I tend to build most of my UIs from scratch. I can promise that it is possible to have performant UIs with a lot of embedded charts (like this demo has) using the DOM, but I have no idea what Rust framework devs have been getting up to or publishing.
There's also a little bit of a catch-22 here because yes, any time you introduce the DOM, you are going to lose some performance. That doesn't mean that you're going to lose so much performance that the demo above would be stuttery or wouldn't work. But if you're just measuring "how many quads can I refresh on the screen", that's kind of missing the point that you really shouldn't be refreshing thousands and thousands of quads of information in a UI at 60fps. That's not a thing that most interfaces should be doing in the first place.
And if you are genuinely changing thousands of boxes of information on a screen at the same time, kind of by definition that isn't accessible period. There is no way to present that volume of informational change to a screen reader in a way that will be understandable. But a lot of people when building UIs tend to think they're in the rare cases where they need that level of performance and so they need to sacrifice that accessibility, when in reality what they actually have is a giant list of charts and aside from the actual chart rendering, there's nothing particularly expensive going on.