I remember trying to figure out why video playback was so horribly slow in Chrome on an ARM device. Streaming the video with mplayer would take around 60% CPU time (out of 400%), but playing it in Chrome it would max out at 400% and start dropping frames.

In the end the answer was that each video frame had to be copied between buffers about three times with Chrome, among other things, whereas mplayer was able to draw directly to the framebuffer.

Now I'm not saying it isn't theoretically possible to make this fast (and Chrome has various optimizations nowadays for a select number of platforms), but abstractions can be expensive - especially for video.

It's best to go as native as possible if you're on underpowered hardware or want to go easy on your user's battery life.

Google has the ability to just change chrome to make it work.

The native app uses Flutter [0].

Disclosure: I work on Stadia, and am speaking only for myself.

[0] https://9to5google.com/2019/11/08/google-stadia-app-play-sto...

Are you still using a web view ?

Because obviously then it would be irrelevant whether it's Safari, Flutter or Visual Basic.

The native mobile app does not use a web view.

The Flutter webview is fairly basic, I believe.

No one uses web view anymore. It’s banned.

Ehhh, there is a big difference between streaming some Netflix show that has no input and can buffer minutes or more and a game where even 500ms of buffering are unplayable. Plenty of streaming protocols aren't designed to do that in the first place (hello, HLS) and I could very well imagine players just falling over if they are not in their happy place of usual buffer sizes.

I haven't seen such issues with webrtc. It's been very low latency for my use cases.

Unlikely - web video isn't designed for extremely low latency. Much easier to do if you control the whole stack.