Closed Bug 1196412 Opened 4 years ago Closed 4 years ago

360 Video content not rendering left/right viewport correctly.


(Firefox :: Untriaged, defect)

43 Branch
Not set



Firefox 43
Tracking Status
firefox43 --- fixed


(Reporter:, Assigned: kip)


(Whiteboard: [webvr])


(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2478.0 Safari/537.36

Steps to reproduce:

Using Firefox Nightly + VR addon (

(vrvid1.jpg screenshot)
Clicking the VR goggles to open in VR mode.

(vrvid2.jpg screenshot)
Press 'F' to enter VR mode

(vrvid3.jpg screen)
Press 'f' to enter VR mode.
* Same Elevr player as vrvid2.jpg example.

Actual results:

Viewport left/right viewports offset and cropped.

Expected results:

Should get full coverage of video and proper left/right split into the viewport.
This issue only appears to be present only for 360 video.   Other demos on continue to work properly.
Whiteboard: [webvr]
Flags: needinfo?(matt.woodrow)
Flags: needinfo?(matt.woodrow) → needinfo?(jgilbert)
Chatted w/ Matt on IRC and he recommended pinging Jeff Gilbert.

My theory: the content is being display at it’s native resolution, instead of scaled to fit the display it’s running on. Viewing clips of different sizes [or] entering VR mode on displays of varying resolution both impact the texture offset.

Casey adds:

> Could be that the viewport dimensions are not being reported correctly.   It seems that the canvas element itself is sized correctly
> the context also reports back the right dimensions

This bug may be related? and work well on my Mac Nightly build. But the demos from will be black while enable fullscreen and click-moving my mouse.
This issue is not specific to video.  It occurs any time the canvas element's "Width" and "Height" attributes do not match the screen dimensions.

Tracing with OpenGL Profiler revealed that the canvas element was indeed creating a render buffer as expected with the dimensions set by the "width" and "height" attributes.  Capturing this buffer showed that the scene was in fact correctly rendered at the full Oculus optimal resolution.  During the copy to an intermediate buffer, this buffer was sampled incorrectly, resulting in an incorrect scale and misalignment with the eye distortion.

This incorrect scaling and misalignment does not occur when the "Width" and "height" attributes are set to match the size of the canvas element's outer dimensions.  You can set the "width" and "height" attributes to match as a workaround; however, this will result in a lower quality output.

I'll take this bug and implement a platform fix.
Assignee: nobody → kgilbert
Marking as new, as issue has been confirmed.
Ever confirmed: true
Bug 1196412 - Correctly scale canvas layers that have a transform applied to fill the screen
Attachment #8652044 - Flags: review?(vladimir)
WebVR specific code in ContainerLayerComposite did not handle transforms applied to the canvas element layers.

Internally, layers that represented canvas elements with a buffer with larger dimensions than their CSS size had a transform applied to reduce their size.

The WebVR code already has code to fix the size of the elements to fill the display by adjusting their transforms; however, this code did not calculate the existing bounding boxes of the elements correctly due to ignoring the transform on the layer.

The patch I have added for review transforms the bounds of the container's child layers by their transform.
Comment on attachment 8652044 [details]
MozReview Request: Bug 1196412 - Correctly scale canvas layers that have a transform applied to fill the screen

Looks good, but can you confirm that it works properly for non-canvas layers as well?  That is, does GetEffectiveVisibleRegion already transform by childTransform?
Attachment #8652044 - Flags: review?(vladimir) → review+
Bug 1196412 - Correctly scale canvas layers that have a transform applied to fill the screen, r=vlad
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 43
Flags: needinfo?(jgilbert)
You need to log in before you can comment on or make changes to this bug.