• Content Count

  • Joined

  • Last visited

  • Days Won


tidoust last won the day on November 16 2020

tidoust had the most liked content!

About tidoust

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Related to discoverability, I note a recent proposal for a Web Install API that would allow a website to request the installation of another website, enabling the creation of web application stores with "Install" buttons. The proposal was the topic of a breakout session during W3C TPAC end of October. The video of the presentation is available. That proposal is not targeted at games per se, but it may be worth reviewing the proposal in the context of games.
  2. "have to" probably gives too much authority to specifications but, indeed, in practice, they all ship an Opus decoder. 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.
  3. 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).
  4. A status update on WebTransport and WebCodecs: - The creation of a WebTransport Working Group is under review at W3C until end of July 2020. The group would be tasked to standardize the WebTransport API. - The shape of the WebCodecs API is actively being discussed in the WICG/web-codecs GitHub repository, including discussions such as whether to follow WHATWG Streams (current approach is to rather decouple WebCodecs from Streams), or whether to have a synchronous option for encoding/decoding.
  5. This will depend on advancement on the technical specifications and on their adoption by brower vendors and device manufacturers, but that is indeed the goal. WebGL is derived from OpenGL and is thus restricted to features that OpenGL supports. WebGPU builds on newer GPU system APIs and is also designed to be agnostic of the underlying platform technology (meaning it can be directly implemented on top of platforms such as Microsoft's Direct3D 12, Apple's Metal, and Khronos's Vulkan). Standardization-wise, the WebGPU API and WebGPU Shading Language specifications are actively being developed in the GPU for the Web Community Group. The documents should soon enter the usual web standardization process in a GPU for the Web Working Group, whose creation is currently under review within W3C.