-
Notifications
You must be signed in to change notification settings - Fork 327
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GVR support #982
Add GVR support #982
Conversation
This also adds in a new @abi_type annotation to specify a different type to use when passing the type as an exported variable. This is needed as structs appear to behave differently when passed with and without a copy constructor.
Groups GVR frames. Yay!
Was a hack for GVR. Now fixed.
Needs special love as the framebuffer is unbound at this point.
Use these commands to help populate GVR frame -> gles framebuffers.
@@ -185,8 +188,12 @@ Spy::Spy() | |||
mCaptureFrames = header.mNumFrames; | |||
mSuspendCaptureFrames.store((header.mFlags & ConnectionHeader::FLAG_DEFER_START)? | |||
kSuspendIndefinitely: mSuspendCaptureFrames.load()); | |||
if (header.mGvrHandle != 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I understand correctly we get the GVR handle from JDWP, then send it back to the application later in the connection header.
That feel .. painful, but I understand why we do it this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup. All because it's near impossible to obtain the android.context.Context
from JNI, which is needed to call the GVR loader to get the GVR handle. 😞
No description provided.