I have a setup with OpenGL ES 2.0 and EGL on Android 4.4.2 (API level 19).
我在Android 4.4.2(API级别19)上安装了OpenGL ES 2.0和EGL。
My goal is to access the buffer of the window (the default framebuffer in OpenGL terms) directly from the CPU / user space.
我的目标是直接从CPU /用户空间访问窗口的缓冲区(OpenGL术语中的默认帧缓冲区)。
I have tried using ANativeWindow_fromSurface to get ANativeWindow from the Surface of a GLSurfaceView. Then trying to get access to the buffer with ANativeWindow_lock fails with status -22. Logcat gives
我尝试使用ANativeWindow_fromSurface从GLSurfaceView的Surface获取ANativeWindow。然后尝试使用ANativeWindow_lock访问缓冲区失败,状态为-22。 Logcat给出
03-25 10:50:25.363: E/BufferQueue(171): [SurfaceView](this:0xb8d5d978,id:32,api:1,p:6488,c:171) connect: already connected (cur=1, req=2)
From this discussion it seems you can't do that with GLSurfaceView, because EGL has already acquired the surface.
从这个讨论来看,似乎你不能用GLSurfaceView做到这一点,因为EGL已经获得了表面。
How could you get to the memory of the window? Can you somehow do it through an EGLSurface? I am willing to use android::GraphicBuffer, even tough it is not part of the NDK.
你怎么能得到窗户的记忆?你可以通过EGLSurface以某种方式做到吗?我愿意使用android :: GraphicBuffer,即使很难它也不是NDK的一部分。
If this is not possible, can you use the other direction, by first creating an android::GraphicBuffer and then binding it to an EGLSurface and the displayed window?
如果这是不可能的,你可以使用另一个方向,首先创建一个android :: GraphicBuffer,然后将它绑定到EGLSurface和显示的窗口?
2 个解决方案
#1
0
Android devices may not have a framebuffer (i.e. /dev/graphics/fb). It's still widely used by the recovery UI, but it's being phased out.
Android设备可能没有帧缓冲区(即/ dev / graphics / fb)。它仍然被恢复用户界面广泛使用,但它正在逐步淘汰。
If it does have a framebuffer, it will be opened and held by the Hardware Composer unless the app framework has been shut down. Since you're trying to use the NDK, I assume the framework is still running.
如果它确实有帧缓冲,它将由硬件编辑器打开并保持,除非应用程序框架已关闭。由于您尝试使用NDK,我认为框架仍在运行。
If your NDK code is running as root or system, you can request a top window from SurfaceFlinger. The San Angeles demo provides an example.
如果您的NDK代码以root用户身份或系统运行,则可以从SurfaceFlinger请求顶部窗口。 San Angeles演示提供了一个示例。
Additional information can be found here, here, and here. If you want to work with graphics at a low level, you should also read the graphics architecture doc.
其他信息可以在这里,这里和这里找到。如果您想使用较低级别的图形,您还应该阅读图形架构文档。
#2
0
This is not doable with just NDK API, you will need to pull-in some OS headers, that are not guaranteed to be stable.
仅使用NDK API是不可行的,您需要引入一些不保证稳定的OS头。
You will need to subclass ANativeWindow, similarly to what is done in frameworks/native/include/ui/FramebufferNativeWindow.h. However you may need to construct your own buffer queue using own-created android::GraphicBuffer objects, and properly respond to all dequeue() and enqueue() requests.
您将需要子类化ANativeWindow,类似于在frameworks / native / include / ui / FramebufferNativeWindow.h中所做的操作。但是,您可能需要使用自己创建的android :: GraphicBuffer对象构造自己的缓冲区队列,并正确响应所有dequeue()和enqueue()请求。
On enqueue() you will need to sync (GPU renders asynchronously) and than map enqueued buffer to CPU memory.
在enqueue()上,您需要同步(GPU异步渲染),然后将入队缓冲区映射到CPU内存。
Note that this approach may be underperformant, due to explicit GPU<->CPU sync needed.
请注意,由于需要明确的GPU < - > CPU同步,这种方法可能会表现不佳。
#1
0
Android devices may not have a framebuffer (i.e. /dev/graphics/fb). It's still widely used by the recovery UI, but it's being phased out.
Android设备可能没有帧缓冲区(即/ dev / graphics / fb)。它仍然被恢复用户界面广泛使用,但它正在逐步淘汰。
If it does have a framebuffer, it will be opened and held by the Hardware Composer unless the app framework has been shut down. Since you're trying to use the NDK, I assume the framework is still running.
如果它确实有帧缓冲,它将由硬件编辑器打开并保持,除非应用程序框架已关闭。由于您尝试使用NDK,我认为框架仍在运行。
If your NDK code is running as root or system, you can request a top window from SurfaceFlinger. The San Angeles demo provides an example.
如果您的NDK代码以root用户身份或系统运行,则可以从SurfaceFlinger请求顶部窗口。 San Angeles演示提供了一个示例。
Additional information can be found here, here, and here. If you want to work with graphics at a low level, you should also read the graphics architecture doc.
其他信息可以在这里,这里和这里找到。如果您想使用较低级别的图形,您还应该阅读图形架构文档。
#2
0
This is not doable with just NDK API, you will need to pull-in some OS headers, that are not guaranteed to be stable.
仅使用NDK API是不可行的,您需要引入一些不保证稳定的OS头。
You will need to subclass ANativeWindow, similarly to what is done in frameworks/native/include/ui/FramebufferNativeWindow.h. However you may need to construct your own buffer queue using own-created android::GraphicBuffer objects, and properly respond to all dequeue() and enqueue() requests.
您将需要子类化ANativeWindow,类似于在frameworks / native / include / ui / FramebufferNativeWindow.h中所做的操作。但是,您可能需要使用自己创建的android :: GraphicBuffer对象构造自己的缓冲区队列,并正确响应所有dequeue()和enqueue()请求。
On enqueue() you will need to sync (GPU renders asynchronously) and than map enqueued buffer to CPU memory.
在enqueue()上,您需要同步(GPU异步渲染),然后将入队缓冲区映射到CPU内存。
Note that this approach may be underperformant, due to explicit GPU<->CPU sync needed.
请注意,由于需要明确的GPU < - > CPU同步,这种方法可能会表现不佳。