Bug Description

Mir lacks a direct rendering mode.

Direct rendering means when a surface is full screen, the app is allowed to render directly to the framebuffer and bypass the compositor. This is a critical requirement for gaming performance. We did this in Compiz and it's the reason why Ubuntu went from just about the slowest distro for gaming in 12.10 to the fastest in recent benchmarks of 13.04. (In compiz, it's known as "Unredirected Fullscreen Windows").

The really fancy part is how GLX implements this with multiple monitors. You can have a single framebuffer for all your monitors and yet one of them could be rendered directly bypassing the compositor if it's covered by a fullscreen window. How this was achieved is documented in the paper "System Support for OpenGL Direct Rendering (1995)": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.4979

There are quite a lot of moving parts to this, ranging in difficulty from an estimated ‘pretty easy’ to ‘blocked until we're running a Mir session compositor under a Mir system compositor’.

The first step would be for the system compositor to not composite when there's no need to - which should be all the time when there's not an active transition occurring. That's the easy one.

Then we have the X server copy-to-Mir overhead. We can't reasonably remove this¹ because X's rendering model is persistent. Once we're running under a Mir session compositor we can run XMir without a root window and have each X window backed by its own Mir surface. For GL clients this would allow us to pass the Mir buffer all the way through DRI2, eliminating X's buffer copy.

¹: Although we could optimise it somewhat by Mir telling the client how old the buffer its receiving is. Then XMir could track damage between frames, and only copy the diff.

as for android+this bug...
We have control over the framebuffer objects, so this should be possible. We have to write a native window type (or adapt the current one to use framebuffers instead of standard buffers) for the compositor to use in process. We currently sit on top of a small nugget of android code (from about GB) that is an android native window type backed by framebuffers. We will probably have to take into consideration the HWC layer