3 ms·

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

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.

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.