Desktops Running On XMir

Kevin Gunn kevin.gunn at
Tue Jun 25 15:52:29 UTC 2013

Daniel - cmiiw, but I believe the introduced lag won't be a full frame
(16ms) because as i understood from RAOF, the input buffers on xmir aren't
vysnch governed, only the ouput final fb render of unity-system-compositor
hence, x/compiz level can literally draw as fast as possible into the input
buffers...and only the u-s-c composition turn is vsynch'd.
so while maybe it could be more effecient, its not as bad as vsynch lock at
multiple levels.

and doesn't compiz have a bypass mechanism itself ? meaning shouldn't it
draw into mir's input buffers directly ?
(i'm guessing this is exactly the problem you're pointing out...)

On Mon, Jun 24, 2013 at 9:06 PM, Daniel van Vugt <
daniel.van.vugt at> wrote:

> I was thinking about this just today, and the fact that it works means
> XMir is probably not working how it should (!)
> 1. Double-buffered compositors (Usually only Compiz. Sometimes Gnome) have
> >=two buffers of their own. Only the front one gets sent to Mir's
> backbuffer...? This would be sub-optimal because:
>   (a) The X compositor is maintaining two buffers at the same time that
> Mir is. It's a waste of resources in the least
>   (b) It creates at least one frame of lag.
> 2. Single-buffered desktops (all others?), which are updated by region
> blits only. No full-screen buffer swapping in the X compositor, because for
> most of them there is no "compositor". Last I checked, single buffering
> cannot work in Mir because we haven't implemented it. You have to simulate
> it by copying the X buffer to Mir's backbuffer (see
> mir/examples/fingerpaint.c). This is again sub-optimal because of the
> copying and lag.
> So given these desktops do work under XMir (I checked), and given Mir does
> not understand single buffering, that means our XMir approach probably has
> some slow buffer copying that needs to be eliminated. It might feel native,
> but benchmarks will disagree.
> Also, last I checked, RAOF's plan was to use composition bypass to solve
> this problem (when it's ready). Thus skipping the extra step we still have
> and achieving equal performance to native X.
> P.S. I just measured 9-16% improvement in windowed Compiz/XMir performance
> by tweaking the compiz config to eliminate Compiz' double buffering (untick
> everything under CCSM > OpenGL). This is safe under XMir because Mir does
> the real buffer swapping.
> - Daniel
> On 25/06/13 04:43, Jono Bacon wrote:
>> Hi All,
>> In case anyone didn't see it, Thomas did some testing of other desktops
>> running on XMir on Mir:
>>   * XFCE -
>>   * LXDE -
>>   * GNOME 3 -
>> He couldn't test KDE because of an archive issue (non-Mir related). He
>> will test this soon. Unity 7 already runs on XMir.
>> I asked him about performance and he said it feels native.
>> Thanks,
>>     Jono
>> --
>> Jono Bacon
>> Ubuntu Community Manager
>> <> /
>> <>
>> <**jonobacon<>
>> >
>> <**jonobacon<>
>> >
> --
> Mir-devel mailing list
> Mir-devel at
> Modify settings or unsubscribe at:**
> mailman/listinfo/mir-devel<>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mir-devel mailing list