the issues here is that mir is not another mp3 player or another mail client but a very complex part of the entire stack that could help your vision in the short term but since everyone else will support only wayland for quite sometime it can become a hell to maintain in the long term since ubuntu will have to maintain their QPA plugin and Mesa patches including any other linux app Qt or Gtk that will support wayland only.
another thing we can expect is canonical to cut from ubuntu every open app[except for server apps] and create their own mir apps prolly using a very high level set of tools like mono and so detach themselves from the FOSS world and became their own project which would save them a huge amount of porting and maintaining and get rid of any license issue that could happen with their store
Canonical doesn't even want any third-party developers, they just want it developed in-house by themselves.
Not very community spirit!
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.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]
Yes, I was aware.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.
Here you lost me. Isn't all of this pointless without a system compositor?so why wayland need a compositor? it doesn't need one at all and is not part of the spec either
Wouldn't you need to at least let the compositor know you will have fullscreen and need to be on top?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
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.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]
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.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
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.
"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.
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.