| > 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. |
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.