Comment 3 for bug 827537
Revision history for this message
| Sam Spilsbury (smspillaz) wrote Re: [Bug 827537] Re: unity-window-decorator needs to support anti aliased rounded corners | #3 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
9199653
demo site
(Get the code!)
On Wed, 14 Dec 2011, Daniel van Vugt wrote:
> Was bug 731685 the reason this fix didn't make it into oneiric? Or other
> clipping bugs?
>
No, this is different.
Metacity specifies a clipping region for the actual window decoration
pixmap which is rendered outside of compiz. This is so that you can have
1-bit alpha semi-rounded corners in the window decorations there when
running without compositing. gtk-window-
clip the rectangular decoration drawing into one that had the same 1-bit
semi-rounded corners.
The fix here was to use those same regions in order to create a nicer
rounded clipping path in cairo. However, you still need to have "hard"
corners in order to do shadows correctly since the shadows are done by
xoring the decorations drawing on top of a black box and then blurring
that black box. With rounded corners, you'll end up with offset shadows
because of the smooth gradient between the corner and the alpha region of
the drawing.
A nice arhcitectural workaround can be employed here because the shadow is
only generated once per decoration "type" (eg dialogs, toolbox windows,
normal windows) and then composited underneath the actual decoration.
However, in order to do this, you still need a decoration, and so
decorations need to be associated with either windows or standalone
pixmaps (eg a "default" decoration to be displayed while the real one is
being generated). It wasn't really possible to make that distinction
without the architectural re-haul that I did of gtk-window-
cycle that didn't get merged in for various reasons and probably won't get
merged in this cycle because I don't have time to write a testsuite and
complete the testharness for it.
> IMHO, the fact that compiz uses clipping at all is a bug. But that's an
> architectural debate... :)
>
The reason why I chose to clip shadows directly using paint regions rather
than painting shadows underneath windows that were meant to clip them was
because it means that you effectively need to paint a window multiple
times at several different points in the paint stack. Clipping has its
problems, but I do have a branch here:
https:/
Which fixes a lot of the overhead to do with clipping by using a region
cache and only clipping where necessary.
I think the correct solution to this is to decouple texture painting from
window painting at all and to make every texture have a clip and damage
region, but that's a much larger architectural change which I won't have
time to do this cycle.
> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https:/
>
> Title:
> unity-window-
>
> Status in Compiz Core:
> In Progress
>
> Bug description:
> unity-window-
>
> To manage notifications about this bug go to:
> https:/
>