Canonical Joined The Khronos Group To Help Mir/Wayland Drivers

[TheSoulz]

You asked for an example where the program has to talk directly to the display server. The article has an example.


You propose that there be an API to determine what display server a program is running on. But that would just give the programmer some value that they could use to figure out what display server they are using, it would still be up to the individual application to react to this information appropriately, and that would involve separate code-paths for each result.


Again, yes, talking to the display server is more work. But now applications have three display servers to talk to instead of two. That is a 50% increase.

50% increase of the work? WTF
If 50% of the work when creating a app is spent on the display manager your probably doing something wrong or linux is a way wrost of a shape then i thought.
My understanding is the display manager is useless all you require from the display manager is the window position, drag events, resizes, mouse/keyboard input and maybe display resolution correct??
the display should not even try to mess with whats inside your app (should not draw anything in your app).
I will read that article you sent more detailed when i have a bit more "study time" but all these things can and should be done by the toolkit quiet easly.

a stupid example for creating a window:

APP:

function create_window ();
call_toolkit_api (My_App_Name)
end

The toolkit:

Funtion call_toolkitapi (name)
if mir
call_mir_api_to_create_window
give_it_a_name ("name")
if wayland
call_wayland_api_to_create_window
give_it_a_name ("name")
if x11
call_x11_api_to_create_window
give_it_a_name ("name")
else
print ("sorry this display manager is not supported")
end

This is how i understand how it works (kinda)...
i will study it and maybe even try can create an app for linux just to have some facts.

[TheSoulz]

for those like me that actualy like to learn what they are talking about heres where im starting:

http://qt-project.org/doc/qtcreator-2.5/creator-writing-program.html

[silix]

The truth is that toolkits will take care of 99% of the issues by abstracting away the window system underneath. But 1% of a million different apps is still a very significant undertaking.

right but... (continues)

One of the divides between acadamia and practicing software developers is that acadamia always sees the theory and how well everything should work. Developers see what happens in real life, and it's never nearly as clean as everyone hopes.

... the problem is not a matter of academy/real life division .. at least not only... rather a matter of what the toolkit allows to do vs what the application needs to do and how it needs to look
for as obvious as this may appear, this means having to roll your own widgets and or drawing code as soon as those provided by the toolkit are not adequate anymore (say you want to go beyond the default look and feel or need some more features) for the specific requirements of the application
(what in the windows world has been done for ages with widget subclassing and owner drawing - interestingly, on windows a submarket has flourished, for third party widgets)
plus, there's the notable detail of the application's working (document) area - with application which are not trivial, or dont fall in the handful of horizontal models (say, the text editor or the web browser) for which either the toolkit or third party frameworks provide readily usable implementations, one has again to roll his own
implementing your own widgets, the issue becomes to what extent the underlying graphic system is involved and how it has to be touched
now, with both mir and wayland (or better, a generic wayland compositor) being structurally similar (though not identical) and based on the concept of client side rendering, this should break down to
- render to an egl surface (common)
- pass the surface somehow to the compositor (specific)

thus being the main logic common, porting to a different server will most likely mean to add some lines of code (the calls to pass on the surface), not an entire application rewrite

You propose that there be an API to determine what display server a program is running on. But that would just give the programmer some value that they could use to figure out what display server they are using, it would still be up to the individual application to react to this information appropriately, and that would involve separate code-paths for each result.

that's not abstracting the underlying platform in a generic manner (what a cross platform framework should do)
i as an application developer dont want to care of what display server i am using, out of an arbitrary N of them - nor should i care
what i want is a simple feature query and the ability to do this

if (featureIsSupported)
{
// normal code
}
else
{
// fallback code
}

or even, remebering that if's have a certain runtime cost while exception handling has no overhead in the normal case, something like

try
{
/// normal code
}
catch (UnavailableFeatureException e)
{
// fallback code
}

this is generic code that will work on any display server or protocol present and future, what is written in that article is hackish code with implementation details that should be masked by the api, leaking outside

[silix]

My understanding is the display manager is useless all you require from the display manager is the window position, drag events, resizes, mouse/keyboard input and maybe display resolution correct??

