Hacker News Reader

Comment by 0x70dd | Hacker News Reader

If I understand correctly, Flutter embedders use a low level rendering API that renders the UI similar to how a game is rendered - skipping native widgets altogether. This makes me wonder what's the battery consumption? Is it similar to electron?

View on HN

Jumping onto this: what about accessibility? On iOS at least, if you use the native controls you get a ton of accessibility support either for free or with relatively little effort. VoiceOver has some really deep hooks into the system.

How, if at all, does this work with Flutter? Seems like it would be like trying to get a screen reader to describe a game.

Flutter apps, from the basic one I've built and tried, are completely inaccessible to Talkback on Android.

I don't think this is supposed to be the case, from reading the documentation. But I can't get any labels inside my application to be read aloud.

I've just tried this on my apps which I've done no accessibility work yet. It's not perfectly accessible (would need to add some annotations to some text) but they are mostly accessible

> This makes me wonder what's the battery consumption? Is it similar to electron?

what makes you think that native widgets are the most efficient ? in the end what matters is how slim are your GL calls.

Native UI toolkits (with “native” defined as system standard) have system hooks and access to functionality that third party toolkits don’t. Not sure about Android but on iOS I’m pretty sure that a Flutter app would have a battery impact closer to that of a 2D game than a traditional app, even if it’s reasonably efficient.

Games tend to animate all the time at 60 fps. That drains battery.

Flutter is more like a regular UI in that it animates, but stops when idle. Though you could write a game in it.

> Native UI toolkits (with “native” defined as system standard) have system hooks and access to functionality that third party toolkits don’t

what makes you think that ? the time when scrollbars were rendered in-kernel is long gone.

I believe the current situation is that first-party toolkits have much more insight into the OS and underlying platform than third-party developers can afford.

And I don't think that this is true. First party toolkits do the very same GL calls in the end than a third party would.

I would expect it to be similar to native widgets. After all, native widgets still need to be rendered somehow.

Native widgets on iOS are rendered with the system compositor, Core Animation. If you render everything yourself into a GL or Metal context then you have to blit everything to the context, and then Core Animation blits your buffer to the screen. (This may be bypassed in full screen mode; I don't know. But in any case if you are using native widgets at all then you have this extra blit.)

This is a significant power consumption concern.

Not knowing anything about this, are there any numbers on the power consumption of that extra blit?

I can't imagine it actually blits, it probably swaps buffers like everything since 2000.

No, it blits. Buffer swap doesn't work because Core Animation owns the entire scanout buffer. iOS apps don't have access to it.

Reply on news.ycombinator.com