-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HDR / WCG #20
Comments
What is the use-case for having the requested information provided? I think including too many things is something to be careful on due to fingerprinting ability. The more information there is, the more uniquely identifiable the configuration as a whole is. These two things can be properly used in sites to provide specific content to a user. However, we may want to explore alternate ways of approaching having the information depending on the use-case. For example, if it's to primarily serve a better image/video for the given monitor, it may be best to have a property request elsewhere that gives this info based on the screen the current window is on (as things currently function) rather than providing it in a generic dump of information. |
I'm not claiming I have a great use case -> just that when I played with
the api HDR seemed to me to fit in with some of the other bits of
information we were exposing ( like color profile and resolution ).
That said I can imagine some use cases outside the what asset to show on
what screen you suggested.
I'm imagining that I may have 2 monitors extending on to each other, in
which 1 is hdr and the other is not.
- I might choose to start my movie / game / image viewing on the HDR
optimized monitor and not just on whatever screen kicked off the request.
- If my screen is extended across both screens I might choose to do
something different than if both are HDR.
Jim
…On Wed, Jul 1, 2020 at 3:58 PM Jonathan Garbee ***@***.***> wrote:
What is the use-case for having the requested information provided?
I think including too many things is something to be careful on due to
fingerprinting ability. The more information there is, the more uniquely
identifiable the configuration as a whole is.
These two things can be properly used in sites to provide specific content
to a user. However, we may want to explore alternate ways of approaching
having the information depending on the use-case. For example, if it's to
primarily serve a better image/video for the given monitor, it may be best
to have a property request elsewhere that gives this info based on the
screen the current window is on (as things currently function) rather than
providing it in a generic dump of information.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/webscreens/screen-enumeration/issues/35#issuecomment-652685857>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXCYQSO5LN6SKFANWFCPITRZO5SDANCNFSM4OOCI2JQ>
.
|
I feel like this could be annoying to users. They have a window on Screen 1 while they have something critical to work on with the HDR of Screen 2. Some app they are using decides to jump screen to Screen 2 since the dev feels that is the best place for what is being done. If we allow that kind of behavior what controls would a user have to reject what the app is doing? The UX here would need to be explored. Initially my thoughts are all of really bad UXes since conveying information is already difficult. It gets even more-so when you start including technical details and there is no clear way to express the intent of the application to a user.
I'd need to see how Windows does extended desktops. I don't believe they would let one sit in HDR while the other isn't. When extended it would make sense to go with the lowest quality options to normalize across all monitors as best you can. |
I must admit to not following Screen Enumeration too closely, but I wonder if we need to consider HDR/WCG in the context of other work happening at W3C, eg., in the Media Working Group (see w3c/media-capabilities#118, w3c/media-capabilities#135), and proposals to the CSS WG (see w3c/csswg-drafts#4471)? |
While I don't have a motivating use case sufficient to the point that I think this is worth prioritizing, I don't think there is any issue with exposing this information. We explicitly put a permission prompt in front of this access to prevent sites from just accessing this information without reading it. Yes, a site that has good reason to get this permission granted could then use the information, but this is true of almost every powerful API behind a permission prompt. On top of this, this fingerprinting would certainly count as active fingerprinting that is detectable by the browser, allowing it to alert or for it to factor into things like privacy budget. |
Thanks for the question and sharing those complex discussions! At the most basic level, any HDR or video-plane properties added to the Screen interface should also be available on the respective static screen information snapshot returned through the proposed multi-screen getScreens() API. Did w3c/csswg-drafts#4471 resolve to add some new Screen properties? |
Yes, the CSS discussion there was quite lengthy, and mostly relates to TV devices where the capabilities of video rendering differ from the capabilities for graphics rendering. One option discussed was to extend Screen to add HDR and WCG attributes, but the outcome was to use media queries instead, so there's no proposal to extend Screen at this stage. Media Queries already supports 'color-gamut', so MQ level 5 proposes I'm not proposing that exposing both graphics and video capabilities is important for Screen Enumeration API. That's an even narrower use case than exposing HDR/WCG capability at all. |
Thanks. It may still be of interest to add corresponding attributes to the Screen Enumeration work, which proposes to provide information about all connected screens, beyond the single screen currently hosting the content window. Those other display device attributes could be used to inform the placement of content windows in web applications (e.g. place an image editor's color correction window on a WCG display), or to inform users in a helpful manner (e.g. let users know when another connected screen could render some content in HDR). The complexity of separate planes and capabilities for video and graphics is somewhat unfortunate. I'll leave this issue open for now, and welcome any feedback about this topic. |
I have been considering building a realtime video composer. It would be wonderful to know more about the output capabilities of the screens I am targeting, so I can understand what LUTs to apply to not to the the output. Without being able to query for this information, some users will have a bad default experience. |
Perhaps DisplayCapabilities could be used here? |
This issue came up again in W3C color group, in the context of canvas HDR support. I have been given an AI to write a proposal for allowing web applications to access detailed color and luminance information. Before writing it up, I would like some initial feedback on the idea from the people who have been thinking about the same problem from this context. Use cases & motivation:
Solution proposal
On Windows, these values would come from DXGI_OUTPUT_DESC1. The maximum SDR luminance would come from the SDR slider. On macOS, these values would come from the NSScreen. The maximum SDR luminance is always 100 nits, and the maximum HDR luminance is specified by a multiplicative factor of the maximum SDR luminance. |
This is a still valid enhancement request that merits future consideration. |
Could the screen API expose whether the screen supports HDR or some other form of WideColorGamut along with other monitor specific information?
The text was updated successfully, but these errors were encountered: