Unanswered user makes question their MS thesis and answers self 2 years later

Not only slow GUIs but GUIs that demand tens or hundreds of MBs just to draw a few items

(Consider the Rick and Morty "true level" bit... and realize it's not that much of an exaggeration when it comes to stuff like this...)

I have worked with people actually trying to do several of such projects like implementing RSA encryption from scratch, a charting library, and several other similar projects they assumed where going to be a quick solution. It’s not that such projects are impossible, it’s that people starting them generally have no idea what’s actually involved.

That said, if you’re doing it for fun then feel free.

(if you recognise the reference you're right if not it's here https://www.youtube.com/watch?v=jG7dSXcfVqE)

> I am currently working on a standard Windows desktop application <...>

> and have decided to write a GUI framework on my own

If you want to write an application, rolling your own GUI framework is obviously a horrible idea.

In this particular case the reddit!OP converted their GUI framework experiment into a master thesis, but that does not make the advice in the 'first comment' less valid. Did they write that application they wanted?

I now have some production experience in Rust and have learned to shy away from Piston. I think you've inspired me to try again with SDL2 and a better approach.

If you have some UI in retained mode, chances are that rendering it live every frame will lead to unacceptable performance.

But if you have UI in immediate mode, you can probably switch to retained - essentially lazy rendering until something else happens. But you'll have to be very careful that your render calls are indeed pure functions, and cannot produce different outputs unless some input has indeed changed.

Sciter (https://sciter.com) uses both, as internally as on user's level.

For example you may want to define this:

   var bodyElement = document.body;

   bodyElement.paintForeground = function(graphics) {
     ... draw something 
     ... on top of <body> content 
     ... using the graphics 
   }

It's a complex tangle, all in all.

>Are you building vertex buffers?

yes

>Are you creating backing layers?

I am not sure what those are.

>Even the immediate mode APIs retain information!

Yes, immediate mode only refers to the way the API is designed, it has nothing to do with how the framework works internally.

>Oh, you can’t paint then scale later? Oh, so to do transparency effects you have to redraw the primitives every frame with new alphas instead of sending a different alpha to your shader? OK. Sure.

Yes, in my implementation, I redraw every primitive every frame.

>What’s your invalidation strategy? You don’t have one because it’s all “immediate,” sure. That’s really interesting. If there’s no performance difference, then well, hmm, why didn’t we do this back in the win32 era?

Because the graphics hardware wasn't there. Todays GPUs are crazy fast, which enables you to just push tens of thousands of vertices to the GPU and be done in less than a millisecond. In the early days this all had to happen on the CPU, which were way too slow for this, so you had to be very careful about what to redraw.

As far as I am concerned though, it is pretty irrelevant to the user if an application is slow because the developer made a mistake, or because they wanted it that way.

In most retained-mode GUIs, this meta-state is often a copy of a significant portion of your application state, but with a very different structure. To maintain the integrity of both copies, you then need a layer of events and/or listeners on top of that, with a complex and dynamic control flow.

Retained mode optimizes for display throughput, which matters a few decades ago. Immediate mode is better for latency and consistency, which are much more important now.

React's reconciliation bridges this - immediate mode programming model, retained mode commit model, with key-based bailout to solve the O(n^3) problem. There are reasonable disagreements as to how necessary this is, of course.

If you have transparent or moving elements you have to identify the components behind them and redraw those as well. You could use buffers for each element to avoid some of it, but then you may have to update several buffers for various changes.

If you have elements that are updated a thousand times per frame (progress bars) do you update the whole element every time, only update the affected region of it on every change or try to somehow collect changes that might affect different parts of it for a single update operation?

If you look at ALL the digital workstations, they're doing their own rendering. And they all punt on text scaling.

Usually the GUI framwork wants to own the project. I need to build an application IN Qt or IN C# with WPF. Thats just unnecessary. There is no reason why these libraries can't just provide a header with some functions that I can call, and thats it. The notion that I have to use C# for WPF seems completely ridiculous to me. Or that I don't get to use my own build system (Qt) or chose how I want my control flow to happen and so on. I want the GUI framework to be a library to my application, no the other way around.

I hate all of these build shenanigans. I had a C++ application, that I built with a .bat file. I was not gonna port that to C# or have some bullshit wrapper around C#, or port the whole thing to Qt, or switch my build system. That WPF and Qt required this of me is just unnecessary, and I was super annoyed that everybody thinks that is just ok and not a big deal. Stuff like this makes modern programming a slog and kills my productivity and morale.

I don't know about embedded Qt, but after seing that standard dev Qt download is 40 GB, I already knew this is not going to work because 99% of that is going to be stuff I don't need or want, and (as it always goes with these things) it is going to cause a lot of friction, because, of course, I will still have to interact with those things.

So, yeah, basically I just couldn't find a small, simple, non-intrusive, no arbitrary constraints GUI library that looked halfway decent.