Every Frame Perfect
79 points by w0nder1ng
79 points by w0nder1ng
The basic premise of this article if flawed, you don't use these apps in a frame-by-frame way. Any basic animation course will teach you that how you perceive motion differs from static images. Search for a "squash and stretch" demo and you'll see frame-by-frame that the dimensions of some objects looks absurd in isolation but work beautifully in motion.
I think the point is not that the animation is ugly, it's that you have created a window of time in which you have replaced usable UI with a nonfunctional animation sequence that may even misrepresent the state of the program (as in the case of the crop example). The user just has to kind of shut off their brain for a third of a second while the UI reassembles itself before they can continue using the program.
I don't believe this is what the Wayland project means by the phrase at all.
Rather it is about lower-level technical details like resizing windows (but the content resizes asynchronously) or broken vsync (tearing or weirder diagonal artefacts, or damage reporting to rectangular sub-regions). Though it would be nice to have both the low-level details and the high-level animations, frame-perfect.
Let's say you wanted to write tests for these kinds of animations/making sure these properties don't break over time.
What are the SOTA techniques today for testing such properties for web apps and native apps? Are certain categories of tests that one would like to be able to write simply impossible/very hard because you don't control the event loop?
I can only speak for native Android apps: Using the Jetpack Compose UI Toolkit you can control the very clock that drives the UI so you can capture any part of the transition for a static screenshot test, or you can just record the whole transition itself as an Animated PNG using a tool like Paparazzi and get automated regression testing.
Ideally your sizing would be exposed, your generic layout engine would be testable in isolation, and your animations are isolated too. So you have 2 places to verify independently, then one to check the final state. The animations should be possible to drive step by step from outside rather than being fixed to the time input.
I don't quite understand your point -- are you describing the ideal application architecture/code style (that would be platform/framework agnostic), or are you talking about the needed platform support?
In practice, I haven't seen any examples of JS frameworks or ways of doing CSS animations with injected clocks. Not saying it's impossible, it's just that I don't know any examples off the top of my head.
I’m fairly sure the YouTube example is an instance of View Transitions. They’re a way of saying “when this element changes, morph it automatically” and it does result in these technically impressive but kinda mushy looking transitions where things float around and transform into each other. It’s a very cool technology that I have rarely seen look great except for minor accents upon navigation. It has to be used very, very tastefully to not be too distracting.
I think this is a really great simplification for devs to be able to reason about animations. In reality it's more about how we perceive the animation than the frame by frame shots, but I see so many apps that would really benefit from following this simple rule.
People can barely ship apps that work, it feels like a very bad idea to even talk about this, as it will cause more mis-prioritization.