SURVEY: Lite XL on Wayland

[takase1121]

@franko has been trying to collect Lite XL UX data on Wayland for a while now.

Some reported that Lite XL on wayland is extremely slow, eg #442 while others reported it's fine. For me, using Wayland straight up crashes Lite XL.

What's your experience using Lite XL on Wayland? Please describe your experience + some information about your computer.

Note: please use SDL_VIDEODRIVER=wayland to enable experimental Wayland support.

[jgmdev]

I use it mostly under Wayfire which is a wayland compositor that uses wlroots and it works nicely as long as one uses default XWayland backend. It does gets laggy at rendering if one uses the SDL wayland backend by doing SDL_VIDEODRIVER=wayland lite-xl

Besides the lag issue with wayland backend I have tested lite-xl on Gnome Wayland, KDE Plasma Wayland and Sway. On all of them it seems to work normally.

Edit:
SDL v2.0.16, Self compiled Lite-XL

[franko]

Just for information, the linux binaries I provide are linked to SDL2 2.0.16 but this latter is compiled without Wayland support.

It is important to know if people use lite-xl compiled by themselves, provided by the package manager or from the release package.

In addition it seems that the SDL version matters a lot with the new 2.0.16 behaving a lot better.

I think we should compile a table to sort all these different cases.

[Guldoman]

In Arch, intel gpu, mesa 21.2.1, GNOME, SDL 2.0.16, with SDL_VIDEODRIVER=wayland, compiled from master:

• The first paint is often buggy:
  

• Sometimes it glitches out:
  

• We don't have client side decorations

• The application icon is missing

Otherwise it is smooth.

None of these problems appear when using SDL_VIDEODRIVER=x11.

[vincens2005]

OpenSuse Tumbleweed, intel gpu, Mesa 21.2.0, KDE Plasma, downloaded from releases.
Whenever I manually set the SDL_VIDEODRIVER variable, be it to xcb or wayland, lite-xl crashes with this error:

