Intent to Implement and Ship: Screen.colorDepth and Screen.pixelDepth can return other value than 24

[Mounir Lamouri]

Contact emails

mlam...@chromium.org, johnp...@chromium.org

Spec

https://drafts.csswg.org/cssom-view/#screen

Summary

The Screen object is no longer required to return 24 for colorDepth and pixelDepth. It enables websites to have a better idea of the number of bits being used to display a colour on the screen.

Worth noting that CSS Media Queries such as `color` depending on the same underlying information will also start returning values other than 8 when appropriate.

Motivation

Websites that could provide high bit-depth content (e.g. HDR) may wish to query the display bit depth to ensure that the extra bits are worth sending. For example, a site may choose not to send 10-bit HDR video to a (presumably SDR) 8-bit display. This information, in addition to others, will help websites discover the device abilities and optimize content delivery.

Interoperability and Compatibility Risk

colorDepth and pixelDepth used to be allowed to return different values than 24 then the specification changed to pin them to 24 because of the low benefit and potential fingerprinting surface. The fingerprinting surface is fairly low by today’s standards and the benefit is actually greater nowadays.

Therefore, compatibility issues are unlikely. Interoperability risks are low even if they exist given that the specification requires to do a best effort to figure out the pixel depth which means that some user agents might not return the same values as others depending on the quality of implementation.

Edge: No signals.

Firefox: Public support (as in dbaron reviewed the spec change)

Safari: No signals.

Web developers: Positive

Ongoing technical constraints

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://crbug.com/701466

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5743005361242112

Requesting approval to ship?

Yes.

[Dimitri Glazkov]

LGTM1

[Jochen Eisinger]

what values other than 24 do you expect?

[Mounir Lamouri]

On Wed, 15 Mar 2017, at 07:54, Jochen Eisinger wrote:
> what values other than 24 do you expect?

Excellent question. It is mentioned in the specification and thought I
mentioned it in here too. A common case would be to return 48/16 instead
of 24/8 when we are using a 48-bit frame buffer in Chrome.

-- Mounir

[Jochen Eisinger]

Would it make sense to spec that it can be either 24/8 or 48/16?

[Mounir Lamouri]

On Wed, 15 Mar 2017, at 08:26, Jochen Eisinger wrote:
> Would it make sense to spec that it can be either 24/8 or 48/16?

I don't think so. Ideally, we should return other values when using a
monochrome device for example. There might be alternative values
(between 24 and 48) or higher values. The issues with 24 bits is that it
was "fine" for the time because pretty much all devices were using this.
I would prefer if we don't try to paint ourself on another than the
"only 24" one.

-- Mounir

[Jochen Eisinger]

oh well, lgtm2

[Chris Harrelson]

LGTM3

oh well, lgtm2

--
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+unsubscribe@chromium.org.