4 ms·

> figuring out when to redraw (...) sections of it What happens if you just brute-force and re-render everything when there's a change? I'm all for optimizing

> figuring out when to redraw (...) sections of it What happens if you just brute-force and re-render everything when there's a change? I'm all for optimizing but is this really required these days? Even considering laptops and mobile power requirements, rendering off-screen and flipping is lightning fast. Layout flows are a different matter and can be expensive to compute.

kaba0 4y ago
> Even considering laptops and mobile power requirements, rendering off-screen and flipping is lightning fast I believe it is not speed, but battery life. Most of the time nothing happens on the screen besides some small widget changing like once per second (e.g. clock), doing 59 full rerenders every second for that (or even more with high refresh rate screens) is significantly higher drain. But I am absolutely not an expert on this.
- wolframhempel 4y ago
  I think that's right. I started of just rendering everything on every requestAnimationFrame callback - and things rendered smoothly, especially when nothing needed copying to the GPU. But users complained that their laptop fans sprang into action and their battery life plummeted.
- Strom 4y ago
  Your point is correct and there is another changing thing beyond the clock that's common - the blinking caret in a textbox. Firefox used to have really bad battery usage on macOS for a long time because in order to only change the caret you have to do a lot of things the Apple way.
  - kaba0 4y ago
    Oh didn’t think of that! When you are more in control of the hardware then hardware planes could help with that - at least cursors in display managers are handled that way. Does native OS frameworks have some escape hatch for these slightly changing, constantly damaging elements?
seba_dos1 4y ago
> I'm all for optimizing but is this really required these days? Of course it is. Even if it doesn't matter on your machine, your users will launch your code: * on a 10 years old PC * in train on a laptop with 10% battery left * on a computer with so many things running in the background that you'll be on the edge of thrashing * on a thermally throttled ultrabook * on an underpowered SBC * through foreign CPU arch emulation * [insert more cases here] In each of those scenarios, your code will either do its job well or be the source of frustration.

kaba0 4y ago

> Even considering laptops and mobile power requirements, rendering off-screen and flipping is lightning fast I believe it is not speed, but battery life. Most of the time nothing happens on the screen besides some small widget changing like once per second (e.g. clock), doing 59 full rerenders every second for that (or even more with high refresh rate screens) is significantly higher drain. But I am absolutely not an expert on this.

wolframhempel 4y ago
I think that's right. I started of just rendering everything on every requestAnimationFrame callback - and things rendered smoothly, especially when nothing needed copying to the GPU. But users complained that their laptop fans sprang into action and their battery life plummeted.
Strom 4y ago
Your point is correct and there is another changing thing beyond the clock that's common - the blinking caret in a textbox. Firefox used to have really bad battery usage on macOS for a long time because in order to only change the caret you have to do a lot of things the Apple way.
- kaba0 4y ago
  Oh didn’t think of that! When you are more in control of the hardware then hardware planes could help with that - at least cursors in display managers are handled that way. Does native OS frameworks have some escape hatch for these slightly changing, constantly damaging elements?

seba_dos1 4y ago

> I'm all for optimizing but is this really required these days? Of course it is. Even if it doesn't matter on your machine, your users will launch your code: * on a 10 years old PC * in train on a laptop with 10% battery left * on a computer with so many things running in the background that you'll be on the edge of thrashing * on a thermally throttled ultrabook * on an underpowered SBC * through foreign CPU arch emulation * [insert more cases here] In each of those scenarios, your code will either do its job well or be the source of frustration.