https://bugs.kde.org/show_bug.cgi?id=452373
--- Comment #4 from doncb...@gmail.com --- Darn, I could have sworn there was a grace period where it was perfect, but maybe I just hadn't noticed yet. (In reply to Silas Della Contrada from comment #3) > I've investigated this, and it's directly caused by the corner mask fix. The > corners were fixed by adjusting the blurred region by -1 pixel on each side > and adding a border with the same thickness. If I remove this patch, the > thin borders are gone, but the corners extend out. I don't really understand what you mean by "adding a border with the same thickness". Are you saying KDE shipped with changes to the blur mask such that it would be impossible for the blur to meet with the corners of the dialog? i.e. there would be a border regardless of what was specified in the svg? I'm not good with the code specifics, but to put into words what I felt making my theme's mask meet with corners cleanly (given that the mask is not anti-aliased), I felt that the way the mask was calculated just needed to be a little less aggressive with determining if a pixel was blurred or not. I remember previous themes' svgs always reduced the mask by about .5 pixels to combat this. Then, for straight edges (e.g. top, left, right, bottom) the .5 would round up to 1 and they would meet cleanly with the edges. For curved edges, less pixels would be included in the mask (because rounded down?). If the above can somehow be put into code, I think we could have a pretty decent aliased mask. The criteria for rounding up a pixel in the mask just needs to be less lenient. Perhaps .6 would be enough coverage to be considered a fully blurred pixel. However, I know firsthand this is a complicated procedure, and needs to take into account different types of rounded corners at different scalings. Obviously, I have no clue if the code lines up with what I said, but it's just a thought. -- You are receiving this mail because: You are watching all bug changes.
