Xubuntu Saucy on Mir/XMir

[Brandon Watkins]

On Mon, Aug 5, 2013 at 12:44 PM, Eero Tamminen <oak at helsinkinet.fi> wrote
>
>
> Do you have a bug about this on XFWM (window compositor)?
>
>
>         - Eero
>
> --
> xubuntu-devel mailing list
> xubuntu-devel at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/xubuntu-devel
>
Tearing with xrender based compositing is a very old and known issue :) On
some hardware it may be possible to get tear-free with xrender compositing
(I've had users of the AMD oss driver tell me that they don't get tearing),
but on modern intel hardware it is not possible at all to get tear-free
compositing with xrender, because any intel hardware sandybridge or newer
requires a page-flipping opengl compositor to get any kind of tear-free
output. Unless XFCE ports XFWM to use opengl there isn't really anything
they can do about tearing on intel hardware (there is a patch here that
implements a very hacky vsync method:
http://www.webupd8.org/2012/10/xfce-sync-to-vblank-support-for-xfwm.html,
but on intel hardware it doesn't full work and there is still tearing near
the top of the screen, because as I mentioned on intel you need a proper
page-flipping compositor to get full tear free output).

Here is a quote from an intel developer: First note that all Intel hardware
up to SandyBridge has functional vsync support with no greater cost than
stalling the GPU until the blit can proceed.

The problem is that with the agressive powersaving of SandyBridge and the
greater decoupling between the display engine and the GPU, the ability to
delay rendering until a particular scanline had passed was assumed to be a
legacy feature and the GPU commands to do so were removed. By presuming
that all updates would then be through a compositor using pageflipping
(i.e. their primary target, Windows Vista/7/8), they were then able to make
further power savings. If you use an OpenGL (really DRI2) compositor that
only pageflips (i.e. doesn't try to take "advantage" of
MESA_copy_sub_buffer), you will not see any tearing, suffer very little
jitter, and maximise the power savings of the GPU.

The reason that running xubuntu/xfce on xmir results in tear-free, whilst
plain X has a ton of tearing, is probably because xmir runs on top of the
"unity-system-compositor", and the USC is making sure the xmir outputs are
always page-flipped.

>From what I've seen the XFCE devs are pretty limited when it comes to
manpower, and from what I've seen don't really have the resources or the
interest in adding opengl compositing to xfwm, so for intel hardware
there's really only two solutions: using a 3rd party opengl compositor,
such as compiz (and unfortunately compiz is very buggy when run outsde of
unity in 13.04 so that's not an option for me, mainly because of this bug:
https://bugs.launchpad.net/compiz/+bug/1158267), or compton:
https://github.com/chjj/compton. Compton is very lightweight and stable and
doesn't need to replace xfwm, but since it doesn't replace the window
manager/window decoration it has limitations when it comes to drawing
shadows, so its shadows are glitchy in various applications, so you have to
manually exclude these things in its config file (examples of things I
needed to exclude because of buggy shadows: xfce4-power-manager,
xfce4-notifyd, conky etc...).

Sorry for the wall of text, but hopefully this shows why I'd consider xfce
on top of mir/USC/xmir to be the best solution for tearing on xfce :) It
would work "out of the box" without having to mess around with 3rd party
compositors and window managers. Intel hardware is quite common, so a
xubuntu that doesn't have tearing out of the box would probably make other
intel users happy!

I do understand that if xubuntu on xmir turns out to be too buggy then
xubuntu would obviously have to stick with X as default. But even if that
happens, it would be nice if there was an optional xmir session available :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/xubuntu-devel/attachments/20130805/5772578d/attachment.html>