[cssom-view] Make colorDepth/pixelDepth return useful information again

[mounirlamouri]

Context: this is related to the Screen interface, in particular the colorDepth and pixelDepth

Some bug history:

• https://www.w3.org/Bugs/Public/show_bug.cgi?id=17522
• https://www.w3.org/Bugs/Public/show_bug.cgi?id=14071

I am suggesting that we do the following changes:

• colorDepth and pixelDepth continue to return the same value;
• colorDepth and pixelDepth should return the number of bits allocated to colors on the output device or an approximation to the best of the UA's knowledge;
• 24 is to be used as a default value for privacy considerations or when the UA can't find the value;
• the color MQ should return a consistent values with colorDepth and pixelDepth (eg. 8 when the properties return 24 or 10 when 30 is returned by the properties)

We could also recommend 24 to be used if the value would be below 24. However, Blink already exposes monochrome in the color MQ so there might be benefit of keeping consistency between APIs in some cases where the value would be below 24.

The purpose for this change is for websites to be able to detect whether it is worth providing content that would require high color depth output.

The main concern would be fingerprinting. The treat seems fairly weak compared to the current fingerprinting surface on the Web. It will most likely add one or two bits of entropy (24/30/48) which can probably be linked to other properties of the display (CSS color gamut, screen size, etc), thus likely reducing the practical benefit for fingerprinting.

[smfr]

I'd like to see concrete use cases for returning "correct" numbers for these properties. I'm not convinced that you can collapse all the complexity of rendering and color management into one pixel bitcount that will be useful to anyone. For example, you can have wide color with an 8-bit-per-component format. You can also have textures that use half-float pixel formats. Throw HDR into the mix and things get very complex.

I would prefer that we go with things like the color-gamut media query, which are useful for answering specific questions.

[FredrikHubinette]

When deciding if you should show the user an HDR or SDR video, you need to know that the output device has a (a) wide enough gamut (b) good enough contrast & brightness and (c) enough bits to represent the HDR data. That last part is what this will address.

[mounirlamouri]

To add more context, Blink is shipping the color-gamut MQ and we are looking into the contrast/brightness feature as part of our Media Capabilities work.

[zcorpan]

We discussed this on the telecon yesterday, see
https://logs.csswg.org/irc.w3.org/css/2017-02-01/#e768945

In particular we were a bit confused about what use case this tried to address (maybe the above 2 comments clarify that a bit). The spec also needs to be very clear about what should be returned where there the "logical" amount of bits is different to actual amount of bits allocated because of dithering or memory layout etc. And the spec should have text/examples for how to use this and when not to use it.

[mounirlamouri]

@zcorpan I've added an example in the PR: #994

I'm not sure what you meant by the difference between logical and actual amount. I'm happy to clarify that if you can give more details.

[zcorpan]

From the minutes

@dbaron: I think...I'm fine with this being useful as long as the spec is clear what the value means. Some impl were returning what the bit depth was semantically before the hard code and some were returning number of bits in the memory layout that the graphics card liked
@dbaron: There are some context where when you have rgb data you back a bite of r, of g, of b. THere are some context where you want 32 bites aligned. Sometimes this differs per video driver. Some impl exposed this.

@svgeesus: bits per component vs bits per pixel. spec needs to be clear.
@svgeesus: also for 5-6-5 red green blue = 16