Linux Wayland glitches about azul HOT 17 CLOSED

For what it's worth, the upcoming release of winit will bring a lot of improvements regarding wayland support, and alacritty build on the master branch of winit is fully functional on native wayland, including hidpi support.

from azul.

Imagine that every windowing toolkit (SDL, winit, etc.) doesn't only have to be responsible for managing the window size and position, but also drawing its title and making sure that its title looks like the DE.

Yes, that's kind of the horror I want to avoid with SCTK and winit. As such the policy I've chosen is to use xdg-decorations to request server-side decorations if it is available, and if not fallback to simple and functional decorations (whose looks have been improved, see rust-windowing/winit#671 ). I don't plan to introduce logic to try to match GTK or Qt looks in SCTK, it'd be way out of scope and far too complex.

from azul.

@kennylevinsen Yes, there is a way that both CSD and azul can get along - if mutter would implement xdg-decorations. Every other DE has support for xdg-decorations, which is the more-or-less "standard" way to draw window decorations on wayland - except for mutter. There is no technical reason for them not implementing it, just look at this issue if you don't believe me.

I do not know how hard this would be to implement

Very hard, that's the problem. And it could so easily be avoided if mutter implemented xdg-decorations (like every other DE in existence). Imagine that every windowing toolkit (SDL, winit, etc.) doesn't only have to be responsible for managing the window size and position, but also drawing its title and making sure that its title looks like the DE. That means dependencies on system-specific config files, dependencies on OpenGL or another drawing API, dependencies on XML and CSS parsers, dependencies on dbus, etc. - duplicated code across every window toolkit, just because one, one single DE (mutter) doesn't want to play nicely. At that point, I simply don't care about their DE - it's not that I don't care about wayland, I just don't care about wayland on mutter. Either they implement xdg-decorations like every other DE or wayland decorations are going to look shitty and non-native.

Yes, azul is going to support wayland properly (when winit is fixed), but I am not going to code DE-specific exceptions and workarounds. It's something that has to be fixed in mutter, not in a downstream toolkit.

The way Windows handles SSD is really the most sane: If a window wants SSD, the DE will simply resize the the existing window to the new size, which covers the title bar. Then the application tells the DE to draw the window decorations on top of the current window. That's it, simple as that. I've implemented it here for winit.

If you want to complain, complain to Gnome devs in the issue linked above, that's all I can say. I am simply not going to use GTK as a windowing toolkit for azul. Gnome wants everyone to use Gnome, but then azul would just be a toolkit centered around Gnome, which is not the point.

from azul.

@myfreeweb - feel free to do if yourself, but I won't port it or put it in azul. I want azul to be a framework that can stand on its own and not rely on GTK or QT, otherwise it'd just be a wrapper around GTK or QT again, which I absolutely don't want. Every other window manager can draw window decorations just fine, even on the client-side - just mutter can't. There is no technical reason why they don't want it, other than "doesn't fit our bill, deal with it". And I don't support that attitude.

The only way their applications can get "fixed" is by converting them to the Gnome™ platform with Gnome™ approved libraries. I am sick of this ignorant-towards-other-toolkits attitude (this isn't the first time they've pulled this). And for such ignorant developers - no, I won't maintain a separate GTK backend just to please their platform.

You're free to do it if you like and I can help you with issues regarding azul if they arise, it's just that I don't want to maintain it and I don't want it in azul itself. I hope my view is understandable.

And potentially also for file dialogs

Azul already uses the native file dialog chooser for each platform (zenity, kfiledialog, etc.). However, the file chooser is determined at runtime and azul doesn't need to link against any library for that. GTKs file dialog looks really out of place on KDE, for example, something which doesn't happen with Azul.

HiDPI should work, though, as it works independent of wayland. The bug is just related to positioning and sizing of wayland surfaces.

from azul.

Okay, I've reproduced the issue and it's not the same as on macOS - the window does get redrawn correctly, just not at the right position.

• When the window is resized to be smaller, the window size increases instead.
• The initial bug may have something to do with the HiDPI factor, not sure about that, however.
• The hit-testing work as if the window is rendered normally, meaning that the keyboard / mouse events work as expected and it's just a rendering issue.

These are bugs in winit - according to rust-windowing/winit#305 (comment) and rust-windowing/winit#306 these things should be resolved in the future, but winit simply has little to almost no proper wayland support. For example, the reason there are no native decorations seems to be a bug in mutter / GNOME specific - wayland is still in its very early stages.

The program does run properly on xwayland, however. So if you want to run the calculator right now, simply use xwayland by setting the WINIT_UNIX_BACKEND environment variable to "x11":

export WINIT_UNIX_BACKEND="x11"
cargo run --release --no-default-features --example calculator

Or you could do this in your main() function, obviously. This also fixes the missing window decorations:

I really can't say when these things will be fixed. I am not that invested in wayland, simply because, well I don't use wayland and there's always X11 or xwayland. Not to say it's not important, but I need to manage my time, too. If you want to push these things forward, contact @vberger and help him with getting winit to work on wayland properly.

from azul.

Would be cool to maybe have a (build) option to use GTK for windowing instead of winit? (And potentially also for file dialogs, etc.)

I made galacritty, a GTK based Alacritty wrapper, and it has perfect Wayland+HiDPI support :)

