6 ms·

Just because you can doesn't mean you should. Sure, but that’s not an argument for not doing it either. As I’ve been trying to explain, I’ve had practical succ

Just because you can doesn't mean you should. Sure, but that’s not an argument for not doing it either. As I’ve been trying to explain, I’ve had practical success building applications using the kind of software architecture I described. I don’t like to get into personal backgrounds in these discussions, because as a rule I think arguments should stand on their own merit. However, just for some perspective, I wrote my first professional GUI around three decades ago. More to the immediate point, the longest I’ve maintained and extended a single GUI built using the architectural pattern I described was over a decade, and that one was probably more complicated in its requirements than a lot of web applications you’d see today. So although it’s just one anecdotal data point, I think it’s a good demonstration that this kind of architecture can work well over an extended period. There're too many things which can go wrong with visuals. Incorrect order has smaller probability than a bug in a style somewhere which makes data invisible. For the 2nd reason you want to test that thing somehow else anyway: unit tests don't catch rendering bugs. You seem to be making some implicit assumptions about the platform here with the reference to styling. In any case, this is why I mentioned that you might want a different testing strategy for the presentation rendering layer to the code that collects the presentation data. Totally different. SVG renders vector 2D graphics, WebGL is a 3D GPU API. Try to render something slightly more complicated than rectangle of solid color, and you'll see. Sorry, I’m not sure I understand the point you’re trying to make here. 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. Obviously which native technology you’d choose would depend on what kind of visuals you were creating and how you wanted any interactions with them to work. Once you know the data, you do not want to run your code at 60 Hz (or 240Hz if you're really unlucky) computing functions of time and updating things. It's almost always a good idea to use the GUI framework for playing animations. They do better with rendering and power saving. To the best of my knowledge, the GUI framework you are describing does not exist. You might be able to extract some basic movements that could be handed off to something running at a lower level with hardware acceleration, but ultimately you still need code to define the way the layout should animate according to whatever rules your system uses, for the same reason you need to define a static layout before or after the animation that way. I’m not sure what you’re getting at with “doing better with rendering and power saving”. Can you clarify?

Const-me 6y ago
> 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 6y ago
  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 6y ago

> 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 6y ago
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?