[Webkit-unassigned] [Bug 221225] Implement WebXR getViewerPose and getPose

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=221225

--- Comment #17 from Imanol Fernandez <ifernandez at igalia.com> ---
(In reply to youenn fablet from comment #16)
> If you want to keep the design of using only WebXRSession ref, you will need
> to keep all spaces in WebXRSession (see how XMLHtppRequestUpload uses the
> ref/deref mechanism I mentioned before).
> 
> Looking further the spec (I am not familiar with it), there is not a 1-1
> relationship between session and space.
> - Spaces always need a reference to their session. I think having a
> Ref<WebXRSession> is good.
> - One space, the viewer space, is creating a circular reference as its
> session needs to ref it.
> 
> It is not totally clear to me whether the viewer space is exposed somehow to
> scripts.
> 
> One possibility would be to have the session keep a WeakPtr<> of the viewer
> space if it is easy to recreate it as needed.
> Another possibility is for the viewer space to be a different class, not
> refcounted at all, but fully owned by the WebXRSession as a unique_ptr.

The viewer space owned by the WebXRSession is not exposed to script. It's only used in WebXRFrame::getViewerPose().

Another option would be to create a separate populatePose method in WebXRFrame for getViewerPose calls. That would avoid creating a new class at all or the ref/deref proxy solution but at the cost of some code reusability in WebXRFrame::populatePose();

Thinking more about the pros/cons of all the 4 solutions I like the one about creating a separate class for viewer space:
- It's simpler to understand than the ref/deref proxy solution.
- It doesn't require to recreate the viewer space if WeakPtr<> is not alive. XRFrame::getViewerPose is tipically called once per frame so I prefer to avoid allocations as much as possible
- It allows us to reuse the WebXRFrame::populatePose() logic.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210216/60205c1d/attachment-0001.htm>