Desktops Running On XMir

[Kevin Gunn]

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
(u-s-c)
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...)
br,kg


On Mon, Jun 24, 2013 at 9:06 PM, Daniel van Vugt <
daniel.van.vugt at canonical.com> 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 -
>> https://plus.google.com/u/1/**110095242873945299189/posts/**93dAjSwbmch<https://plus.google.com/u/1/110095242873945299189/posts/93dAjSwbmch>
>>   * LXDE -
>> https://plus.google.com/u/1/**110095242873945299189/posts/**ZxfdAPrybtn<https://plus.google.com/u/1/110095242873945299189/posts/ZxfdAPrybtn>
>>   * GNOME 3 -
>> https://plus.google.com/u/1/**110095242873945299189/posts/**3q7YJrc8Fpp<https://plus.google.com/u/1/110095242873945299189/posts/3q7YJrc8Fpp>
>>
>> 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
>> www.ubuntu.com <http://www.ubuntu.com> / www.jonobacon.org
>> <http://www.jonobacon.org>
>> www.identi.ca/jonobacon <http://www.identi.ca/**jonobacon<http://www.identi.ca/jonobacon>
>> >
>> www.twitter.com/jonobacon <http://www.twitter.com/**jonobacon<http://www.twitter.com/jonobacon>
>> >
>>
>>
>>
> --
> Mir-devel mailing list
> Mir-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/**
> mailman/listinfo/mir-devel<https://lists.ubuntu.com/mailman/listinfo/mir-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/mir-devel/attachments/20130625/f68205eb/attachment.html>