Announcement

Collapse
No announcement yet.

Wayland 1.0 Stable Release Is Imminent

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #76
    Originally posted by renox View Post
    I totally disagree: I prefer responsiveness over prettiness.
    When there is a separated window manager, if the application becomes busy, you can still draw the window outlines so the resizing still feel responsive (even if the content of the window becomes ugly),
    , with Weston this won't be the case, the window will freeze resizing until the application answer again..
    Weston is perfectly capable of doing outline resizes, and I'm not sure why you think it isn't.

    Originally posted by renox View Post
    The only way to have both is to ensure that the application is never busy by using multithreading, very,very nice when you have it but a big change.
    Still doesn't help if the app's waiting on I/O because everything got paged out.

    Originally posted by renox View Post
    And what about moving windows?
    Here, client side management of decorations looks even worse compared to server side management of decoration (except when the application is multithreaded)!
    How? Again, it's more fluid because the compositor moves the window directly and doesn't even need to tell the application ever. With X11, the pointer event goes to the window manager, which then tells the server where to move the window. Removing the round trip can only help.

    But there's no difference in client vs. WM decorations here at all, because the decorations are never relayouted or redrawn.

    Comment


    • #77
      Originally posted by daniels View Post
      Weston is perfectly capable of doing outline resizes, and I'm not sure why you think it isn't.
      I didn't say that Weston isn't capable of doing it, but as it is the application which decides that the mouseclick is a resize/move event (client side window decoration management), if the application is slow to answer then Weston cannot do anything until it decides that the application is stalled and then takeover.

      Originally posted by daniels View Post
      Still doesn't help if the app's waiting on I/O because everything got paged out.
      True, an additional drawback of having window management partially handled by the applications: as a window manager is used by all the applications it is less likely to be "paged out" and it could be locked into memory for distribution which wants to maximize responsiveness (difficult though as one must ensure that it use only a small amount of memory).

      Originally posted by daniels View Post
      How? Again, it's more fluid because the compositor moves the window directly and doesn't even need to tell the application ever.
      Wrong, with Weston it is the application which converts mouse clicks to 'move action' (client side decoration management) so the application is in the loop.

      Originally posted by daniels View Post
      With X11, the pointer event goes to the window manager, which then tells the server where to move the window. Removing the round trip can only help.
      Note that with remote display, the window manager is in the same station as the display server whereas the application isn't so the RTT is very different.
      With server side window management (which Weston doesn't do normally i.e. unless it decides that the application is stalled), the application doesn't need to be the loop when it is moved, whether it is best to have the window manager
      in the display server process or in a separated process is a different implementation issue.


      Originally posted by daniels View Post
      But there's no difference in client vs. WM decorations here at all, because the decorations are never relayouted or redrawn.
      This is not about drawing this is about RTT and event management, with server side window management you have much smaller RTT and the events are handled by code dedicated only to window management not by applications which do already many other things..

      Comment


      • #78
        Wayland is and has been for a long time developed by Intel and Collabora among other companies commercially.

        Comment


        • #79
          Originally posted by daniels View Post
          It's not 100%, since there is no acceptable solution to 'my app doesn't respond quickly to resize requests', but vastly better than before.

          The Wayland model is that the app tells the compositor to initiate a resize sequence, at which point the compositor just starts feeding the app resize events as appropriate. The then app sends the window with decorations already drawn, which is always safe to draw on screen. We've cut out a huge amount of the round trips and lag inherent in the X11 model, where the server would send a pointer update to the client, who would request a resize from the server, which would ask the WM what it thought; the WM would then paint a new frame and resize both its frame window and the real client window; the server notifies the app of a resize, at which point the app can finally draw its content. I left out all the app -> X server -> WM -> X server -> app roundtrips for synchronisation through window properties too - it looks even worse if you add those in.

          So yeah, I maintain that the problem's solved as well as it could be.
          And you're right, sorry for my mistake I thought that 'client side decoration' meant that each time the interpretation of every mouse clicks was sent to the client even when moving a window which isn't the case apparently, the client initiate a 'move grab' sequence and then the server can do the work alone, nice!
          Ooops, either I misread the documentation or there is a need of better documentation..

          Comment

          Working...
          X