the reason there are no native decorations seems to be a bug in mutter

Not really a bug, mutter intentionally doesn't support server-side decorations.

from azul.

Every other window manager can draw window decorations just fine, even on the client-side - just mutter can't. There is no technical reason why they don't want it, other than "doesn't fit our bill, deal with it". And I don't support that attitude.

The only way their applications can get "fixed" is by converting them to the Gnome™ platform with Gnome™ approved libraries. I am sick of this ignorant-towards-other-toolkits attitude (this isn't the first time they've pulled this). And for such ignorant developers - no, I won't maintain a separate GTK backend just to please their platform.

I'd just like to add my two cents here: This isn't a matter of it being a "Gnome™" platform, but simply that client-side decorations are a pretty big thing these days, and that wayland does not require support for server-side decorations. If I am not mistaken, baseline Wayland compatibility requires support for client-side decorations for this reason. I'd argue that avoiding duplicated functionality is a good idea.

While I certainly have my own gripes with Gnome and Wayland (for example, I dislike that mutter ever implemented nVidia's awful EGLStream suggestion), and many other projects for that matter, it is important to remember that large distributions has been shipping Wayland for quite a while (such as Fedora), and that Gnome is a very major desktop environment. XWayland does not provide a good user-experience (it's a better-than-nothing situation), and X is dying.

Thus, embracing Wayland is the only sensible choice. If you have things that you dislike, enter the debates. Doing what I, as both a developer and an end-user, would see as handicapping your own project and the applications that may build upon it, does not seem like a decision that benefits anyone, including you. Azul has potential, and it would be sad if end-users ended up seeing Azul as an anti-feature.

(I would also like to add that I was going to suggest implementing CSD support anyway before even reaching this issue. This is a modern and very popular design decision, to the point where SSD apps look out of place and outdated. I do not know how hard this would be to implement—styling wise, it should "just" be a matter of disabling title-bars, but I do not know how window movement ends up being handled.)

</end of rant>

Keep up the good work. I'm watching the project closely, as it looks very useful, even if all my machines run Wayland. :)

from azul.

I am aware of this, it has to do with how resizing events in winit / wayland work. Layout isn't the problem, it's that the resizing event gets ignored for some reason, so when you resize the window, it doesn't update the screen. This is more or less the same problem as on MacOS. I mean, at least it renders something, so that's a start, on MacOS, it doesn't even do that correctly.

If you do want to help debugging this: try running the webrender demos and look in the app.rs file where the renderer (from webrender) gets called. There is probably some difference between azul and webrender. Right now I've only tested it under X11, but I'll take a look later.

Note to self: there needs to be something done about the title bars, which are currently drawn by winit / sctk. However, I'm not sure how to integrate them with KDE / Gnome properly (since in wayland, every application has to draw it's own decorations). But somehow I should be able to get the users CSS styles, and then draw the title bar manually.

from azul.

alacritty has a similar issue with a workaround -- maybe it applies here?

from azul.

