GraphicBuffer as a fallback for API<26?

[tareksander]

• Benchmark the performance for pbuffer + shared memory to see if it get a good improvement
• If the improvement is enough, integrate it as an option for API 24 + 25

[twaik]

I think pbuffer + shared memory will always have lower perfomance since it always uses some kind of memcpy implementation between graphic accelerator and CPU (which has terrible perfomance). When I tried to flip image with this code

//real_glReadPixels(0, 0, w->pWidth, w->pHeight, GL_RGBA, GL_UNSIGNED_BYTE, w->pData);
for (int i=0; i<w->pHeight; i++)
    real_glReadPixels(0, i, w->pWidth, 1, GL_RGBA, GL_UNSIGNED_BYTE, &((uint32_t *) w->pData)[(w->pHeight - i - 1) * w->pWidth]);

FPS was much lower (20 instead of 30). So we definitely should check if it can work.

[twaik]

Going on this conversation.

Termux-x11's server also works as termux-app's child process, so if setting sdk version for process will work with libegl-android.so it will work for termux-x11 too.

[twaik]

Also I should point that in the case it works we will be able to get DMABUF fd almost directly with GraphicBuffer API. Without socketpair trick.