Please don't get me wrong. I am not totally against this, just trying to get to the best decision for Anbox.
The whole point of this idea is to make anbox run at near native speeds even on not as fast devices, that should have been said from the start, it is not intended as a replacement for the current method and it would be entirely optional, say anbox session-manager --gles-driver=native.
Yes and no. There quite a bit more than a simple switch as the entire foundation currently relies on certain things.
The qemu pipe which the anbox pipe is based on has been optimized a lot, are there any bottlenecks that we could work on?
We can't map things from the QEMU emulator 1:1 to Anbox. The pipe implementation in QEMU is different then from what we do in Anbox. Right now we have a single local socket which is responsible for different communication channels. The code responsible for this was written for Anbox and is not copied from anywhere else. I am sure there is a lot room for optimization. Before we can start to talk about this we need to get some numbers. Adding support for LLTng would be the next natural step here to look into the pipeline and the graphics stack to see what is happening and then take further decisions.
The reason why we made Android aware of wayland is because using SDL inside the container for this purpose is overhead (in the sense of work overhead).
I agree, using SDL inside the container doesn't make sense. However it contradicts one of the goals of Anbox of having the container being agnostic to the host.
That being said i am not entirely sure whether the emugl pipe or this approach is more complex.
As whatever we do here has consequences for more than Sailfish OS. So the decision needs to be wisely choosen. Lets sit back and take a first step and get Anbox working as is. Then lets see where are the bootlenecks and what we can do to optimize these. If we end up with a situation that things are not well working we can still switch to a native approach.
I think long term the community gains a lot more from such a generic approach than diversing and creating device specific implementations which are hard to maintain, hard to oversee and complex to debug. If we all work with the same container, we all have to solve the same problems, etc.
Anbox does not run on most SailfishOS devices out of the box but i am sure this will change. Due to kernel configurations and build dependancies (e.g. some boost components).
True, but I wouldn't count any packaging / missing dependency as a blocker or problem.