lite-xl: ../src/renderer.c:98: ren_init: Assertion `win' failed.

However, with no setting on the variable (which I think defaults to xcb), lite-xl runs very smoothly. Dragging files over the window does not work, but that is the only issue I have had.

[Guldoman]

...downloaded from releases.
Whenever I manually set the SDL_VIDEODRIVER variable, be it to xcb or wayland, lite-xl crashes with this error:

I believe that this is to be expected:

Just for information, the linux binaries I provide are linked to SDL2 2.0.16 but this latter is compiled without Wayland support.

(which I think defaults to xcb)

According to https://wiki.libsdl.org/FAQUsingSDL the available options are x11, directfb and wayland. So I guess it crashes when you use xcb because it's not recognized.

[vincens2005]

okay, setting it to x11 works but it still crashes with the same error when it's set to wayland

[vincens2005]

after compiling it from master myself using the latest freetype built from master and the latest sdl built from master, using SDL_VIDEODRIVER=wayland works. I see similar glitches to @Guldoman 's , and the scale is a lot larger than it should be. I also get this error when dragging a file onto the window.

[franko]

Thank you for the report, I see there are quite some problems using wayland natively.

When you compile yourself you may try the meson build option -Drenderer=true, I may behave better and it is interesting to know.

[Surendrajat]

Sway on fedora (with Xwayland)
Lite XL downloaded from release and works fine. Didn't notice any issue at all.

[cyanreg]

Using the Wayland SDL backend without -Drenderer=false, there are damage issues, particularly with autocomplete popups.
With -Drenderer=true, there's a very large delay between hitting a key and it appearing on screen. Mouse scrolling is just as quick as before, though.
SDL wasn't really designed for such use-cases, so even getting this far is saying something.

[bermudi]

Running Archlinux on an Asus L210.

I'm using Sway with xwayland disable.

Either I had a big black rectangle blocking the top half of the window (or rather not rendering correctly) or the window rendered correctly but the mouse had lots of issues. Eg. I clicked a folder and when I tried to move the mouse down to select a file the folder would collapse and hide the files again or sometimes the window wouldn't respond to mouse clicks

Unfortunately it is in a unusable state at least on my specific configuration.

[takase1121]

I got my hands on some other laptop and installed Fedora 34 on it

As usual the first paint is terrible

Keyboard input doesn't work (only text input, not arrow, shift, etc)
Escape key doesn't work.

It throws a segfault when it quits.

[Sakura0134]

It works fine in KDE.

[volucris1]

Works fine with EndeavourOS and Sway

[Nightwing13]

Wayland is broken with KWin

[Mrfiregem]

Much like this comment, lite-xl works great without, but with SDL_VIDEODRIVER=wayland has screen blacking when first using the sidebar or other GUI elements, and there is a very noticeable input lag.

This is using river v0.1.0 with wl-roots v0.14.1 on Arch. One odd thing I noticed, settinging SDL_VIDEODRIVER equal to '' or 'x11' makes the app open in floating mode instead of tiling by default, which is kind of annoying.

[takase1121]

Please test with SDL_VIDEODRIVER=wayland. SDL2 had always worked on X11 and will work on XWayland. Testing on raw Wayland is way more important.

[Mrfiregem]

Please test with SDL_VIDEODRIVER=wayland. SDL2 had always worked on X11 and will work on XWayland. Testing on raw Wayland is way more important.

I'm not sure what you mean, that is what my comment is referring to.

[elder-n00b]

Just found this project, cool. First run (on Sway):

Pentium(R) Dual-Core CPU T4400 @ 2.20GHz
ATI RV710/M92 [Mobility Radeon HD 4530/4570/545v]
3.8 GB RAM

 λ git describe --long
v1.11-lite-xl-1276-g8caccbf
# oh well

  λ /bin/ls -1d subprojects/*-*
subprojects/freetype-2.11.1
subprojects/lua-5.4.3
subprojects/pcre2-10.39
subprojects/SDL2-2.0.18

 λ pacman -Q wayland wlroots sway
wayland 1.20.0-1
wlroots 0.15.1-2
sway 1:1.7-2

./build-packages.sh -p /opt

 λ SDL_VIDEODRIVER=wayland ./scripts/run-local build-linux-x86_64/
running ninja
ninja: Entering directory `build-linux-x86_64/'
ninja: no work to do.
copying lite executable and data
running "lite-xl " with local HOME

The very first run resulted in corrupted graphics: black, colored and "random looking" rectangles, they would come and go while operating the editor.
Interestingly, I could not reproduce that issue any more after restarting it -- who knows, but for now it seems to have healed by itself.
I tried drag-dropping files from the Thunar file manager, no problem -- this with the expanded package, otherwise with run-local (I surmise, because of the "local HOME" thing) the result was a tab with the filename but no text.
With a few files, it was fast to start, type, and scroll, both on xwayland and wayland proper.
With too many files it became slow as molasses, but that may well be a memory problem as I also have the browser open with ~80 tabs at the same time (and my laptop is old), or some of the default plugins struggling. The "test" was:

 λ time fd '\.(c|h)$' ~/some-directory/ |wc -l
1491

________________________________________________________
Executed in  324,60 millis    fish           external
   usr time  349,39 millis    0,70 millis  348,69 millis
   sys time  249,39 millis    1,43 millis  247,96 millis

time ./_package/lite-xl/opt/bin/lite-xl

________________________________________________________
Executed in  657,07 millis    fish           external
   usr time  224,50 millis    0,18 millis  224,32 millis
   sys time   69,91 millis    1,12 millis   68,79 millis
# ==> closed lite-xl as soon as it showed up with keyboard shortcut, not much time wasted.

 λ time fd '\.(c|h)$' ~/some-directory/ |xargs ./_package/lite-xl/opt/bin/lite-xl # <== this is the built package

________________________________________________________
Executed in   70,03 secs    fish           external
   usr time   69,14 secs    0,72 millis   69,14 secs
   sys time    0,84 secs    1,84 millis    0,84 secs
