But you don't need SurfaceFlinger to get multicontext GL out of Android GPU drivers... You only need to use the "gralloc" buffer allocator and give EGL an address from there and you can start rendering to the framebuffer or offscreen.
SurfaceFlinger does handle some things like allowing windows to draw directly to the framebuffer when they're unoccluded, but the Linux guys don't care about that (or they would unredirect frontmost windows in their X compositors, which still nobody does, ugh!).
SurfaceFlinger is also pretty immature and featureless for a desktop surface compositor:
1. Only handles 2x2 transforms (+translation) which it expands internally to 4x4 GL matrices.
2. Written entirely around GLESv1 -- no shaders, no complex geometry: no "genie effect" or anything like that.
3. Immature multi-display support. It was literally just added in Android 4.2. Try taking a screenshot of anything that's not display 0.
4. No IPC system, unless you count Binder which has it's own set of problems ("lets make every message be synchronous").
I haven't kept up with Wayland, but I imagine it has a lot of these problems addressed (except for allowing unoccluded windows direct framebuffer access -- almost nobody bothers with that one, even though it's a big win).
Also, someone at Canonical wrote a library, "libhybris" which supposedly could load GL implementations compiled against bionic on a glibc system -- this seems a much more sensible approach to me...
I'd agree that SurfaceFlinger is pretty minimal as a compositor. However, because of the power / performance limitations on mobile devices. you're losing if you're compositing with the GPU rather than say overlays, which SurfaceFlinger does facilitate with the HW Composer (as I'm sure you know).
I wouldn't recommend this approach for the desktop but the reason I like this approach for mobile ubuntu initially is that you will get a more mature GPU integration with SurfaceFlinger/ANativeWindow than generic Linux.
Edit: we also know the limitation of glesv1 is because of the problems for glesv2 support in some is emulator environments. So it s a trade off. Agree that the multiple display support is a big problem too
SurfaceFlinger does handle some things like allowing windows to draw directly to the framebuffer when they're unoccluded, but the Linux guys don't care about that (or they would unredirect frontmost windows in their X compositors, which still nobody does, ugh!).
SurfaceFlinger is also pretty immature and featureless for a desktop surface compositor: 1. Only handles 2x2 transforms (+translation) which it expands internally to 4x4 GL matrices. 2. Written entirely around GLESv1 -- no shaders, no complex geometry: no "genie effect" or anything like that. 3. Immature multi-display support. It was literally just added in Android 4.2. Try taking a screenshot of anything that's not display 0. 4. No IPC system, unless you count Binder which has it's own set of problems ("lets make every message be synchronous").
I haven't kept up with Wayland, but I imagine it has a lot of these problems addressed (except for allowing unoccluded windows direct framebuffer access -- almost nobody bothers with that one, even though it's a big win).
Also, someone at Canonical wrote a library, "libhybris" which supposedly could load GL implementations compiled against bionic on a glibc system -- this seems a much more sensible approach to me...