On 5/14/18 3:18 PM, Jean-Yves Avenard wrote:
The most obvious choice considered was to provide identical information to what
the existing canPlayType information provide: that is not providing extra
details.
OK. All I'm saying is that this needs to be sorted out before we ship.
I would invite you to submit such bug and concern you have on the wicg site:
https://github.com/wicg/media-capabilities/issues
I can do that, sure. Figured I'd check whether these issues had been
considered yet first. Filed
https://github.com/WICG/media-capabilities/issues/82
Having said that, with hardware decoders, typically whatever you may be doing
has no impact on performance: it’s a dedicated circuit (even if for some
there’s a limit on how many decoders can be used at the same time).
Sure; the question is what happens when the decoders are not hardware.
4) For the "change" event on Screen, does that apply to any property defined in
any specification, not just the properties defined in this specification? That would be
a pretty significant monkeypatch in its own right. It would be better if whatever
specifications define properties also define what events fire if those properties change.
I’m not sure I understand your question. onChange and the change event is only
defined for the Screen interface
(https://drafts.csswg.org/cssom-view/#the-screen-interface).
Yes... For which properties of that interface? For example, should it
fire for changes to availWidth? Changes to pixelDepth?
Or you’re suggesting that as the MediaCapabilities Screen extension is only
about gamut and luminance, each should get its own event so that future
extension to the Screen interface do no conflict?
I don't have a strong opinion on that, though having a single "change"
event mean "yeah, one of these N things changed" is not that great; then
you have to re-poll all those N things to figure out which one changed.
But my real objection is that the MediaCapabilities spec is currently
saying that changes to _any_ property on Screen, defined by _any_
specification, necessitate a change event to be fired. That is a pretty
severe constraint on what other specifications can expose on Screen, no?
In particular exposing anything that the OS doesn't notify on changes
for and is somewhat expensive (whatever that means) to query the OS for
would suddenly become a non-starter.
-Boris
_______________________________________________
dev-platform mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-platform
