Announcement

Collapse
No announcement yet.

Another Attempt At Reducing GNOME's Mutter Input Latency

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

  • torturedutopian
    replied
    > Another performance patch got in. Yay.

    Wow, patch description sounds simple but effective :-) That's surprising that wasn't the default behaviour !

    Leave a comment:


  • 144Hz
    replied
    https://gitlab.gnome.org/GNOME/mutte...e_requests/568

    Another performance patch got in. Yay.

    Leave a comment:


  • torturedutopian
    replied
    Originally posted by tildearrow View Post
    Oh, Daniel, you get a chance in mainline...

    Time to try to upstream my efforts on the KWin side!
    Please do ! :-)

    Leave a comment:


  • polarathene
    replied
    Originally posted by tildearrow View Post
    Oh, Daniel, you get a chance in mainline...

    Time to try to upstream my efforts on the KWin side!
    That'd be good! There was that other dev who had their own patch for rendering GTK apps with kwin frames or something too, but they weren't interested in trying to get it merged upstream into kwin

    https://www.reddit.com/r/kde/comment..._support_sick/
    Last edited by polarathene; 07-01-2019, 09:07 PM.

    Leave a comment:


  • RealNC
    replied
    Originally posted by torturedutopian View Post
    My dumb user question : does this patch only affect windowed-apps or also fullscreen apps... (obviously I'm referring to games ;-) ?
    Applications don't get their input events from the window manager, so I'd say this doesn't affect applications at all (fullscreen or not.)

    Leave a comment:


  • tildearrow
    replied
    Oh, Daniel, you get a chance in mainline...

    Time to try to upstream my efforts on the KWin side!

    Leave a comment:


  • Britoid
    replied
    Originally posted by AsuMagic View Post

    AFAIK full screen apps are indirected so the compositor doesn't compose them. So it should not matter.
    I would think given this MR is about input latency, compositor output latency is not really relevant.

    Originally posted by treba View Post

    If I get things right, this MR is mostly about Wayland (see https://gitlab.gnome.org/GNOME/mutte...68#note_530925), but could be wrong here. In that case, fullscreen games would be affected as they don't yet get unredirected there. Although there's ongoing work by Jonas Adahl to make it work under Wayland, which might even land for 3.34 (the concept is quite different, though. The term 'unredirect' doesn't really apply. And event delivery would still be handled by the compositor, so this MR would still apply there).
    Yeh. "Unredirection" doesn't really exist in the Wayland world in the same way. I think on Wayland it's more about the compositor getting as much out of the way as possible for full screen applications.
    Last edited by Britoid; 07-01-2019, 10:39 AM.

    Leave a comment:


  • treba
    replied
    Originally posted by AsuMagic View Post

    AFAIK full screen apps are indirected so the compositor doesn't compose them. So it should not matter.
    If I get things right, this MR is mostly about Wayland (see https://gitlab.gnome.org/GNOME/mutte...68#note_530925), but could be wrong here. In that case, fullscreen games would be affected as they don't yet get unredirected there. Although there's ongoing work by Jonas Adahl to make it work under Wayland, which might even land for 3.34 (the concept is quite different, though. The term 'unredirect' doesn't really apply. And event delivery would still be handled by the compositor, so this MR would still apply there).

    Leave a comment:


  • AsuMagic
    replied
    Originally posted by torturedutopian View Post
    Thank you again, Daniel, great work !

    My dumb user question : does this patch only affect windowed-apps or also fullscreen apps... (obviously I'm referring to games ;-) ?
    AFAIK full screen apps are indirected so the compositor doesn't compose them. So it should not matter.

    Leave a comment:


  • 144Hz
    replied
    Reviewers are heroes too Anyway great to see the developers evaluate more than one approach.

    Looks like !568 is about to get merged as well.

    Leave a comment:

Working...
X