# ==> closed lite-xl as soon as it showed up with keyboard shortcut, not much time wasted.

 λ time fd '\.(c|h)$' ~/some-directory/ |xargs ./bin/lite-xl # <== this is the 2.0.5 luajit release

________________________________________________________
Executed in   32,50 secs    fish           external
   usr time   29,56 secs    1,73 millis   29,56 secs
   sys time    0,71 secs    0,83 millis    0,71 secs

Trying a second time and leaving it open, I noticed only a dozen files in the file manager panel and tab bar, and the editor was functioning but so slow as to be inoperable. Killed. Still no graphic glitch, just the lower half of the window took half second to draw.
The luajit release (on xwayland) took half the time to start and was somewhat less unresponsive with all those files.
Later I'll try soon after reboot, actually using it to edit a sane number of files, and with the luajit one compiled from sources.

A side note, I tried the -f --forcefallback Force to build subprojects dependencies statically option to build-packages.sh and it resulted in a functioning but apparently X11-only build -- running with SDL_VIDEODRIVER=wayland crashed the same as the release.

[arun54321]

SDL_VIDEODRIVER=wayland  lite-xl
lite-xl: ../src/renderer.c:98: ren_init: Assertion `win' failed.
[1]    69365 IOT instruction (core dumped)  SDL_VIDEODRIVER=wayland lite-xl

gnome wayland. fedora 35.

[franko]

gnome wayland. fedora 35.

Thank you for sharing these details about the crash.

What version of Lite XL you was using ? If you compiled the application by yourself did you use the standard "dev" packages from your distribution for SDL ? What version of SDL is your distribution providing ?

[Guldoman]

SDL_VIDEODRIVER=wayland  lite-xl
lite-xl: ../src/renderer.c:98: ren_init: Assertion `win' failed.
[1]    69365 IOT instruction (core dumped)  SDL_VIDEODRIVER=wayland lite-xl

gnome wayland. fedora 35.

If you used the latest release build, this is to be expected as it's compiled without wayland support.
Could you test by building from master?

[TorchedSammy]

on fedora 35, with sway, lite-xl runs and is almost perfect albeit with the first glitch mentioned here

but i also noticed one time that it discolored the entire window

[arun54321]

gnome wayland. fedora 35.

Thank you for sharing these details about the crash.

What version of Lite XL you was using ? If you compiled the application by yourself did you use the standard "dev" packages from your distribution for SDL ? What version of SDL is your distribution providing ?

I've compiled it from source.I t works now. There is always a glitch for few seconds after opening and it works fine afterwards.

[Guldoman]

Testing with SDL from their git repo, the first paint problem doesn't seem to happen anymore. Can anyone test that too?

[arun54321]

I have used SDL2 from fedora repos.

[takase1121]

This is how it looks for me at first load with sdl 2.0.20 and lite-xl build from master

After scrolling the document everything is rendered but sometimes moving the mouse around causes black squares (pieces not been re-rendered). Also if I minimize the window or change to another window I get black squares again, maybe something related to the code that stops lite-xl rendering when not focused to save cpu cycles?

Testing with SDL from their git repo, the first paint problem doesn't seem to happen anymore. Can anyone test that too?

will give that a try

Looks legit to me, you just have to scroll around to use the editor :)

[jgmdev]

Testing with SDL from their git repo, the first paint problem doesn't seem to happen anymore. Can anyone test that too?

Confirmed, built sdl from master 2.0.20.r217.gb2463a917 and it is rendering normally on wayland without any issues so far

[darltrash]

No problems here so far except the scale and the weird bar (though the weird bar is already fixed on SDL2's master branch afaik)

[devlocalhost]

Working on my 17 year old 32bit laptop using void linux, SDL 2.0.22 (sdl2-config --version), xwayland, with gnome 41.5. It also works using "SDL_VIDEODRIVER=wayland". (But I'm facing a issue. I can't launch lite-xl from overview. I can launch it only by opening a terminal. This does not happen on xorg)

[Guldoman]

Does resizing work smoothly?

[devlocalhost]

Does resizing work smoothly?

Using a DE (gnome) it's not smooth (normal, since poor hardware, but other apps resize smoothly... But, using a WM (dwm, xorg) it's very smooth)

