
How Flutter uses Widgets, Elements, RenderObjects to create eye-candy at 120fps - yannikyeo
https://medium.com/flutter-community/the-layer-cake-widgets-elements-renderobjects-7644c3142401
======
klohto
Last time an article about Flutter was posted, several users showed concerns
that this is a campaign to promote the product. I'm starting to lean into this
theory more and more.

Articles like these bring nothing to the table and look out of place for HN.

Putting on my tinfoil hat, I'm concerned about the ratio of likes and comments
as well.

~~~
xpaulbettsx
People excited about X submit articles about X, is this surprising?

> Articles like these bring nothing to the table and look out of place for HN.

This is a reasonable technical article on how one framework implements
rendering and manages to achieve a pretty high bar for performance, not at all
out-of-scope for HN.

------
IshKebab
Flutter seems great, but so far it definitely does not achieve perfect 120 fps
performance. It still drops frames quite often at 60 fps. It's getting better
but I don't think it is up to iOS performance levees yet.

~~~
saagarjha
I doubt it will get there anytime soon. UIKit still has APIs designed back
when iPhone was clearly underpowered (for example, UITableViews still deque
cells), so it really performs well on new hardware.

~~~
kitsunesoba
I mean, is dequeueing cells ever a bad idea, regardless of available power? In
AppKit on macOS, NSTableView and NSCollectionView still dequeue even though
computers have been exceedingly powerful for decades now. It’s slightly more
tricky to work with as a developer, but it’s not that hard and saves resources
that’d be better spent elsewhere.

------
skybrian
Wait, why should we care about 120hz? It seems like 60hz should be good enough
for people who aren't professional gamers?

I wonder how much battery life could be saved by turning the refresh rate down
to 30hz?

~~~
ghusbands
The most obvious difference for most people is to how readable text is while
it is moving, and how fast it can move while still being readable. For touch
interfaces, this is important, as people do read while pushing things around.
In essence, anything above a pixel per frame is not very readable. So at
30fps, text is only readable when moving at less than 30 pixels per second (60
for hi-DPI). At 120fps, you can move everything four times faster and still
have it look sharp.

You could expand your knowledge greatly by visiting blur busters [1]. It is
trivial for humans and cameras to see the difference between 60Hz and 120Hz
motion [2], especially when tracking motion. When we were all on CRTs, the
difference was much less noticeable, give or take flicker sensitivity, because
they display things in pulses. Most modern displays will hold the image until
it changes, which any tracking visual system (eyes or camera) will see as
smearing. You can see images of this at blur busters.

A lot of often-cited sufficient-for-everything frame rates are incorrect.
24fps is claimed to be sufficient for motion for cinemas, but it only works
with heavy motion blur and a lack of fast camera sweeps. 30fps is claimed to
be sufficient for games, but it impacts reaction times, input lag and blur in
motion. 60fps is claimed to be sufficient for games, next, but it stopped
being so when we stopped using CRTs (visit blur busters for more detail).
We're now at 120fps for many things and it's almost good enough.

[1] [https://www.blurbusters.com/](https://www.blurbusters.com/) [2]
[https://www.blurbusters.com/faq/60vs120vslb/](https://www.blurbusters.com/faq/60vs120vslb/)

~~~
skybrian
This is good information, but to quibble, "noticeable" does not mean "not good
enough". Being able to notice a difference doesn't mean it matters to the
user; that's more subjective and both versions might be considered fine by
many users.

For example, I'd be surprised if most users would care about reading text
while moving it quickly. (Well, maybe they would care with sufficient
advertising?)

------
yen223
Correct me if I'm wrong, but this sounds almost exactly like how React works
under the hood. Which I suppose goes a long way to explaining why the Flutter
API resembles React's a lot.

Not a knock, I really like the React approach to building UIs.