in theory and according to sense, correct

in practice, i suspect some details from the very inception of the wayland project in 2008 have made their way to this day - namely the fact the client (the application) has full duties wrt event handling and redrawing, being in charge of everything from moving its own windows to drawing inside them
with windows being fullscreen anyway (transparent pixels around content to pad) and a stack of fullscreen surfaces the only thing the compositor manages
if this is still the case (notice i actually expect to be proven wrong on this) wayland may require applications to interact with the server more closely than one may think

[justmy2cents]

The truth is that toolkits will take care of 99% of the issues by abstracting away the window system underneath. But 1% of a million different apps is still a very significant undertaking.

One of the divides between acadamia and practicing software developers is that acadamia always sees the theory and how well everything should work. Developers see what happens in real life, and it's never nearly as clean as everyone hopes.

The real issue I think is less the porting process for apps, but the testing process. It's going to be very difficult to properly test things (fully and constantly) on all 3 servers (X, Wayland, and Mir) and there are going to be times when Mir breaks assumptions that they would like to keep in the code for Wayland, and no one is really going to want to have to deal with that when there isn't a good reason for it. The only reason it's even a possibility is because fundamentally Wayland and Mir are so similar - if we were talking about another change as big as the one between X and Wayland is, there would be a full-scale revolt among developers.

*Compositors, like Kwin are a different animal than regular apps, and have much much more trouble, which is why i don't expect kwin to run on Mir anytime soon. The problem is much less severe for most other apps.

thanks on response and not mistaking it as trolling. testing and execution difference makes much more sense than sounding of your previous argument. this i completely agree on

[erendorn]

right but... (continues)
... the problem is not a matter of academy/real life division .. at least not only... rather a matter of what the toolkit allows to do vs what the application needs to do and how it needs to look
for as obvious as this may appear, this means having to roll your own widgets and or drawing code as soon as those provided by the toolkit are not adequate anymore (say you want to go beyond the default look and feel or need some more features) for the specific requirements of the application
(what in the windows world has been done for ages with widget subclassing and owner drawing - interestingly, on windows a submarket has flourished, for third party widgets)
plus, there's the notable detail of the application's working (document) area - with application which are not trivial, or dont fall in the handful of horizontal models (say, the text editor or the web browser) for which either the toolkit or third party frameworks provide readily usable implementations, one has again to roll his own
implementing your own widgets, the issue becomes to what extent the underlying graphic system is involved and how it has to be touched
now, with both mir and wayland (or better, a generic wayland compositor) being structurally similar (though not identical) and based on the concept of client side rendering, this should break down to
- render to an egl surface (common)
- pass the surface somehow to the compositor (specific)

thus being the main logic common, porting to a different server will most likely mean to add some lines of code (the calls to pass on the surface), not an entire application rewrite
that's not abstracting the underlying platform in a generic manner (what a cross platform framework should do)
i as an application developer dont want to care of what display server i am using, out of an arbitrary N of them - nor should i care
what i want is a simple feature query and the ability to do this

if (featureIsSupported)
{
// normal code
}
else
{
// fallback code
}

or even, remebering that if's have a certain runtime cost while exception handling has no overhead in the normal case, something like

try
{
/// normal code
}
catch (UnavailableFeatureException e)
{
// fallback code
}

this is generic code that will work on any display server or protocol present and future, what is written in that article is hackish code with implementation details that should be masked by the api, leaking outside

Exception overhead depends on implementation. In any case, the overhead of a branch misprediction is like 5 cycles, if you cannot afford them for performance reasons, I wouldn't put an exception instead. It's certainly premature optimization to me (and most likely a counterproductive one at that).

[TheBlackCat]

50% increase of the work? WTF
If 50% of the work when creating a app is spent on the display manager your probably doing something wrong or linux is a way wrost of a shape then i thought.

Obviously I meant 50% more work in the display manager-specific portions, not the whole code.

My understanding is the display manager is useless all you require from the display manager is the window position, drag events, resizes, mouse/keyboard input and maybe display resolution correct??

