Bugs list for web platform quality/consistency

[AshleyScirra]

Hi all,

As discussed on our call today, I said I'd bring together a list of bugs I've filed relating to the quality of the web platform (i.e. the kinds of things causing developers headaches when they run in to them). To get the ball rolling, here are a few. Please feel free to add your own, but I think we should try hard not to throw in our full bug lists - I for one have quite a few filed over the years! Let's try to keep this focused on things which will affect web development in general, cross-platform gotchas, and the like.

Chrome

• OffscreenCanvas works in Chrome, but is not supported in the WebView: crbug.com/923007
• Audio playback sometimes has unexpectedly high latency on Android: crbug.com/1014614
• WebView performance is sometimes unexpectedly worse than in Chrome. It's a difficult issue to track down and it's not clear what the cause is or if there are multiple causes, but two issues related issues are crbug.com/810928 and crbug.com/1127307
• Sometimes we see GPU driver crashes, e.g. crbug.com/1086024, and it seems really hard to get the graphics vendor to respond or act on it

Firefox

• Options for createImageBitmap aren't implemented (or fully implemented - hard to tell from the tracker) - related issue: issue 1367251. It's useful for preparing textures for WebGL upload, but because of this you have to deal with three paths: no ImageBitmap (current Safari), ImageBitmap but no options (Firefox), ImageBitmap with options (Chrome)
• You can't draw an SVG to a 2D canvas, even with the overload that specifies the width and height: issue 700533
• Support for OffscreenCanvas: issue 1390089

Safari

• createImageBitmap (issue 182424) and options (issue 202458?)
• Safari is the last browser that does not support WebM Opus audio. This is the sole reason we have to use dual encoding or ship our own WebM Opus decoder with the game. If they supported this, we would at last have one audio format that plays in all browsers. Issue 183852
• We find pretty much every iOS release breaks something. Here's the latest in our case - switching tabs breaks audio playback in iOS 14: issue 217606
• Support for OffscreenCanvas: issue 183720
• Support for WebGL 2: issue 126404 - seems to be on the way though, latest tech preview enabled it!

Edited October 20, 2020 by AshleyScirra

[Noel]

Awesome! Thanks @AshleyScirra for sharing! I will share Francois and Tom today.

[tidoust]

Thanks! Looking at it from a standardization specs perspective, I would group them in the following buckets:

• Features that are specified but not yet supported: OffscreenCanvas, createImageBitmap, SVG to 2D canvas, WebGL2. There is not much that can be done standardization-wise, apart from making sure that features do not end up in a spec unless they have reasonable support among implementors. This is also where it can be useful to document pains and needs in a Games CG report to set priorities.
• Features that break across releases: Better test suites might help although I suspect that, in most of these cases, testing the feature in isolation (which is what web platform test suites do) is not going to reveal much.
• Performance issues: Specs typically don't include performance requirements. They can still set expectations and clarify when e.g. a feature no longer makes sense if performance is poor. One recent example is the addition of "and ideally within 20ms" for the firing of cue events during media playback (see HTML spec). That may not seem like a huge change, but discussions on this triggered work to improve some implementations that were regularly firing these events every 250ms or so. Similar updates may be useful in other specs or for other features. Collecting performance issues, as done here, seems like a good starting point
• Hosted runtime definition: The WebView runtime is not specified anywhere. There are more and more games that ship either wrapped in a native shim, or within hosting applications (e.g. Facebook, WeChat). In some cases, the runtime does use Web technologies but is not even based on WebView or only expose a small number of APIs (e.g. only Canvas, no DOM). In practice, that means that all runtimes are slightly different from each other. It may be worth discussing ways to converge on a common games runtime.
• Support for specific formats/codecs: Specs often don't mandate support for specific audio, video, image, texture formats, because these formats may not have good royalty free guarantees. But that can perhaps be revisited. For instance, Opus is indeed mandated in WebRTC (see RFC 7874).

[tcmg]

Thanks Ashley! I've created a sheet here everyone:

https://docs.google.com/spreadsheets/d/1l9jfZCOuqUpx2Y0PjiVl2GHJ1nLo-XLVw8L_PyhcptI/edit#gid=0

It should be publicly visible and I've given edit access to Ashley, Richard Davey and Florian Rival.

I can share it with Unity as well.

Francois, I like your approach to categorising the issues. 

Would the WebView runtime point be listed as a separate engine do you think?

[AshleyScirra]

On 10/22/2020 at 10:47 AM, tidoust said:

Specs often don't mandate support for specific audio, video, image, texture formats, because these formats may not have good royalty free guarantees. But that can perhaps be revisited. For instance, Opus is indeed mandated in WebRTC (see RFC 7874).

If Opus is now mandated in WebRTC, all modern browsers already have to ship an Opus decoder, right?

So could the standard now also mandate Opus for <audio> / Web Audio? Would there still be opposition based on the WebM container?

[tidoust]

2 hours ago, AshleyScirra said:

If Opus is now mandated in WebRTC, all modern browsers already have to ship an Opus decoder, right?

"have to" probably gives too much authority to specifications but, indeed, in practice, they all ship an Opus decoder.

 

2 hours ago, AshleyScirra said:

So could the standard now also mandate Opus for <audio> / Web Audio? Would there still be opposition based on the WebM container?

Possibly. And possibly

The discussion would need to be brought to the WHATWG for HTML.

I note that, by charter, the Web Audio Working Group is not allowed to specify which codecs need to be supported in the Web Audio API. However, that may actually not be needed. The spec does state in the description of decodeAudioData that the "Audio file data can be in any of the formats supported by the <audio> element", so getting support in <audio> should in theory be enough.