3 ms·

I agree. Every Flutter app I've ever used has been noticeably janky. The absolute worst is the UI for the Google Home Hub which runs at about three frames per s

I agree. Every Flutter app I've ever used has been noticeably janky. The absolute worst is the UI for the Google Home Hub which runs at about three frames per second and is incredibly unresponsive to touch and button input. It's as frustrating to use as the touchscreen navigation system displays in old cars, the ones with resistive touchscreens. I like a lot of things about Flutter, but how did they develop a completely new UI framework from scratch in 2015 and not make fluid animations and fast touch response latency an absolute priority?

ardit33 5y ago
I interviewed with one of the flutter engineers. After a casual talk with him on how they were doing the rendering, while interesting, I had a feeling that fluter will fail. It reminded me a bit of all the HTML 5.0 on mobile efforts back in 2011-2014, which mostly failed. (React Native, was an offshoot of those earlier efforts, but even that is being slowly abandoned by the industry now). That's what you get your company hires only leetcoders. Sometimes domain expertise comes at expense of general expertise. (some people are super strong in one area, but not so in others). Google hires generalists, which are good at the small leetcode style problems given during an interview, but which surprise surprise are not super strong at design well thought out rendering techniques. Hence the continuous failures in many new products.
- heavyset_go 5y ago
  > not super strong at design well thought out rendering techniques. Can you expound on this?
pkphilip 5y ago
It may have something to do with the fact that Flutter state management of the UI requires the UI to repaint completely whenever there is a change. This makes no sense whatsoever because it goes exactly in the opposite direction of optimised graphics programming - where the ideal was to repaint the smallest portion of the screen as possible for any change.
- modeless 5y ago
  No, that's not right. Optimizing repaint rectangles is kind of a corner case these days. It's a nice feature to have in some cases for reducing battery usage, but if you're relying on it to hit 60 FPS then you are certain to fail because there are always cases where you do have to repaint the whole screen. If you can't do that at 60 FPS you're already screwed. Games redraw everything every frame, and yet good games have much better performance than UI toolkits generally.
  - pkphilip 5y ago
    Just curious but isn't the whole point of using techniques such as double buffering meant to reduce the time it takes to make an update to the screen? wouldn't that actually enable higher FPS? Why would you draw an entire screen when you could repaint just a small portion of it?
    - modeless 5y ago
      Double buffering prevents the user from seeing a half painted buffer. Instead of having the application draw directly to the screen buffer, the application draws to an offscreen buffer and the buffers are swapped only after drawing is finished. It's orthogonal to whether you do full or partial updates. (Although if you do partial updates then you're not really swapping the whole buffer, you have to do a blit to present instead and that can actually be less efficient than swapping if the swap path is really swapping, say if you're in fullscreen exclusive mode or if hardware overlays are in use). And it can only ever increase the time it takes updates to reach the screen, not decrease it, since it adds an extra step (swapping) compared to drawing directly on the front buffer. Why would you draw the entire screen? Well, it instantly eliminates a whole class of bugs where partial updates don't match full updates. It eliminates a ton of really complex code you'd otherwise have to write to track the on-screen size of arbitrary changes separately from painting them, and skip things outside the dirty rectangle while painting. And it doesn't change your worst case performance, which is what you care about when trying to hit a fixed frame rate. Actually the worst case performance should be slightly better because you're not wasting time tracking changes when you have to paint the whole screen anyway. So the question really is, why would you bother to implement partial updates? The only real reason would be to save power in scenarios where only a small part of the screen is changing. Which is important but not that related to responsiveness or animation smoothness, which again are about worst-case performance. Even if you do want partial updates you may be better off simply special casing a few common things like blinking cursors or video playback than implementing a fully general change tracking solution.

ardit33 5y ago

I interviewed with one of the flutter engineers. After a casual talk with him on how they were doing the rendering, while interesting, I had a feeling that fluter will fail. It reminded me a bit of all the HTML 5.0 on mobile efforts back in 2011-2014, which mostly failed. (React Native, was an offshoot of those earlier efforts, but even that is being slowly abandoned by the industry now). That's what you get your company hires only leetcoders. Sometimes domain expertise comes at expense of general expertise. (some people are super strong in one area, but not so in others). Google hires generalists, which are good at the small leetcode style problems given during an interview, but which surprise surprise are not super strong at design well thought out rendering techniques. Hence the continuous failures in many new products.

heavyset_go 5y ago
> not super strong at design well thought out rendering techniques. Can you expound on this?

pkphilip 5y ago

It may have something to do with the fact that Flutter state management of the UI requires the UI to repaint completely whenever there is a change. This makes no sense whatsoever because it goes exactly in the opposite direction of optimised graphics programming - where the ideal was to repaint the smallest portion of the screen as possible for any change.

modeless 5y ago
No, that's not right. Optimizing repaint rectangles is kind of a corner case these days. It's a nice feature to have in some cases for reducing battery usage, but if you're relying on it to hit 60 FPS then you are certain to fail because there are always cases where you do have to repaint the whole screen. If you can't do that at 60 FPS you're already screwed. Games redraw everything every frame, and yet good games have much better performance than UI toolkits generally.
- pkphilip 5y ago
  Just curious but isn't the whole point of using techniques such as double buffering meant to reduce the time it takes to make an update to the screen? wouldn't that actually enable higher FPS? Why would you draw an entire screen when you could repaint just a small portion of it?
  - modeless 5y ago
    Double buffering prevents the user from seeing a half painted buffer. Instead of having the application draw directly to the screen buffer, the application draws to an offscreen buffer and the buffers are swapped only after drawing is finished. It's orthogonal to whether you do full or partial updates. (Although if you do partial updates then you're not really swapping the whole buffer, you have to do a blit to present instead and that can actually be less efficient than swapping if the swap path is really swapping, say if you're in fullscreen exclusive mode or if hardware overlays are in use). And it can only ever increase the time it takes updates to reach the screen, not decrease it, since it adds an extra step (swapping) compared to drawing directly on the front buffer. Why would you draw the entire screen? Well, it instantly eliminates a whole class of bugs where partial updates don't match full updates. It eliminates a ton of really complex code you'd otherwise have to write to track the on-screen size of arbitrary changes separately from painting them, and skip things outside the dirty rectangle while painting. And it doesn't change your worst case performance, which is what you care about when trying to hit a fixed frame rate. Actually the worst case performance should be slightly better because you're not wasting time tracking changes when you have to paint the whole screen anyway. So the question really is, why would you bother to implement partial updates? The only real reason would be to save power in scenarios where only a small part of the screen is changing. Which is important but not that related to responsiveness or animation smoothness, which again are about worst-case performance. Even if you do want partial updates you may be better off simply special casing a few common things like blinking cursors or video playback than implementing a fully general change tracking solution.