You never looked at the example I linked to, did you? You also need to be able to draw to it. You may need to know the shape and size of the space you have to work with, where the mouse and/or mouse events are relative to what you are trying to draw (which may or may not be provided directly by the display sever), perhaps even whether your window has focus or if there is another window above yours, nowadays probably the DPI, perhaps even whether the window is maximized or minimized. Different display servers can provide this information in different forms, in different units, using different data types, and in different places, or not provide it at all and you have to calculate it from other values.

I will read that article you sent more detailed when i have a bit more "study time" but all these things can and should be done by the toolkit quiet easly.

Until you have actually bothered to find out what does and does not need to be done, perhaps it would be a good idea to not make claims about what does and does not need to be done.

a stupid example for creating a window

Creating a window is not the problem here.

[silix]

Exception overhead depends on implementation.

yes - but last i investigated on it or a mid term project (several years ago), some of the relevant C++ runtimes were in the process of achieving actual (or so their papers said) zero overhead for the main path at the expense of the "exception taken" path (but exceptions are supposed to be exceptional afterall)

In any case, the overhead of a branch misprediction is like 5 cycles,

i actually talked about "if's have a cost", not just branch misprediction cycles... now you may not take my word for it, but that cost may be up to WAY more, especially when you have long sequences of strictly dependent instructions (which the processor can hardly execute OOO speculatively)

It's certainly premature optimization to me (and most likely a counterproductive one at that).

to me it's not, since premature optimization is when you write code not mirroring the algorithmic semantics it should implement, and do so on a first pass - making it harder to understand and revise the algorithm itself

but in this case (my fault, i may have not made myself clear enough) it wasnt about optimizing branch costs away, it was an example of control flow whereas one could (and should) write code handling minimal platform feature differences in the "else" or "catch" block (notice that i wrote down both) rather than in the main path (that will stay as streamlined as possible)

(on a side note mind you, programming by exception is actually enforced in several projects and companies... i was in one where strict coding guidelines mandated it to keep cyclomatic complexity at a minimum - we couldnt have more than 5 if's per whole method and no more than 3 per "screenful" , ie 20 LoC - this and other rules enforced in order for the code to be more readable and what it was supposed to do, more evident, according to the coach)

OTOH, from the perspective of how to handle display server differences at athe toolkit / application level, the one line of code i wrote is a very minor detail - it's interesting how people prefer to focus and attack on minutiae rather than the wider point, here...

[erendorn]

yes - but last i investigated on it or a mid term project (several years ago), some of the relevant C++ runtimes were in the process of achieving actual (or so their papers said) zero overhead for the main path at the expense of the "exception taken" path (but exceptions are supposed to be exceptional afterall)
i actually talked about "if's have a cost", not just branch misprediction cycles... now you may not take my word for it, but that cost may be up to WAY more, especially when you have long sequences of strictly dependent instructions (which the processor can hardly execute OOO speculatively)

I do take your word for it, it just that it seem hard to predict without profiling + estimation of exception occurrences. But I agree it's good to know it can be leveraged for performance.

to me it's not, since premature optimization is when you write code not mirroring the algorithmic semantics it should implement, and do so on a first pass - making it harder to understand and revise the algorithm itself

but in this case (my fault, i may have not made myself clear enough) it wasnt about optimizing branch costs away, it was an example of control flow whereas one could (and should) write code handling minimal platform feature differences in the "else" or "catch" block (notice that i wrote down both) rather than in the main path (that will stay as streamlined as possible)

(on a side note mind you, programming by exception is actually enforced in several projects and companies... i was in one where strict coding guidelines mandated it to keep cyclomatic complexity at a minimum - we couldnt have more than 5 if's per whole method and no more than 3 per "screenful" , ie 20 LoC - this and other rules enforced in order for the code to be more readable and what it was supposed to do, more evident, according to the coach)

Fully agree on that, there's no doubt it increases readability.

OTOH, from the perspective of how to handle display server differences at athe toolkit / application level, the one line of code i wrote is a very minor detail - it's interesting how people prefer to focus and attack on minutiae rather than the wider point, here...

It's just that this minor point was more interesting than the display server issues, which have been discussed quite a lot already