Hello everyone, hope you all are doing great ! Recently I rewrote my entire system from scratch focusing on its performance, and it's going great ! I am currently working on the compositing window manager called "deodhai", I have windows, and I want to add drop shadows behind active window. So, the question is, if I want to have a drop shadow, should I blit the entire window to another buffer that have size little bigger than window size? Or should I provide the client application with little bigger sized buffer than requested so that it can draw it's drop shadow? Is there any other approach? How to implement drop shadow in compositor?
Thank you,
Manas Kamal
https://github.com/manaskamal/XenevaOS
Window drop shadow in compositor
Re: Window drop shadow in compositor
Let's take a look at some examples:
xcompmgr is a very simple X11 compositor that supports two kinds of shadow rendering:
- "Server-side shadows" are unblurred shadows: The alpha of the window is taken as a mask and a partially-transparent black fill is drawn at a user-configurable X and Y offset, and then the window is drawn on top of it. No extra texture space is used for this approach, but the results are not always visually-pleasing.
- "Client-side shadows" are blurred shadows: The extent box of a non-transparent window is used to create a larger (single-channel) texture with a precomputed blurred box, and this is then used as the mask to blit an opaque black fill (the precomputed blurred box is already partially transparent). This requires extra texture space, but not as much as a normal window as it is only a single channel.
Compiz took a wildly different approach. In Compiz, if you wanted window decorations you used a supported window decorator, and a plugin would communicate settings for shadows to the decorator. The decorator would then render shadows the same way it does the borders. The downside to this approach is only decorated windows have shadows. It also requires some cooperation between components, such that the compositor doesn't consider shadows part of the bounds of the window decorations.
The downside to all of these approaches is that they are all optically wrong: with all three of these, shadows compound in a way they shouldn't. This can be mitigated slightly by having non-focused windows have less pronounced shadows, or even no shadows: if only one window is drawn with shadows, it can be thought of as a single raised object and will then generally be correct.
If you had the benefit of a full modern graphics stack, you could do better: You could combine shaders with the approach xcompmgr's server-side shadows take to have alpha-based blurred shadows with no extra buffers (you can try to do this in software, but it may not be worth the performance costs). You could also render shadows like a game engine would by calculating shadow maps in a 3D space.
xcompmgr is a very simple X11 compositor that supports two kinds of shadow rendering:
- "Server-side shadows" are unblurred shadows: The alpha of the window is taken as a mask and a partially-transparent black fill is drawn at a user-configurable X and Y offset, and then the window is drawn on top of it. No extra texture space is used for this approach, but the results are not always visually-pleasing.
- "Client-side shadows" are blurred shadows: The extent box of a non-transparent window is used to create a larger (single-channel) texture with a precomputed blurred box, and this is then used as the mask to blit an opaque black fill (the precomputed blurred box is already partially transparent). This requires extra texture space, but not as much as a normal window as it is only a single channel.
Compiz took a wildly different approach. In Compiz, if you wanted window decorations you used a supported window decorator, and a plugin would communicate settings for shadows to the decorator. The decorator would then render shadows the same way it does the borders. The downside to this approach is only decorated windows have shadows. It also requires some cooperation between components, such that the compositor doesn't consider shadows part of the bounds of the window decorations.
The downside to all of these approaches is that they are all optically wrong: with all three of these, shadows compound in a way they shouldn't. This can be mitigated slightly by having non-focused windows have less pronounced shadows, or even no shadows: if only one window is drawn with shadows, it can be thought of as a single raised object and will then generally be correct.
If you had the benefit of a full modern graphics stack, you could do better: You could combine shaders with the approach xcompmgr's server-side shadows take to have alpha-based blurred shadows with no extra buffers (you can try to do this in software, but it may not be worth the performance costs). You could also render shadows like a game engine would by calculating shadow maps in a 3D space.
Re: Window drop shadow in compositor
Just one quick glance at your OS, it is great but I think before continuing anything you should've completed the multiprocessor scheduler as you will then need to adapt your functions to be synchronized between cpus, and that may become a huge problem since you may have a large codebase.
Re: Window drop shadow in compositor
Thank you so much klange and devc1 for your reply...
And yes, I am also planning to work on multiprocessor scheduler, currently I started to work on the terminal part of the system. Once it is completed I'll definitely start the multiprocessor scheduler.
Thank you,
Manas Kamal
And yes, I am also planning to work on multiprocessor scheduler, currently I started to work on the terminal part of the system. Once it is completed I'll definitely start the multiprocessor scheduler.
Thank you,
Manas Kamal
Re: Window drop shadow in compositor
You're welcome anytime 