Intent to Ship: CapturedSurfaceResolution
Chromestatus
Contact emails
agp...@google.com, gui...@chromium.orgExplainer
https://github.com/guidou/mediacapture-extensions/blob/main/explainer-pixels.mdSpecification
https://w3c.github.io/mediacapture-screen-share/#dfn-screenpixelratioSummary
Expose pixel ratio of the captured surface while screensharing. This feature will help applications to conserve their system resources or adapt the quality/bandwidth trade-off according to the physical and logical resolutions of the captured surface.
Blink component
Blink>MediaStreamTAG review
https://github.com/w3ctag/design-reviews/issues/1060TAG review status
PendingRisks
Interoperability and Compatibility
Interoperability risk is relatively low. The main risk is that other browsers do not implement the feature. However, since the feature is a small addition to an existing spec and it has consensus across browsers, it is possible that it will be implemented. There is no compatibility risk as the feature is strictly additive and orthogonal to existing features.
Gecko: Positive (https://github.com/w3c/mediacapture-screen-share/pull/315) Since this is a minor addition to an existing spec, no official position was requested as it would have been closed without response. The provided link points to the PR where Firefox's representative was supportive.
WebKit: Positive (https://github.com/w3c/mediacapture-screen-share/pull/315) Since this is a minor addition to an existing spec, no official position was requested as it would have been closed without response. The provided link points to the PR where Safari's representative approved.
Web developers: No signals
Other signals:
Ergonomics
No risks identified.
Activation
No risks identified.
Security
This feature exposes the pixel ratio of the screen being captured. This type of ratio is already exposed in other APIs, but it was not possible to tie a capture to the ratio of the screen being captured. The ratio is exposed only while the capture is active, and the capture requires explicit permission from the user.
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
N/A
Debuggability
N/A
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
NoWill be supported for Windows, Mac, Linux, ChromeOS but not for Android and Android WebView as they don't support the getDisplayMedia API, which is the base for this feature.
Is this feature fully tested by web-platform-tests?
YesFlag name on about://flags
Finch feature name
CapturedSurfaceResolutionRequires code in //chrome?
FalseTracking bug
https://g-issues.chromium.org/issues/383946052Launch bug
https://launch.corp.google.com/launch/4382372Availability expectation
Feature is available only in Chromium browsers for the foreseeable future. However, since the feature is small and has consensus across browser vendors, it might become available in other browsers.Adoption expectation
Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome.Estimated milestones
| Shipping on desktop | 136 |
Anticipated spec changes
Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).
N/ALink to entry on the Chrome Platform Status
https://chromestatus.com/feature/6738236535472128?gate=5004697808928768
Guido Urdaneta
Vladimir Levin
Interoperability risk is relatively low. The main risk is that other browsers do not implement the feature. However, since the feature is a small addition to an existing spec and it has consensus across browsers, it is possible that it will be implemented. There is no compatibility risk as the feature is strictly additive and orthogonal to existing features.
Gecko: Positive (https://github.com/w3c/mediacapture-screen-share/pull/315) Since this is a minor addition to an existing spec, no official position was requested as it would have been closed without response. The provided link points to the PR where Firefox's representative was supportive.
WebKit: Positive (https://github.com/w3c/mediacapture-screen-share/pull/315) Since this is a minor addition to an existing spec, no official position was requested as it would have been closed without response. The provided link points to the PR where Safari's representative approved.
Guido Urdaneta
LGTM1Interoperability risk is relatively low. The main risk is that other browsers do not implement the feature. However, since the feature is a small addition to an existing spec and it has consensus across browsers, it is possible that it will be implemented. There is no compatibility risk as the feature is strictly additive and orthogonal to existing features.
I assume that this can be feature detected (as presence or absence of the information) and in non-supporting browsers, the app would fall back to whatever the current behavior is. Is that a reasonable approach for developers?
Gecko: Positive (https://github.com/w3c/mediacapture-screen-share/pull/315) Since this is a minor addition to an existing spec, no official position was requested as it would have been closed without response. The provided link points to the PR where Firefox's representative was supportive.
WebKit: Positive (https://github.com/w3c/mediacapture-screen-share/pull/315) Since this is a minor addition to an existing spec, no official position was requested as it would have been closed without response. The provided link points to the PR where Safari's representative approved.I would typically err on the side of filing a position request regardless of the size of the feature. I don't believe it's common that these would be closed without a response. However, in this specific case I agree that the approval and comments on the pull request seem to be sufficient evidence of support.
Thanks,Vlad
Alex Russell
Daniel Bratell
LGTM3
/Daniel
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f52e5637-6e42-4181-9067-e01d3990c173n%40chromium.org.