[WIP] Wobbly windows effect

[TheSunCat]

Describe your PR, what does it fix/add?

This PR adds an optional wobble simulation to windows when they are moved. It implements #1184.

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

I need help rendering the effect as I am unsure how I could deform an entire window in Renderer.cpp without making the code a mess. My own code also requires a lot of cleanup, as it is heavily based on this C implementation and thus missing a lot of C++ niceties and style.
This is also missing configuration support, as it is enabled for all windows at the moment.
I will keep working this and adding commits.

Is it ready for merging, or does it need work?

This is not functional yet, but the base simulation is there.

[vaxerski]

Any usage of new and delete is strictly banned from the codebase.

Make configurable options: enabled, only floating and windowrules.

[TheSunCat]

Done :)

[TheSunCat]

I'm unsure how to approach the windowrule, but I think we should make sure this works before fleshing out the config. It will also need some configurable factors for the simulation (that together control wobblyness).

[vaxerski]

don't make wobble into a separate category, why?

[TheSunCat]

You said to name it enabled, and that can't go into animations as it would conflict with animations:enabled. We can rename it to animations:enable_wobble if you think that fits better.

[vaxerski]

wobble_enabled
wobble_other
wobble_stuff

[TheSunCat]

done

[TheSunCat]

Is there anything else I can do to help out with implementation of rendering?
I was thinking of making a separate shader for wobbly windows that take the simulation's parameters as input and in a geometry shader subdivide the four-vertex quad into the wobbled grid of verts it needs to be (taking the UVs with it). This way, we would not need as much code in the renderer side and simply plug in the shader program to replace the regular one. As for damage, it needs to be between the model's m_vTopLeft and m_vBottomRight vectors, which are updated every time the model is so it should contain the whole window.

[vaxerski]

the problem is with decorations, e.g. shadows. Wobbly windows in hyprland would require a major rewrite and probably would slow down computers noticeably, as how I am seeing it right now, would require drawing to a separate fbo, applying the wobble and then back to the main fbo, which will add up to 2 additional drawcalls per window.

I am still not convinced this is a good idea.

[TheSunCat]

Do you think we could make the extra drawcalls an optional control path, only if wobbly windows (or potential other effects that would require it) are enabled? I think a user enabling wobbly windows would be conscious that this can have a noticeable performance impact.
As for drawing to a separate framebuffer, yes this is a possibility, but why not just apply a geometry shader to the quads we already draw for windows (and presumably decorations; I'm unfamiliar with that part of the code)? This would only add zero draw calls: just using the different shader (and setting the uniforms).

[TheSunCat]

From my understanding of geometry shaders, this is exactly the kind of drawcall we can deform with a single glUseShader:
Borders rendering with glDrawArrays.

[vaxerski]

we could of course but this is likely to get ugly.

buddy the shadow is one quad, we're not subdividing it. Besides, many decos might draw multiple things (e.g. groupbar)

[TheSunCat]

It's the same glDrawArrays call which is easily subdivided and deformed alongside the surface itself + borders by a shader. No additional code would be required on the CPU side.
Geometry shaders can output more geometry than is input, so we would only need to subdivide them if the window is being wobbled.

[vaxerski]

feel free to attempt, but again, many things may draw multiple things, and text. Those can't be deformed this way.

You should probably try the fbo method.

[TheSunCat]

It would take me a lot of time to familiarize myself with the way Hyprland's rendering code works, as well as the many macros I see it uses. This is why I did not even try to implement rendering... I was hoping you might give it a try. I can make the necessary shader (just porting the calc geometry function to glsl) but integrating it into the renderer sounds like I'll just write even more spaghetti à la bolognaise than usual.

[vaxerski]

I can clean it up later, but I am not willing to write the impl.

[TheSunCat]

Understood. I will implement it when I find the time in that case, but expect a large portion of spaghetti.

[TheSunCat]

I'm reading through the code and it seems that, though Hyprland is using OpenGL ES 3.2, it has an optional OpenGL ES 2.0 backend. If I were to use a geometry shader, I would be unable to support that backend. Is this a problem, or is it okay for some features to be exclusive to OpenGL ES 3.2?

[taylor85345]

That would be the legacy renderer, and I believe there are already features in Hyprland which don't support the legacy renderer.

[TheSunCat]

Got it! I'll wrap the wobble rendering in ifdefs, then.

[Eclextic]

I'm having a lot of trouble staying on Hyprland due to the mouse lag issue (#3490) and lack of Unreal Engine compatibility (#2127). If these get resolved I'll be able to continue using Hyprland and implement this, but at the moment I have to use GNOME for work.

Unrelated to this issue/Only for GameDevs

As a GameDev I can relate lol
All major game engines still don't have any Wayland support (Godot being the earliest to probably implement it)

I recently have heard about Xwayland rootful mode (run an X11 server inside Wayland, resulting in behavior similar to a Virtual Machine)

I still haven't tried it, but maybe one can open these multi window applications inside of that...

[daUnknownCoder]

any updates on this?

[nonetrix]

Merge conflicts, I would have to imagine this would need to be pretty much redone with everything that has changed since with rewrite as well. I do hope someone adds this eventually though

[vaxerski]

I have no plans of accepting this into core, this is better suited as a plugin

[ThatOneCalculator]

Even though I'm no longer a Hyprland user, in all fairness, wobbly windows isn't really a core feature. I don't see more than a few dozen people legitimately daily driving this (not just enabling it once, saying "oh that's funny" and turning it off) – given the size of Hyprland as a project, keeping what has to be maintained down to a reasonable level is more than valid. Probably a ton of Hyprland users (even the majority!) use blur and animations. Wobbly windows? Not so much.

Edit: for context to this reply, the person previous to vaxry's reply complained about Hyprland's apparent lack of maintaining features in favor of plugins, a stance I don't feel is representative of the project in its current state.

[nonetrix]

Fair enough I might have worded it badly or sounded angry which I am not, I just disagree midly. Personally I have used it a lot on KDE. But this whole project is pretty much just eye candy because it looks cool so I just find it odd, I'm not asking for like every feature like burning windows but wobbly windows seems common enough to add

[ThatOneCalculator]

I think that's definitely a minority userbase preference, KDE and Hyprland have fairly different goals in terms of long-term development, and I think a plugin would be best for this feature. However, don't take my words as representative of @vaxerski 's opinion, especially since I'm no longer involved with the project or even a user anymore.

[TheSunCat]

Yes, this should be moved into a plugin. Perhaps I'll tackle it as I have some time this month, I'll close the MR now as there's no point keeping it open here. If I do make a plugin, I'll post a comment here linking to it for anyone still watching the MR.