[Const-me]

> I think it’s a good demonstration that this kind of architecture can work well over an extended period.

I think for me the figure is about 8 years of development of 1 GUI software, with MVVM and .NET.

> implicit assumptions about the platform here with the reference to styling

It's 2021, pretty much all of them support styling now.

> I was saying that web-based GUIs might have moved from rendering graphical content using one of the plugins a few years ago to rendering it using one of the native technologies today, without necessarily changing the content itself.

None of them were able to reuse much code while switching just the renderer: ActiveX written in C++, Flash in ActionScript.

> the GUI framework you are describing does not exist

WPF and UWP definitely exist. I think modern HTML+CSS can do that too, but I ain't a web nor electron developer and not sure.

> ultimately you still need code to define the way the layout should animate according to whatever rules your system uses

It's the matter how you define them. When you offload playing animations to a framework, you tell the framework which properties to animate and how: define function of time (typically supported ones include step functions, polylines, and Bezier), pass metadata about timing and repeats, etc. That's for the hard case when animations depend on the data, when they do not they're made offline by art people.

> Can you clarify?

When you do them manually, i.e. computing functions of time and changing visuals, following happens.

1. Your code runs at refresh rate of the monitor, typically 60Hz, but for high-end gaming monitors can be 240Hz. Even if you aren't animating anything, this alone prevents certain power saving modes from engaging.

2. If you manually change positions of things not just color, your updates gonna invalidate layout.

3. There're multiple ways of measuring time with different tradeoffs about precision and when it's running versus paused.

A framework is in a better position because it drives the main loop. It knows how many nanoseconds passed since the last frame. It knows when to render at 240Hz and when to sleep on GetMessage() because there's nothing to update. If it knows which properties are animated, it can integrate animations with layout for reasonable performance cost.

[Chris_Newton]

I think for me the figure is about 8 years of development of 1 GUI software, with MVVM and .NET.

Great. As I said before, there are many different architectures that can work well.

None of them were able to reuse much code while switching just the renderer: ActiveX written in C++, Flash in ActionScript.

But if you’re calling that renderer from JavaScript that has already done everything except the rendering, which would be the case with the kind of architecture I was describing if you were just using the plugin for the final rendering layer…

It's the matter how you define them. When you offload playing animations to a framework, you tell the framework which properties to animate and how: define function of time (typically supported ones include step functions, polylines, and Bezier), pass metadata about timing and repeats, etc. That's for the hard case when animations depend on the data, when they do not they're made offline by art people.

Right. But where do you get those data-driven paths from so you can use them as your key frames to drive your animation? That is what is generated in the presentation data layer in this example. No GUI framework can do this for you, because no GUI framework knows the rules of your system for how to lay out a particular diagram and how a transition between states should appear.

Actually moving lines or rotating text or whatever is then little more than an implementation detail, which can be done manually by the presentation layers or handed off to some platform-provided animation system, as the situation dictates.

Your code runs at refresh rate of the monitor, typically 60Hz, but for high-end gaming monitors can be 240Hz. Even if you aren't animating anything, this alone prevents certain power saving modes from engaging.

This seems like such an extreme case that it’s no longer very useful as an example. Who is using a 240Hz high-end gaming monitor, wanting our UI to produce animations that can keep up with that frequency of updates, yet concerned about some unspecified power saving mode not engaging if we do the maths manually when it would have engaged if the work had been delegated to some system service?

If you manually change positions of things not just color, your updates gonna invalidate layout.

We’re talking about immediate mode rendering. What “layout” is there to invalidate?

[Const-me]

> if you’re calling that renderer from JavaScript that has already done everything except the rendering, which would be the case with the kind of architecture I was describing if you were just using the plugin for the final rendering layer

Writing such renderers is huge amount of work. I know because I once did something similar: https://github.com/Const-me/Vrmac When I can, I prefer someone else to do that. Unfortunately, they all do it differently. Not just in terms of pixels on output, but general things.

Like, compare SVG and PostScript – many features are common, yet you gonna need substantially different things on input to make these two formats with the same image.

It’s somewhat similar story about rendering libraries.

> No GUI framework can do this for you

Sometimes XAML can. I remember there was a checkbox in Blend for some target platforms called “fluid layout” or something, the framework automatically replaced some discrete changes with auto-generated animations. Not universally applicable, but sometimes it was good enough.

> Who is using a 240Hz high-end gaming monitor .. yet concerned about some unspecified power saving

On the first page of US Amazon bestsellers in the “Laptops” category there’re a few models with 144Hz displays. These people care, occasionally.

I can agree that was an extreme case, but to lesser extent that applies to laptop users in general. I think laptops have been outselling desktops for a decade now. People don’t like choppy animations; they cause otherwise good GUI to be perceived slow. They don’t like spinning/noisy fans and reduced battery life either.

[Chris_Newton]

Writing such renderers is huge amount of work.

Not so much, if you’re only asking them to do the last step of translating information you already have into whatever format/APIs are needed for a particular medium, which is essentially what I’m advocating with the architecture here.

Long-lived web apps have had to deal with this several times in recent years as the various plugin technologies have been deprecated and ultimately removed from browsers. It obviously takes a certain amount of time to reimplement that logic on what might effectively be a new platform, but it’s certainly achievable, and it’s easier than rewriting more of your application because you’ve been forced to change platforms.

Sometimes XAML can.

I think perhaps you’re misunderstanding my argument, because it is literally impossible for any GUI framework to do what I’ve been describing. It absolutely requires application code to specify what animation is to be constructed, based on the data available. A GUI framework can then handle the mechanics of actually running that animation, but it can’t know what the animation should be. That’s an application problem.

Take a simple example. Suppose we want to illustrate a sorting algorithm. We will do this by drawing 10 boxes in a row on the screen, labelled with different data values to be sorted. Without me telling you how I want to animate those boxes from one order to another after each step of the sorting algorithm, how will your XAML or whatever know what animations to draw? Are we fading out the items that will change positions and then fading them back into their new positions? Are we going to animate a moving item up out of the row, then slide the other items along one way as the moving item slides above them the other way, then animate the moving item back down to its final place? If we do that, are we going to do both horizontal slides at the same time, or one and then the other? What if we want a hybrid, where the moving item fades out, then we slide the others that need to shift, then the moving item fades back in at its new position?

There is no way any GUI framework can know what should happen in a situation like this. The required behaviour needs to be specified as part of your code. The GUI framework can handle the mechanics of fading things in and out or sliding shapes from A to B according to some timing curve, but only once you’ve told it what needs to happen.