As for the actual issue (this got a bit off-topic, sorry):

I think for the forseeable future, proper wayland support is a pipe dream, so xwayland is the next best thing. Not perfect, but at least you can run apps under wayland, instead of them being glitchy and unusable. So a "solution" would be to simply introduce a flag in azul to choose between real-wayland and xwayland, with xwayland being the default.

from azul.

@vberger Good, then I'll just wait for the next winit release, which should then fix these glitches with wayland (at least the resizing). Window decorations are a separate topic.

from azul.

@fschutt

Yes, there is a way that both CSD and azul can get along - if mutter would implement xdg-decorations. Every other DE has support for xdg-decorations, which is the more-or-less "standard" way to draw window decorations on wayland - except for mutter.

I'm sorry, but this does not make sense. XDG-Decorations is a server-side decorations spec. How does that make Azul get along with client-side decorations?

If I am not mistaken, only wl-roots and KDE supports this optional extension. It is neither standard nor status quo. However, whether or not it is a good idea is not related to whether or not it is standard.

There is no technical reason for them not implementing it, just look at this issue if you don't believe me.

Of course there is no technical reason. It was never a technical problem. It is a matter of whether there should be multiple ways to draw decorations, rather than the current (and technically the standard and status quo) approach for Wayland environments. I have no strong opinion here, other than disliking duplicated functionality, as well as respecting the status quo.

Very hard, that's the problem. And it could so easily be avoided if mutter implemented xdg-decorations (like every other DE in existence).

I asked if it would be hard to let the user draw their own decorations (which many will want to do), through Azul's DOM API, rather than have any system provided ones. This would require support from smithey-client-toolkit from what I can tell.

Letting the user draw their own decorations, mimicking the platform if they wish to do so, seems like the obvious and best solution to me.

XDG-Decorations would not allow users to draw their own decorations.

If you want to complain, complain to Gnome devs in the issue linked above

It is a wayland community problem (i.e. "should server-side decoration support be implemented by compositors by default"), but I have no problem with the Gnome devs decision.

I see the convenience of having the window manager draw your toolbar for you, but at the same time, standard toolbars are getting less and less popular, and duplicated functionality is not great either.

I also support not complicating your code with GTK or Qt dirt, but you must realize that a Wayland environment without server-side decorations will be a huge chunk of Linux users soon, if not the vast majority, so the end-users should be catered to. Either by engaging in the discussion as a framework author and getting all wayland compositors to adopt server-side decorations, or by finding a way to work with the status quo.

I would just find it sad if Azul ends up not being as practical as it could be. However, note that I am simply sharing my opinion. The decision is all yours.

from azul.

If I am not mistaken, only wl-roots and KDE supports this optional extension. It is neither standard nor status quo. However, whether or not it is a good idea is not related to whether or not it is standard.

It having been merged in the wayland-protocols repo arguably makes it as standard as a protocol can be though: https://github.com/wayland-project/wayland-protocols/tree/master/unstable/xdg-decoration

I asked if it would be hard to let the user draw their own decorations (which many will want to do), through Azul's DOM API, rather than have any system provided ones. This would require support from smithey-client-toolkit from what I can tell.

Smithay's Client Toolkit can support that with pretty trivial API additions. And it would require some work in winit to support manually starting interactive resizes and interactive moves, but that's about it.

from azul.

When compiling with smithay-client-toolkit 0.4, winit git, glutin 0.18, gilium git with small patch, the same glitches seem to occur.

I did fix a similar issue in alacritty/alacritty#1518 that might also be related to this, the tldr for that issue as I recall was that calling glClear after swapping buffers caused glitches.

from azul.

@vberger Well, it doesn't seem like the new winit (now 0.19.0) has fixed much:

The hit-testing is still off (i.e. when I press the "9", I get a "3"), meaning that the cursor input is handled properly, but the rendering is offset by a certain size.

from azul.

It looks like, for some reason, azul is not properly resizing its opengl surface as it should. I don't know anything about azul's code, but it looks like exactly what would happen if this event handling was missing. See GlWindow::resize.

from azul.

As @vberger stated, calling GlWindow::resize seems to fix the issue. As in #106

from azul.