However, in a post which was deleted (because it was an answer to some troll), I explained something. In the post where it's stated there is one second lag, first it explicitly said *at times*. Also, when you talk about lag you don't imply it's at all the time, because then it's just a low general performance.
There might be a one second lag (and I say might because I didn't watch the video, i.e. I don't know if there is) and not be reflected by the benchmark, which makes a statistic of a given runtime. It measures some statistically relevant data which doesn't seem to include the range of obtained FPS. If I read it correctly, it only measures median, average and standard deviation, while lag is in most cases an outlier, something that happens during a short amount of time. If this is the case, this generally high performance (I think considering it's running on a compatibility layer, 10-15% loss is not really a bad performance, it's just bad because of the fact it's unneeded) might actually seem lower to the benchmark because of this short periods of extremely low performance. Furthermore, this seemingly bad news for XMir might be better than they look, because this probably points the issue to be a single bottleneck or bug, instead of being something more spread around in the code.
Well, don't take what I say as a sure thing, because I lack a lot of knowledge in this area, and I don't know how the current implementation is done, so I will just say how I think it might be better.I understand that running a desktop environment on top of xmir/xwayland is just a waste of resources, but I still don't understand the technical details behind saying that running just applications under xwayland/xmir will result in faster rendering for X applications than running them in X directly.
Anyway it seems that canonical gave a shot at running a full DE to keep the development adrenaline going on or shut the people at kubuntu saying that ubuntu and kubuntu flavors would not be able to co-exists due to mir.
First, we should assume that either Wayland or Mir (whichever we care about) is faster than X.org, at the very least on compositing.
Then, we can think the virtual server will only activate compositing if there is an app calling the extension, which will be probably a window manager. If not, all the compositing will be managed by the system compositor or whatever it's called on Mir, which is more efficient than X. This X will not need to actually handle most of the input either, since inside the surface, where the rootless X server is running, you have all the input and all the (virtual) screen on your app. This means you can safely ignore, if no WM is loaded inside this (which might probably be figured out in several ways, where one valid for compositing window managers might be the loading or not of compositing extension), all of the input grab and release requests. For all that X.org cares about, this windows is the only thing that will handle any input. Since compositing is off, the only thing the X server will care about in terms of output will be what the client window wants to draw. And I guess there are several other parts which could be easily ignored with this assumption of a single, fullscreen app for X11. It's like taking shortcuts, mostly.
EDIT: I forgot to say, the other thing about running on top of a compatibility layer is that, as any code, might introduce bugs. It's usually a trade-off for a potential benefit (in the case of using XMir/Wayland in a native Mir/Wayland system, the obvious benefit is that you are able to run software that has not been ported), but in this case there is no benefit, and it makes it harder to maintain. If XMir or XWayland introduces new bugs on KWin, they will not fix them, which makes sense because even reproducing them takes a lot of work if they don't use that solution, and it's very distro specific (at least at the moment; KWin runs natively on Wayland, so there's REALLY no point on trying that configuration, aside for love for science, and Mir is currently Ubuntu only). Kubuntu maintainer says he (and that flavor's community) lacks the know-how and the manpower to fix bugs in KWin, so they can't fix what doesn't correspond to upstream. This means that chances are there will be no one to fix XMir/KWin combination bugs, except Canonical pays someone to. And also, this patches wouldn't be accepted upstream, because of several reasons, one of which is that new code is always likely to introduce new bugs. However, this might be the only viable option: using other solution would mean having multiple duplicated libs (at the very least, the toolkits), which would have to be maintained and tested, too.
Also, at some point is likely X.org versions get dropped from upstream, tho I wouldn't expect that to happen in the next two or three years, and this means this solution will be ineffective, or Kubuntu will have to bring outdated versions.
Last edited by mrugiero; 06-28-2013 at 10:11 PM.
I've been quite surprised reading this and the other 2 Mir threads in the last couple of days. Either Canonical's bull works and people think the whole making XMir default is actually a sign of progress or BOSS has created 3-4 more accounts to do his regular work while his main account tests the limits of absurdity.
You could, for example, have 10,000 FPS in glxgears and still have it display on your screen a second late. That's what it means.
On this case we are talking about graphical lag, how can you notice the underlying system is lagging or behind by 1 second without a tool to measure it? Which part on the video showing XMir running the desktop environments we see the mouse pointer or some other component stop responding for 1 second?
In any case here is the video which some guys are saying has a 1 second lag (also some one else said 30% fps drop means 1 second lag).
On a side note: maybe the guy that said he saw 1 second lag didn't noticed that what lagged was his flash player
Last edited by TheOne; 06-29-2013 at 09:15 AM.
Otherwise, I have no idea how can he know of any lag, since he doesn't see when the input is done.