-
Notifications
You must be signed in to change notification settings - Fork 23
Why does synced_frame_data
take a &self
rather than a &mut self
?
#53
Comments
There is a clash between
As far as I can tell, the only option is to use a mutex, so this API makes it difficult to provide a lock-free implementation. |
Sigh, or do what the Oculus implementation does:
|
I assumed that The idea was that |
Hmm, the problem with that is that In fact, this raises a related question, which is why |
They are separate methods mostly to:
It's true that in practice we have not ended up using those scenarios so I'm ok with unifying the methods and simplifying the API.
Yes, it's a read-only operation on all the SDKs implemented at the time |
@MortimerGoro Is the reason why I'm hitting this for the ML1 (and it's not come up for the other implementations) the ML1's requirements about which methods run on the main thread? How bad would it be if the display.near = 1;
display.far = 10;
display.getFrameData(frame_data); Is the Asking because if |
@asajeffrey Yes, I think we are good if we avoid the requirement of using the latest near and far values from the current RAF. For 2 reasons:
|
OK, in which case should the API for the setters and getters for near and far be split off from the API for getting the frame data? |
We could do that. Normally near and far are set once before starting a WebVR session |
When servo uses a
VRDisplay
it has&mut
access to it, so we could makesynced_frame_data
and friends take&mut self
arguments rather than&self
. This would remove some unnecessary uses of interior mutability.The text was updated successfully, but these errors were encountered: