Every other sample takes the display as it finds it. This one asks it questions — how big is the panel, in metres and in pixels, and what rendering modes can the runtime put it in — and then asks it to change: a different rendering mode, or just the rendering mode. There is no separate 2D/3D control: asking for a one-view mode is what puts the panel's hardware display state flat, and asking for the two-view mode is what brings it back.
| not read yet |
The panel's hardware display state is a consequence of the
active rendering mode, not a knob: request a mode with viewCount 1 and the
browser puts the panel flat and reports that mode active — while the runtime carries on
weaving the same fixed two-view atlas. So the SDK zeroes every window's
ipdFactor/parallaxFactor when that mode goes active,
off the renderingmodechange event rather than off the request: this page's
render loop never changes, and a refused request changes nothing at all. The badge above
is read-only — it shows what the display reported.
setStereoEnabled(false) is sugar for exactly one thing: the
first requestable viewCount 1 mode in the table.
The mode list is the display's, not the browser's. There is no view
synthesis anywhere in this stack, so the browser renders exactly two views and a mode
needing more than two is listed (it is real, the panel can do it) but greyed —
requestRenderingMode refuses it with a TypeError. A
one-view mode is requestable: the browser still submits two views and the runtime
still weaves them, it is the panel that goes flat.
viewScaleX/Y and recommendedViewScaleX/Y are
advisory: the browser cannot resize your canvas. A page honours them by
sizing its own backing store — which is what this sample does on every
renderingmodechange.