Page 8 of 8 FirstFirst ... 678
Results 71 to 80 of 80

Thread: Canonical Joined The Khronos Group To Help Mir/Wayland Drivers

  1. #71
    Join Date
    Feb 2011
    Posts
    1,252

    Default

    Quote Originally Posted by TheSoulz View Post
    I've read that very fast and may have skiped stuff but some problems he presented are not truly valid, he created If wayland and then said what if then it dosent work on mir? create a if mir ...
    also he said "If the toolkit would just abstract away all the display server differences our applications libraries would not have crashed"
    like i said the previus post this could be created
    You asked for an example where the program has to talk directly to the display server. The article has an example.

    Quote Originally Posted by TheSoulz View Post
    "Sure, but it still means developers need to code three solutions to their problem instead of two. It is adding additional work that wouldn't have been necessary."
    that would be ludacris, you would create a library inside the toolkit or something and all apps target it.
    if all apps created it inside theyr own code would be unnessary bloat.
    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.

    Quote Originally Posted by TheSoulz View Post
    "There will never be tools to cover every use case. And writing the tools still requires three different code paths instead of two, so it doesn't change anything, it just pushs the same problem into a different part of the software stack."
    there never is, but for moust commun cases it would work farly well i belive, sometimes when you create something more fancy you already know you will have more work.
    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.

  2. #72
    Join Date
    Feb 2014
    Posts
    116

    Default

    Quote Originally Posted by TheBlackCat View Post
    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.

  3. #73
    Join Date
    Feb 2014
    Posts
    116

    Default

    for those like me that actualy like to learn what they are talking about heres where im starting:
    http://qt-project.org/doc/qtcreator-...g-program.html

  4. #74
    Join Date
    Feb 2013
    Posts
    51

    Default

    Quote Originally Posted by smitty3268 View Post
    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
    Quote Originally Posted by TheBlackCat
    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
    Last edited by silix; 08-28-2014 at 12:40 PM.

  5. #75
    Join Date
    Feb 2013
    Posts
    51

    Default

    Quote Originally Posted by TheSoulz View Post
    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

  6. #76
    Join Date
    Oct 2013
    Posts
    418

    Default

    Quote Originally Posted by smitty3268 View Post
    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

  7. #77
    Join Date
    Sep 2012
    Posts
    754

    Default

    Quote Originally Posted by silix View Post
    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).

  8. #78
    Join Date
    Feb 2011
    Posts
    1,252

    Default

    Quote Originally Posted by TheSoulz View Post
    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.

    Quote Originally Posted by TheSoulz View Post
    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.

    Quote Originally Posted by TheSoulz View Post
    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.

    Quote Originally Posted by TheSoulz View Post
    a stupid example for creating a window
    Creating a window is not the problem here.
    Last edited by TheBlackCat; 08-29-2014 at 05:23 AM.

  9. #79
    Join Date
    Feb 2013
    Posts
    51

    Default

    Quote Originally Posted by erendorn View Post
    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...

  10. #80
    Join Date
    Sep 2012
    Posts
    754

    Default

    Quote Originally Posted by silix View Post
    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.
    Quote Originally Posted by silix View Post
    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.

    Quote Originally Posted by silix View Post
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •