Winit: Blur-Behind / Glassy Windows

[Lisoph]

Moved from https://github.com/tomaka/glutin/issues/875
Possibly related to #260

About

Glassy windows are similar to transparent windows. They let the user see through the client area of the window, exposing whatever is behind it. The difference to transparent windows is, that glassy windows have a blur-filter applied to them.

The effect can look something like this or this.

Transparency and blur are mutually exclusive.

Implementation

On Windows, the WinAPI function DwmEnableBlurBehindWindow can be used to create the blur-behind effect (I think). On OS X, NSVisualEffectView is the way to do it.
Personally I don't know how to achieve the effect on X11, but I'm sure it's possible there as well.

Library wise this could be exposed via a new function to the WindowBuilder struct. The question being is: What do we specifiy as the parameters? Since the blur effect can be customized to achieve a specific look and feel, passing a bool is probably not sufficient.

Further

Both of the Windows and OS X functions above only affect the client area of the window, however on both systems the title bar (and on Windows the border) can be made blurred as well.

It would probably be a good idea to implement seperate functions for controlling the client area and title bar / border blur.

Generally, I propose 2 functions similar to this:

fn with_client_blur(self, tbd.) -> WindowBuilder<'a>;
fn with_decoration_blur(self, tbd.) -> WindowBuilder<'a>;

Names and signatures are of course debatable.

Comments and thoughts appreciated!

Appendix 1

I have done some more research and found that on Windows 10, the undocumented function SetWindowCompositionAttribute needs to be used, as DwmEnableBlurBehindWindow is deprecated and does not properly work anymore on Windows 10. This function is is implemented in user32.dll.

[Lisoph]

I updated the second example link, the old one was invalid.

---

I'd be happy to implement this. Any pointers / suggestions to someone new to this codebase?

[francesca64]

I'd be happy to implement this

Great! I haven't really had any substantial PRs to review in weeks now, and it's been getting lonely.

Any pointers / suggestions to someone new to this codebase?

Well, IMO the Windows backend is currently the messiest, so you have that to look forward to. I took a look into SetWindowCompositionAttribute in the past, and it's presently missing from winapi (among some other related things) so you'll have to take care of that by hand (and ideally upstream it after you're sure it works, which also has the benefit of your bindings getting additional review). As long as everything you do is allowed to (and only needs to) happen on the window thread, you shouldn't have to deal with too much complexity in winit's internals, which I think will be the case here.

Adding things like this to the macOS backend is usually pretty easy, at least once you understand the Obj-C concepts and how they're applied through Rust. I guess you'd change WinitView to be a subclass of NSVisualEffectView? And then it should just be a matter of using msg_send! to change the relevant properties.

I'm not optimistic about an API existing for doing this on X11, so you should probably put this functionality behind WindowBuilderExt. Feel free to be creative with the parameters, but if you can't think of an intuitive way to generalize the API for Windows and macOS, then I'd prefer you use different APIs for each that map more transparently to the platform APIs.

If you have any questions (big or small) I'll do my best to answer them.

[OvermindDL1]

As for X11, this wouldn't really be a call to X11 itself, nor would it be preferable considering how much is switching to wayland recently, but rather this could be defined by flags given to Qt based engines like KDE, and GTK based engines have a similar way as well.

[francesca64]

nor would it be preferable considering how much is switching to wayland recently

It's still going to be a long time before the majority of Linux users are on Wayland, and an even longer time before the majority of applications people run will natively use Wayland.

this could be defined by flags given to Qt based engines like KDE, and GTK based engines have a similar way as well

Are you talking about compositors?

[OvermindDL1]

It's still going to be a long time before the majority of Linux users are on Wayland, and an even longer time before the majority of applications people run will natively use Wayland.

True, but there are still such people (I am not one, my GPU is too old...), I've already had to deal with such issues (which is fun considering I can't run wayland at all, KDE has built a headless wayland compositor that I need to install sometime so I can run tests properly, think of it as xvfb but for wayland...).

Are you talking about compositors?

Correct. There aren't any other ways that I've come across that are even remotely standardized that could do something like blur/glass effects behind windows here.

[Lisoph]

@francesca64 thanks for the help!

So I started with the MacOS backend, which was easy enough to get going; simply subclassing WinitView from NSVisualEffectView was enough to get some simple blur. However, now I'm running into a problem when I try to set the NSVisualEffectView properties of WinitView:

if win_attribs.blur {
    use objc::Message;

    // This line is ok, it doesn't panic.
    (*view).verify_message::<(i64,), ()>(sel!(setMaterial:)).unwrap();

    // This line causes a segfault inside [NSView isHiddenOrHasHiddenAncestor],
    // for some reason. 2i64 is the constant for NSVisualEffectView.Material.dark.
    let _: () = msg_send![view, setMaterial: 2i64];
}

I'm calling this right after this line.

---

Nevermind, found the issue (even before submitting this comment): I was supposed to call initWithWinit before setMaterial. I'm submitting this comment anyway to forever remind myself how I wasted 3-4 hours of my life by writing and debugging a test application in swift and comparing the swiftc generated assembler code with rustc's, as well as trying out every combination of objc-message passing and ivar writing possible on this earth. But hey, at least now I know how to use lldb on the command line.

[OvermindDL1]

Nevermind, found the issue (even before submitting this comment): I was supposed to call initWithWinit before setMaterial. I'm submitting this comment anyway to forever remind myself how I wasted 3-4 hours of my life by writing and debugging a test application in swift and comparing the swiftc generated assembler code with rustc's, as well as trying out every combination of objc-message passing and ivar writing possible on this earth. But hey, at least now I know how to use lldb on the command line.

Lol, we've all been there. ^.^

[francesca64]

Yeah, the Obj-C pattern of calling alloc and then init is something that surprised me in the beginning, since it's just so unergonomic (some classes have new, which does both for you in one step, but that pattern is heavily discouraged by Apple). alloc is basically the equivalent of mem::uninitialized, as you've discovered the hard way.

Anyway, good dedication! There's a wide variety of errors you can encounter when interfacing with Obj-C, including some I've never seen outside of doing that, i.e. bus error 10. If you look into the generated Apple bug report, it can sometimes contain more helpful details than you'd get otherwise.

[Lisoph]

A little progress update:

Should I create a pull request now that I have a working MacOS implementation, or should I wait until I'm done with the other backends as well? I'd like to create it now for code review, so that I don't repeat mistakes.

[francesca64]

Looks nice! Feel free to create a PR, and I'll review it.

[filnet]

Looks like this issue could be closed.

[goddessfreya]

@filnet Where was Glassy windows implemented? #568 was closed cause it got stale, and I don't know of any other PRs implementing it.

[filnet]

@goddessfreya I got it wrong. Sorry.

[goddessfreya]

No worries, @filnet.