[Guldoman]

Using a DE (gnome) it's not smooth (normal, since poor hardware, but other apps resize smoothly...

I'm having the same experience on GNOME, but my hardware is decent. I wonder if this problem is caused by GNOME, SDL or us.

[devlocalhost]

Using a DE (gnome) it's not smooth (normal, since poor hardware, but other apps resize smoothly...

I'm having the same experience on GNOME, but my hardware is decent. I wonder if this problem is caused by GNOME, SDL or us.

You can try a different DE using wayland (KDE maybe?)

[jonian]

Arch Linux, SDL2 2.0.22, Gnome 42.2. Works fine, no performance issues. Decorations are missing and looks like scaled up.
Edit: decorations where missing because I did not have libdecor installed. Maybe it should be added as an optional dependency in the AUR package.

[1player]

Resizing is terribly slow for me on Fedora Silverblue 36 with the editor in Wayland mode.

[Guldoman]

Resizing is terribly slow for me on Fedora Silverblue 36 with the editor in Wayland mode.

Try with config.borderless = true.

If that works smoothly, I think that the problem is in libdecor itself https://gitlab.gnome.org/jadahl/libdecor/-/issues/37

[1player]

Yes, it's perfectly smooth with config.borderless = true. BTW I'm on a AMD card, not NVIDIA

[1player]

Additionally, pixel scaling is incorrect, the UI size is correct (not shrunk by half), but in 96 dpi instead of 192 dpi like the rest of the desktop which is rendered in 200% scaling.

X11 mode:

Wayland mode:

[Guldoman]

Yeah scaling support is in the works in #998.

[jvoisin]

No decorations on 43.1 with libdecord-0-0 installed. Except this, everything looks good.

[Guldoman]

No decorations on 43.1 with libdecord-0-0 installed. Except this, everything looks good.

Is this self-compiled?

[jvoisin]

Nope, it's from the github releases.

[Guldoman]

What distro?

[jvoisin]

Debian Testing x64.

[Guldoman]

Mmm weird that it doesn't find it. We'll see if there is a way to statically link it.
For now you can set config.borderless = true in your user module.

[ColonelPhantom]

Works well on my machine (Arch Linux, Mesa 22.3.3, KDE Plasma 5.26.5, Lite XL 2.1.1 from AUR). I did notice that sometimes it was very glitchy, but I cannot reliably reproduce. I did notice that when it happened I got a lot of "exhausted command buffer" warnings, which I have heard are fixed in the next version of Lite XL.

It does seem like scaling is being handled by KWin, leading to a rather blurry whole. Would be great if it integrated with LiteXL's built-in scaling! (I don't think this is specific to native-Wayland, but would still be quite nice.)

[maroozm]

window decoration look so ugly on wayland gnome? is there a fix?

[takase1121]

window decoration look so ugly on wayland gnome? is there a fix?

If you disable config.borderless you'll get a border drawn by libdecor. Hopefully this is what you want.

Other than that, we do have plans to improve the window decoration, since going forward we're most likely sticking to it on Wayland. There is currently no way to detect if the WM supports server side decorations via SDL, so this is the safest way on Wayland.

[iggy]

Should bugs found with lite-xl (only) on Wayland be reported as new issues or here?

[Guldoman]

Feel free to open new issues.

[exoess]

Everything kinda works, it only launches natively if I open it from the terminal using lite-xl, but if I open it with wofi or rofi it opens with xwayland

Edit: Scratch what I said about no issues, for some reason it doesn't follow the cursor correctly

[kra-mo]

On mutter 45/46, the window size is not restored correctly if the app has been maximized, it will get into this glitched state:

Screencast.from.2024-01-28.10-53-44.webm

The cursor also disappears sometimes.

[devlocalhost]

On mutter 45/46, the window size is not restored correctly if the app has been maximized, it will get into this glitched state:

Screencast.from.2024-01-28.10-53-44.webm
The cursor also disappears sometimes.

Yeah, I have that issue too