[HN Gopher] Improving Xwayland window resizing
       ___________________________________________________________________
        
       Improving Xwayland window resizing
        
       Author : TangerineDream
       Score  : 27 points
       Date   : 2024-10-28 20:18 UTC (2 hours ago)
        
 (HTM) web link (blog.vladzahorodnii.com)
 (TXT) w3m dump (blog.vladzahorodnii.com)
        
       | anotherhue wrote:
       | I like to run xeyes and see if they move when I interact with the
       | test application. It's not better but they're as charming as they
       | always were.
       | 
       | Also consider running an xwayland app under gamescope which
       | smooths out some issues.
        
         | yjftsjthsd-h wrote:
         | I would argue that it _is_ better; it works regardless of this
         | fix and on all compositors.
        
       | yxhuvud wrote:
       | Hmm. Even with the fix it didn't look very smooth even if it is a
       | lot better. I wonder if that is due to the recording, or due to
       | the mouse settings (mouse poll rate and acceleration settings are
       | very impactful on smoothness), due to X or the toolkit, or due to
       | it not being as good as it can be.
        
       | Arainach wrote:
       | Excellent writeup, thanks for posting. I was involved with
       | efforts to achieve similar things in Windows (Direct Composition,
       | etc.). In practice, it was enlightening to debug various apps and
       | frameworks and discover just how long repainting can take and how
       | many edge cases there are around slow apps, hung apps, and so on.
       | Who knows, maybe someone there still has some of the malicious
       | test apps I wrote (using the language of this article, apps which
       | acknowledge the sync request and then take multiple seconds to
       | actually paint, etc., etc.).
       | 
       | It's definitely a hard problem space that's basically
       | incompatible with how most GUI apps and frameworks worked from
       | 1985-2015.
        
       | o11c wrote:
       | For me, the quickest way to tell that I'm running on Wayland is
       | seeing if multi-lingual keyboard input is broken. I have right-
       | alt-while-pressed set to switch to a Greek layout (because who
       | doesn't math?), and it reliably works on X11 but breaks in all
       | sorts of weird ways under Wayland (sometimes it simply fails to
       | enable/disable, sometimes it shows a notification as if it
       | changed but switches back when input actually happens, ...).
       | 
       | On the bright side I'm finally learning how Vim's digraphs work.
        
         | porphyra wrote:
         | Multilingual keyboard input is such a mess haha. I need to type
         | a lot of Chinese using pinyin and still haven't found a
         | reasonably polished implementation on Wayland (Sway) that works
         | on both Xwayland and true Wayland applications. So I reverted
         | to i3 with ibus.
        
       | ryandrake wrote:
       | Nice results. It's kind of wild that the "before" behavior would
       | be considered acceptable/shippable by anyone. That kind of jank
       | should be a show stopper.
        
         | porphyra wrote:
         | Linux desktop is full of such jank. Fortunately, thanks to
         | contributors like OP, the jank is gradually getting fixed. The
         | whole point of Wayland is to eliminate a whole class of jank
         | (screen tearing) that was essentially unfixable with X.
        
           | o11c wrote:
           | And yet, empirically, jank is far more common on Wayland than
           | X11. With X11, on the rare case I noticed, it was usually
           | just a matter of "okay, which toolkit or driver do I need to
           | look up the vsync environment variable for?"
           | 
           | I have no opposition to Wayland in _theory_ ; my concerns are
           | entirely practical and unignorable.
        
         | bsder wrote:
         | "Jank" is still functional. And, to a first order
         | approximation, _nobody cares_.
         | 
         | Even Windows generally switches down to software rendering when
         | resizing. And on mobile devices, nobody resizes.
         | 
         | No pointer warp, however, is a failure (CAD packages all have
         | significant issues on Wayland). Lack of multilingual
         | support/accessibility is a failure. Lack of
         | screenshots/screencasts is a failure. Lack of support for the
         | BSD lineages is a failure. etc.
         | 
         | People are still bitching up a storm because Wayland _still_
         | (Pipewire does screen sharing using DBUS(!) for example) hasn
         | 't fixed basic things while DeadRat is shoving it down
         | everybody's throat by dropping X11 support.
         | 
         | The Wayland devs aren't wrong about the security implications
         | of this kind of stuff. However, they're also not giving anybody
         | _solutions_ , either.
         | 
         | One big issue is that Wayland devlopment is so slow that the
         | entire space moved forward and destroyed a bunch of assumptions
         | that Wayland is based around.
        
       ___________________________________________________________________
       (page generated 2024-10-28 23:00 UTC)