Mir Development Stats Dominated By Canonical

[mrugiero]

well to extend a bit in this topic wayland is not a server at all and it can't be not just because it doesn't draw, as a reference X.Org doesn't necessarily draw either[unless you use motif directly <-- insanity].

so what make an protocol like Mir and X11 server type? well, with either of this two Mir and/or X.org are global processes that handle the interaction between GPU[positioning/input/referencing/rendering/surfaces/subsurfaces/etc] and the clients, this means and X.org or Mir application can't access the framebuffer of the GPU directly, they have to request the operation to this global middleman in between and this apply to the compositors too, they have to request and process the framebuffer to this middleman talking an API this middleman can understand, so the middleman later can render the completed frame.

I thought this part was already clear. As I said in my previous post, I just recalled correctly because a compositor, which as you point out later in this post isn't Wayland, *can* be implemented as a server.

what make Mir different from X.org? well basically Mir trimmed all the fat of the X11 protocol and try to be a less intrusive middleman allowing you more freedom in the render process, in theory Mir can be atomic and properly threaded too[TODO for now] and uses EGL instead the GLX mammut but still is a global process middleman that you have to request operations even so you have to do lot less roundtrips than you would with X11.[you can confirm this checking their own examples and looking at your process table]

I don't know where do you get this part from, I tried to find specific info about how Mir renders but had no success. I haven't much time today to check it out, but other days what I found as a 'spec' was Canonical's fuzz words.

so, why wayland is not a server then? keeping your words wayland is more close to an OpenGL for Framebuffer management than to X.org or Mir. let see it this way, you can do everything wayland does using pure EGL/OpenGL or even GPU ASM, is not a big deal at all and the performance advantage is nasty but if everyone do this their own way basically would be a hell of a mess that will force you to use 1 computer per application, so all christian did was think of an standard library that can send this object directly from the application to the GPU in an standarized fashion so we can all use it. So yes that it is wayland is nothing more that a library of premade objects that you can send to a GPU to do window surface operations directly.

Yes, I was aware.

so why wayland need a compositor? it doesn't need one at all and is not part of the spec either

Here you lost me. Isn't all of this pointless without a system compositor?

so what is a wayland compositor? put simply a client or application that other applications that use the wayland protocol register objects with, so it can keep a global idea of how the framebuffer is looking in a given period of time and do operations with that information[change a surface position for example or add eye candy], in resume a compositor is a good added value but is not necessary

in which god's case i would not use a compositor? full screen games or any type of full screen application, yeap just create a surface that match the entire display size then render something into it and swap it, 100% GPU dedicated to your APP like magic

Wouldn't you need to at least let the compositor know you will have fullscreen and need to be on top?

so how wayland/client relate? you app using the wayland protocol create an usable surface, then your app draw something in that surface using any API you like[OpenGL, OpenVG, GPU ASM, Pixman, etc] then your app inform the compositor it have an valid surface at X,Y,Z[in case is not fullscreen] and the compositor simply re render a surface as big as the screen[that include your app and other apps surfaces] and post-process it to give you a final surface composited from all other subsurface

so in resume when your app is linked to libwayland your app not wayland send packages of operation directly to the GPU, use wayland isn't any different than use a let say a jabber protocol library or libtorrent protocol library, in perfect english everything is on you because wayland do absolutely nothing at all beyond provide you with premade operations to start a valid surface in the GPU[ofc if you use tollkits like Qt or Gtk they do the heavy lifting]

Yes, I was aware of that. My only misconception was about Wayland implemented as a server. As I said, I want to port a pet project to Wayland, so I read a bit about that.

i hope is more clear[and obviously is very simplified], about been polite is hard sometime when you explain the same thing in 200 different post and ppl still come and say "Lulz wayland don't minimize" or any other barbaric assumption without properly investigate before hand

I know that feel, but when you are impolite you just feed the idea your position is based on ignorance, since it looks like you lose your temper because you got out of arguments.
Anyway, thanks for the brief explanation, it could be useful to make some kind of tutorial, so you don't have to put it into words every time but just link to it.

[mrugiero]

here is the blog post http://mer-project.blogspot.fi/2013/...u-drivers.html

and the quote from the dev himself

"Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself."

Well, I did thought that. And I probably had read about that before, just I didn't pay attention because I don't care that much about Android.

No, Ohloh count comments separately from lines of code and whitespace. Mir has 160k lines of actual code, Wayland has 12k, Weston has 53k.

But the other poster explicitly asked about CLOC, not Ohloh :P

Reuse of libhybris (compatibility with android drivers). for xMir xWayland, couldn't find reliable source, and too complicated to compare code myself.

Thanks, as I answered to another post, I thought it was the other way around.

No. A lot of times it's faster to just go do your thing than try to convince others of your POV.

Maybe, but usually you first check if they share your POV, first.

[XorEaxEax]

No, Ohloh count comments separately from lines of code and whitespace. Mir has 160k lines of actual code, Wayland has 12k, Weston has 53k.

I was referring to what Michael wrote in the actual 'article':

"When using CLOC to analyze the source-tree, there's some stats about the lines of code and files."

"When counting code of all different languages, there's a total of 118,008 lines of code in total -- including code comments, etc."

