Summary: Before, shadow size doubled with each new size until Very Large and the smaller shadows were more transparent than the larger shadows. Now shadow size increases linearly and smaller shadows start with more opacity so that they don't become nearly invisible. The new shadows should look better on cheap displays.
Test Plan:
Before
======
Small: {F6622411}
{F6632347}
Medium: {F6622412}
{F6632346}
Large: {F6622413}
{F6632344}
Very Large: {F6622415}
{F6632341}
After
=====
Small: {F6624603}
{F6632334}
Medium: {F6624606}
{F6632335}
Large: {F6624608}
{F6632336}
Very Large: {F6624612}
{F6632337}
Reviewers: #vdg, #breeze, ngraham, rooty
Reviewed By: #vdg, #breeze, ngraham, rooty
Subscribers: filipf, ngraham, zzag, rooty, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D19148
Summary:
Creation of shadows (especially for "Large" and "Very large" sizes) is
a computation expensive task because we have to blur alpha channel of a
shadow texture (which then will be tinted with desired shadow color).
Currently, we use the following approach:
* for blur radius less than 64, use naive 2-pass algorithm;
* for blur radius greater than or equal to 64, use FFT.
Even though the FFT approach is doing its the best, it still takes
impresive amount of time to blur the alpha channel.
What makes things even worse is that while we're blurring the alpha
channel, we're blocking the main thread of KWin (decorations are not
rendered in their own thread). This can result in frame drops (2 or 3
frames, something like that).
So, the only viable alternative is to use an approximation of the Gaussian
blur. As such an approximation, I picked the box blur because it's quite
simple, it's fast, and it takes small amount of iterations to have something
similar to the true Gaussian blur.
In general, there are no big differences between true gaussian shadows
and approximated shadows:
Before:
{F6312610}
After:
{F6312613}
Before:
{F6280935}
After:
{F6312608}
As a win, it takes much less time to generate decoration shadows.
Reviewers: #kwin, #plasma, #breeze, #vdg, ngraham
Reviewed By: #breeze, #vdg, ngraham
Subscribers: cfeck, ngraham, abetts, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D15514
Summary:
5.12 release introduced new decoration shadows. These new shadows are
bigger, centered, and they try to solve a problem related to depth.
Yet, there are still some problems:
* new(5.12) shadows are hard.
* lighting model is broken. Because 5.12 shadows have been centered and
made bigger, they should be casted from north.
This change refines how decoration shadows look:
* shadows are casted from north(shadow under window is bigger and darker,
side shadows are smaller, etc);
* shadows are made up of several separate shadows(one for overall shape,
another for contrast). The separate shadows are produced by using box
shadow helper(something similar to CSS box-shadow property, except there are
no inset and spread properties);
* shadow sizes(e.g. Small, Medium, and so on) haven't changed.
Because GPUs can't be used for blurring images(in our case), the box shadow
helper is using CPU to blur images. More precisely, when blur radius is < 64,
images are blurred with "separable convolutions", otherwise, images are blurred
with a two-dimensional Fourier Transform.
{F5754389, layout=center, size=full}
Desktop experience with the refined shadows
{F5754390, layout=center, size=full}
Depends on D11198
Reviewers: #breeze, #vdg, hpereiradacosta
Reviewed By: hpereiradacosta
Subscribers: abetts, fabianr, hpereiradacosta, ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D11069
Summary:
This implements the menu shadow changes proposed in D9549; now we use a combobox with five options: None, Small, Medium, Large, and Very Large.
Large is the new default value (64px window shadows, 16px menu/tooltip shadows), and implements what we recently changed the default to. Small is the old default value (16px window shadows, 12px menu/tooltip shadows) for people who preferred that.
I had a massive amount of help from @hpereiradacosta; in fact, probably 75% of these changes are his. It's a shame multiple authorship isn't possible. Hugo, feel free to commandeer the revision if you'd like the credit!
Test Plan:
Tested in KDE Neon. New smaller menu shadows for the default window shadow size:
{F5615780}
New shadow chooser UI, with different options:
None (1px border for windows, menus, and tooltips):
{F5623069}
Small (16px window shadows, 12px menu/tooltip shadows); replicates the the old default value:
{F5623071}
Medium (32px window shadows, 14px menu/tooltip shadows):
{F5623072}
Large (64px window shadows, 16px menu/tooltip shadows); the new default:
{F5623073}
Very Large (96px window shadows, 24px menu/tooltip shadows):
{F5623074}
Upgrade story: since this changes the way shadow size is stored in the breezerc file, users who previously had manually set their shadow size to some arbitrary pixel value will now get the new default Large 64 px shadow size.
Reviewers: #vdg, #breeze, hpereiradacosta, abetts, rkflx
Reviewed By: #vdg, hpereiradacosta, abetts, rkflx
Subscribers: rkflx, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9627
Summary:
FEATURE: 388256
#VDG has decided that shadows should be horizontally centered and bigger. This patch implements those changes in the following way:
- Window and menu shadows are now horizontally centered
- Shadow size increased to the maximum value
- Shadow color changed from pure black to a slightly lighter Breeze standard color: Shade Black
Test Plan:
Tested in KDE Neon. Before:
{F5587393}
After:
{F5587390}
Reviewers: abetts, hpereiradacosta, #vdg, #breeze, alake
Reviewed By: abetts, hpereiradacosta, #vdg
Subscribers: rkflx, zzag, cfeck, januz, rpelorosso, apol, mvourlakos, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D9549
Summary:
Adds a new settings on Breeze theme which allows the user to turn off the title bar separator drawn
{F5437291}
{F5437290}
Rationale behind this patch:
From what I understand, the separator is seen as a design choice so I won't argue over it, not to mention something like this is entirely subjective.
However, I personally dislike the separator, especially on darker windows. The only way to get rid of it is to either make a custom color scheme for each application so the colors match exactly or run a patched version of breeze (which is what I do). Before using my Breeze patched version I searched on the net on how to remove it, which led me to several threads with other users wanting to toggle it off which is why I make this patch public.
Below are screenshots where the separator is especially noticeable and in my non-design-expert opinion kind of distracting. I think it's a positive addition. Looking forward to your opinions on the matter.
{F5437332}
{F5437331}
{F5437330}
{F5437329}
Test Plan:
1. Use default breeze theme
2. Check the enable/disable the new setting
Reviewers: #breeze, #vdg, ngraham, hpereiradacosta
Reviewed By: ngraham
Subscribers: andreaska, abetts, jensreuterberg, broulik, rpelorosso, #breeze, ngraham, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D8362
Jacopo De Simoi
Vlad Zahorodnii
Vlad Zahorodnii
Kai Uwe Broulik
Hugo Pereira Da Costa
Noah Davis
Nathaniel Graham
Emirald Mateli
Hugo Pereira Da Costa