Decorations needs to support anti aliased rounded corners

Still not fixed...

Was bug 731685 the reason this fix didn't make it into oneiric? Or other clipping bugs?

IMHO, the fact that compiz uses clipping at all is a bug. But that's an architectural debate... :)

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-decorator used this same method to
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-decorator last
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://code.launchpad.net/~smspillaz/compiz-core/compiz-core.fix_slow_movement/+merge/74750

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://bugs.launchpad.net/bugs/827537
>
> Title:
> unity-window-decorator needs to support anti aliased rounded corners
>
> Status in Compiz Core:
> In Progress
>
> Bug description:
> unity-window-decorator needs to support anti alised rounded corners
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/827537/+subscriptions
>

I think you underestimate the value of simplistic graphics code. Very often just letting overdraw happen is much faster than going to the effort of avoiding it.

But I know compiz and the window decoration code are both complex and difficult to simplify, except in baby steps...

e rOn Wed, 14 Dec 2011, Daniel van Vugt wrote:

> I think you underestimate the value of simplistic graphics code. Very
> often just letting overdraw happen is much faster than going to the
> effort of avoiding it.
>

It's a wrapped function call, which means that every single plugin that
has a handler on that window is going to get called, plus we need to
recompute the geometry multiple times etc.

> But I know compiz and the window decoration code are both complex and
> difficult to simplify, except in baby steps...
>
> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/827537
>
> Title:
> unity-window-decorator needs to support anti aliased rounded corners
>
> Status in Compiz Core:
> In Progress
>
> Bug description:
> unity-window-decorator needs to support anti alised rounded corners
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/827537/+subscriptions
>

I was speaking generally, not about the current implementation details. I know compiz has its own peculiarities that sometimes make life more complicated.

I'm also confused as to why unity-window-decorator lacks basic blending features such as this, when I remember Emerald did it so well several years ago...

Could you not take the existing 1-bit alpha, convert it to an 8-bit alpha and then do a blur with radius = 1 pixel? That would create the required anti-aliasing and compiz is surely good at rendering 32-bit RGBA pixels with alpha blending... ?

P.S. I meant only blur the alpha channel. And probably don't use a normal blur. Just search for pixels with alpha == 0, and if they have 2 opaque neighbours (alpha = 255), then change the alpha from 0 to 128.

On Thu, 15 Dec 2011, Daniel van Vugt wrote:

> P.S. I meant only blur the alpha channel. And probably don't use a
> normal blur. Just search for pixels with alpha == 0, and if they have 2
> opaque neighbours (alpha = 255), then change the alpha from 0 to 128.
>

Yes, however this problem is compounded by the fact that
gtk-window-decorator supports decorations with an alpha channel anyways,

> --
> You received this bug notification because you are a member of Compiz
> Maintainers, which is the registrant for Compiz Core.
> https://bugs.launchpad.net/bugs/827537
>
> Title:
> unity-window-decorator needs to support anti aliased rounded corners
>
> Status in Compiz Core:
> In Progress
>
> Bug description:
> unity-window-decorator needs to support anti alised rounded corners
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/compiz-core/+bug/827537/+subscriptions
>

Updated description to say gtk-window-decorator instead of unity-window-decorator because the former has replaced the latter.

Is this going to land in Precise? This has been a visible flaw for the past years, please make us happy and let it not hurt our eyes for the next five years in an LTS.

Does anybody know where the actual upstream bug for this resides, if anywhere?

@Andrea Cimitan - Is there a branch somewhere with the patch???? Or are you still working on it? ~mamemame187

I am not working on it anymore...

ok

Status changed to 'Confirmed' because the bug affects multiple users.

Will this bug be fixed in Ubuntu raring? There aren't antialiased borders until now in Unity/Compiz/Ubuntu.

Valentin, nobody has stepped up to fix this, as it could be guessed by the (non) activity in this report. You're free to, of course.

If anybody is interested in working on this, the relevant commit in an older branch is here:

http://bazaar.launchpad.net/~compiz-team/compiz-core/oneiric.uwd_fixes/revision/2789

Feel free to ping me on irc. The handle is 'smspillaz'.

Fix committed into lp:unity at revision None, scheduled for release in unity, milestone 7.2.0

\o/ thank you!

This bug was fixed in the package unity - 7.1.2+14.04.20140214.1-0ubuntu1

---------------
unity (7.1.2+14.04.20140214.1-0ubuntu1) trusty; urgency=low

  [ Sebastien Bacher ]
  * use unity-control-center by default.
  * lists keybinding in unity-control-center. (LP: #1271710)

  [ Brandon Schaefer ]
  * Bump to new libnux from this branch:
    https://code.launchpad.net/~brandontschaefer/nux/xim-preedit-
    support.
  * Adds Super+L to lock the screen, while keeping the older shortcut
    around in g-s-d (Ctrl+Alt+L). (LP: #830709)
  * Do not open the dash/hud on a monitor with a top most window that is
    fullscreen. (LP: #1267210)
  * Implement an EMConveter. This way with default settings such that
    DPI = 96.0f, and font_size = system font size. We can get the
    correct EM value for any pixel size. Once we have the correct EM
    value for any pixel size, the DPI value can be adjusted to the
    current logical one. From here, you can now get the correct pixel
    size based from of the EM value for the logical DPI of the screen.
  * Refactor EMConverter API. Now all thats needed is int
    ConvertPixels(int pixel); This will calculate the correct pixel size
    based on the DPI and font size.
  * Testing that the ibus anthy tests could possibly be causing strange
    issues on the nvidia machine. So skipping them to test if tihs is
    the source of the error.
  * Add Pt to Px function to em converter.
  * Move EMConverter over to unity settings.
  * Add multi monitor support for EMConverter in unity settings. Now you
    can grab a specific converter per monitor.
  * Simple RawPixel class. It adds 2 define literals, ex: 10_em,
    10.0_em. From there it turns them into raw pixels. RawPixels have CP
    (CovertPixel) function which takes in an EMConverter that allows you
    to use a converter specific to a monitor to convert the raw pixel to
    the correct value.

  [ Marco Trevisan (Treviño) ]
  * Don't re-present all of our windows on every frame. Only do that if
    damage intersects it. Use the new APIs exposed by compiz and nux to
    intelligently determine which windows need to be presented per-frame
    and only register damage for those windows. This fixes two things:
    1. BaseWindows being redrawn from scratch every time damage was
    registered over them. That was incorrect and should only be done in
    the case of background blurs. 2. BaseWindows being drawn to the
    screen on every frame, regardless of whether or not they needed to
    be. Now they will only be drawn if some damage intersects beneath
    them. Note that unity will expand the damage region to accomadate
    the base window since nux does not support geometry clipping. So if
    there is a partial intersection of the launcher for example, the
    area of the screen which contains the launcher will be re-painted
    (but the launcher itself won't be redrawn, just its texture) (LP:
    #1080947). (LP: #1080947)
  * Convert compiz regions / rects to nux::Geometry's and back easily.
  * UnityScreen: remove the useless and expensive gl{Push,Pop}Attrib
    calls For some reasons this code was copied by the opengl plugin as
    a workaround to fix the s...

Fix Released in Unity Unity 7.2.0.