Events when browser window is moved between HDR and LDR display

[kenrussell]

When a browser window moves between a display supporting HDR and one which doesn't, should an event be dispatched in order to tell applications that could respond to that change in capability?

gpuweb/gpuweb#1231 raises this question; it's come up in other venues before too.

If the rendering is going to an OffscreenCanvas rather than an HTMLCanvasElement, for example, what should the event target be?

CSS Media Queries support querying the color gamut: https://www.w3.org/TR/mediaqueries-4/#color-gamut . Is there already a pattern for dispatching events upon changes to the results of media queries?

[kainino0x]

One thought I had about this: The browser should probably receive a signal that the application intends to handle this. If it doesn't receive such a signal, then the browser should report HDR capability regardless of the current screen (if there's an HDR display attached - at the time the page is loaded, I guess) and the browser should handle conversions to all displays. That way, handling this event is (hopefully?) purely a power optimization, and if ignored still produces good results. It also would make actually adding such an event lower-priority (since it would be for power only).

[kenrussell]

Good thought. Presumably registering for the event would be a signal that the application intends to respond to it.

[svgeesus]

Since the canvas is set up once and then all rendering and compositing happens in the contet as originally set up, it seems that dragging a window from SDR to HDR displays would result in:

• the contents of the existing canvas are rendered to an image
• a new context is set up with the HDR flag enabled
• the previously saved image is rendered to the new context
• carry on writing

So, because contexts are being opened and closed, an event should fire to allow this handoff to happen (either automatically or, more likely, programmatically)

[kdashg]

I think an event is good but it should be orthogonal to accurately presenting any given combo of sdr/hdr.
An event could tell you that you may want to upgrade/downgrade, but apps that take no action there should continue to get our (agreed-upon) best-effort for display on the differing displays. (Avoid trying to handle content spanned across displays. Perfect is the enemy of the good here)

I think this is similar in nature to devicePixelRatio, actually. Content written naively should Just Work, but it should also be possible to do The Right Thing.

I'm curious what Video decided to do here, since I believe a common solution is shipping there already.

[kenrussell]

Canvas rendering contexts - WebGL in particular - can not reallocate the back buffer with a different configuration without the application being aware of that, and participating in the process. State such as intermediate multisampled rendering results can not be reconstituted into a different drawing buffer format. Agree with an event notifying the application, but not trying to automatically reconfigure the canvas contexts.