[Klonoar]

> what's a fundamental problem in a lot of "traditional" C++ game code bases

I'll be more clear that I consider the needs of games and the needs of general apps to be very different, and I am particularly discussing the latter and not the former.

> Refcounting overhead cannot be ignored when performance matters,

People throw around the meme of "performance matters" in the GUI space when we've had mostly working solutions for the 99% percentile of applications for decades now. You're going to throw pretty much all your work to a background thread and send some updates over, or you're going to draw to a canvas of sorts that will likely bypass things altogether.

Refcounting is fine for a GUI framework and I am arguing that there is more value in something that ships and works today than waiting around for the next research project GUI framework approach to take off.

Note that I am not saying there's no value in the exploration of a GUI framework that feels "right" for Rust, I'm just saying that the insistence on that being the only goal is odd and ultimately holding the community back.

[flohofwoe]

If you treat every UI widget as its own refcounted object (or even multiple), maybe even uniquely heap-allocated, arranged in deep hierarchies, and share references to those objects within and outside the UI code, then the situation isn't much different from a typical OOP game code base (just replace "UI widget" with "game object")

The most important 'technical quality' of both application types is that user interaction latency must be low, and everything animates smoothly with the display refresh rate without hickups.

Refcounting overhead isn't much of a problem if the number of refcounted objects is in the low hundreds or low thousands (e.g. a simple game or UI application), but it will become one with tens- or hundreds-of-thousands of refcounted objects which are frequently created, destroyed or "shared" (and with a naive approach those numbers are easily in reach as soon as UI table views come into play) - one typical problem for instance is destroying an object at the root of a large dependency tree, which then may 'ripple outward' and cause the destruction of thousands of other objects, causing noticeable hickups (not much different from garbage collection spikes).

[Klonoar]

> but it will become one with tens- or hundreds-of-thousands of refcounted objects which are frequently created and destroyed (and with a naive approach those numbers are easily in reach as soon as table views come into play)

Look, I'm sorry but it's just bananas to throw around "hundreds of thousands of refcounted objects" when I've already bluntly pointed out that I'm discussing general application building. Joe Schmoe wanting to put together an email client should be able to slap a column view somewhere that can render a virtualized list and move on with their life.

This has been fine in multiple different native widget kits for some time now. It is not as intensive as what some games want to do UI-wise. The current situation does lead to overly complex UI approaches and contributes to the general approach of "smack it with a web browser" that we all collectively bemoan.

[flohofwoe]

> Joe Schmoe wanting to put together an email client ... and move on with their life.

Tbh, for that type of problem a smart Joe Schmoe wouldn't pick a tech stack like Rust in the first place, and instead just write a simple web app (because implementation details aside, the next problem is how to distribute the damn thing without "sideloading" or "potentially harmful download" warnings popping up all over the place).

[Klonoar]

You're focusing on the "email" part when the point is the widget type itself, which signals to me we've reached some form of an end to this I guess.

(And that's not even going in to why one might not want to deal with the web)

[dathinab]

I agree refcounting is fine in state in a GUI, i.e. for using the GUI framework. But IMHO it's not fine for in state in many games.

It might also be less fine so for writing a GUI framework/library.

But it doesn't need to be IMHO as for writing the framework/library you can put your hand in the box of fancy data structures and use what's best suited even if it's implementation involves unsafe code as long as it's contained, well tested and fuzzed.