As I said I found it strange that Michael reported comments along with code, particularly as I recall CLOC (which he states he used) presented actual code separately from comments (and blank lines), although my memory may fail me here.

[mrugiero]

I was referring to what Michael wrote in the actual 'article':

"When using CLOC to analyze the source-tree, there's some stats about the lines of code and files."

"When counting code of all different languages, there's a total of 118,008 lines of code in total -- including code comments, etc."

As I said I found it strange that Michael reported comments along with code, particularly as I recall CLOC (which he states he used) presented actual code separately from comments (and blank lines), although my memory may fail me here.

Your memory is not failing. Since I didn't know about CLOC, I had to google it, and in its description it clearly states that it does present code, comments and blank lines separately.

[smitty3268]

Where can I get the ROM, what distro packages it, does it actually run programs, can I still make a call?

Ubuntu's is right here ready to go.
https://wiki.ubuntu.com/Touch/Instal...InstallProcess

I am rooting for Wayland but this is the current state of things. Canonical deserves respect here.

Wayland is actually shipping in real, live, consumer products. Today. Not just downloadable tech demos.

Whether that means it's "winning", or "losing", I'll leave to you. I don't even know what can be won, since the 2 aren't really in competition against each other.

[shaunehunter]

Wayland is actually shipping in real, live, consumer products. Today. Not just downloadable tech demos.

What and where do you buy it. I probably would buy it. Really.

I'm not hating on Wayland, I'm waiting on it.

[IsacDaavid]

here is the blog post http://mer-project.blogspot.fi/2013/...u-drivers.html

and the quote from the dev himself

"Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself."

not pretending to drive the conversation to a different path, but in cases like this it feels desirable to have an advertising clause or some sort of attribution requirement in the license itself.

[jrch2k8]

for @mrugiero

1.) well if you have a complex desktop maybe it make no sense to discard a compositor but imagine you have an ARM HTPC that you want to autostart XBMC, well XBMC don't need the compositor since it will always be fullscreen and is better for it to have 100% of the GPU resources dedicated to it, instead of wasting cycles in keep a compositor for the sake of it

2.) well if you are in a complex desktop enviroment like KDE or Gnome well the compositor need to know[you have IPC API for that] that you want full control of the GPU and given its smart enough it will use any method it can to remove itself of the GPU to give control to that App. As the how it will depend of the compositor but for example Kwin could copy all the non full screen surfaces to an SHM buffer and flush the GPU to pass it to the App and once you wish to switch or de maximize the compositor will composite in that SHM buffer while is been copied back to the framebuffer or it could simply keep other surfaces in in the framebuffer tagged as offscreen so it will consume some GPU memory but stay entirely away of the render process or any other method the compositor can handle[very rich set of options to play with].

as a rule of thumb remember composite basically means create a single surface using many layers of smaller surfaces outside the scope of you own application[in wayland you can composite effect within your app], so if you control the only surface available cuz is full screen and you own the process and the compositor is not needed because there is nothing to composite[note that eye candy is not part of the composite stage but the render stage and you control the render stage from the app GPU wide if fullscreen or surface owned wide if you are in a multi surface scenario]

[mrugiero]

for @mrugiero

1.) well if you have a complex desktop maybe it make no sense to discard a compositor but imagine you have an ARM HTPC that you want to autostart XBMC, well XBMC don't need the compositor since it will always be fullscreen and is better for it to have 100% of the GPU resources dedicated to it, instead of wasting cycles in keep a compositor for the sake of it

You are right, I just assumed we were talking about desktop. I usually forget there are smartphones and all kind of things out there, mostly because my only personal computing device is a laptop. I still use a Nokia 1100 :lol:

2.) well if you are in a complex desktop enviroment like KDE or Gnome well the compositor need to know[you have IPC API for that] that you want full control of the GPU and given its smart enough it will use any method it can to remove itself of the GPU to give control to that App. As the how it will depend of the compositor but for example Kwin could copy all the non full screen surfaces to an SHM buffer and flush the GPU to pass it to the App and once you wish to switch or de maximize the compositor will composite in that SHM buffer while is been copied back to the framebuffer or it could simply keep other surfaces in in the framebuffer tagged as offscreen so it will consume some GPU memory but stay entirely away of the render process or any other method the compositor can handle[very rich set of options to play with].

as a rule of thumb remember composite basically means create a single surface using many layers of smaller surfaces outside the scope of you own application[in wayland you can composite effect within your app], so if you control the only surface available cuz is full screen and you own the process and the compositor is not needed because there is nothing to composite[note that eye candy is not part of the composite stage but the render stage and you control the render stage from the app GPU wide if fullscreen or surface owned wide if you are in a multi surface scenario]

Thanks for the clarification. I'm aware what compositing means, and I actually put a lot of thought last week to this (but kept forgetting to check if it was actually done this way).

[Delgarde]

not pretending to drive the conversation to a different path, but in cases like this it feels desirable to have an advertising clause or some sort of attribution requirement in the license itself.

Maybe, but it would also be nice not to *need* an anti-asshole clause in the license. Canonical aren't doing anything the license doesn't permit, but with this kind of shit, it's little wonder the rest of the community doesn't trust them much.