Decorations needs to support anti aliased rounded corners

Reported by Sam Spilsbury on 2011-08-16
238
This bug affects 71 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Medium
Unassigned
Compiz
Low
Unassigned
Compiz Core
Low
Unassigned
Unity
Medium
Marco Trevisan (Treviño)
compiz (Ubuntu)
Low
Unassigned
unity (Ubuntu)
Undecided
Unassigned

Bug Description

gtk-window-decorator needs to support anti alised rounded corners

Use RGBA (see http://gnome-look.org/content/show.php?content=100556 ) or is it possible with GTK3?

Tags: euv Edit Tag help

Related branches

lp:~3v1n0/unity/unity-decorations
Merged into lp:unity at revision 3632
Christopher Townsend: Approve on 2014-01-28
Brandon Schaefer: Approve on 2014-01-27
PS Jenkins bot: Approve (continuous-integration) on 2014-01-23
Changed in compiz-core:
milestone: none → 0.9.5.90
assignee: nobody → Sam Spilsbury (smspillaz)
importance: Undecided → Low
status: New → Fix Committed

Still not fixed...

Changed in compiz-core:
status: Fix Committed → In Progress
summary: - unity-window-decorator needs to support rounded corners
+ unity-window-decorator needs to support anti aliased rounded corners
description: updated
Changed in compiz-core:
milestone: 0.9.5.90 → none
Daniel van Vugt (vanvugt) wrote :

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...

Daniel van Vugt (vanvugt) wrote :

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... ?

Daniel van Vugt (vanvugt) 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.

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.

summary: - unity-window-decorator needs to support anti aliased rounded corners
+ gtk-window-decorator needs to support anti aliased rounded corners
description: updated
Ingo Gerth (igerth) wrote :

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.

Jay S (topdownjimmy) wrote :

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

Andrea Cimitan (cimi) on 2012-05-02
tags: added: euv
Andrea Cimitan (cimi) on 2012-05-02
Changed in ayatana-design:
status: New → Fix Committed
assignee: nobody → Andrea Cimitan (cimi)
Brendan William (mamemame187) wrote :

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

Andrea Cimitan (cimi) wrote :

I am not working on it anymore...

Brendan William (mamemame187) wrote :

ok

Changed in compiz-core:
status: In Progress → Triaged
Changed in compiz:
assignee: nobody → Sam Spilsbury (smspillaz)
importance: Undecided → Low
status: New → Triaged
Launchpad Janitor (janitor) wrote :

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

Changed in compiz (Ubuntu):
status: New → Confirmed
Valentin (valentin-stn) wrote :

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

Adolfo Jayme (fitoschido) wrote :

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.

Changed in compiz (Ubuntu):
importance: Undecided → Low
Sam Spilsbury (smspillaz) wrote :

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'.

Changed in compiz:
assignee: Sam Spilsbury (smspillaz) → nobody
Changed in compiz-core:
assignee: Sam Spilsbury (smspillaz) → nobody
Changed in compiz:
milestone: none → 0.9.10.0
MC Return (mc-return) on 2013-07-24
Changed in compiz:
milestone: 0.9.10.0 → 0.9.11.0
Andrea Cimitan (cimi) on 2013-09-20
Changed in ayatana-design:
assignee: Andrea Cimitan (cimi) → nobody
John Lea (johnlea) on 2013-10-03
description: updated
Changed in ayatana-design:
importance: Undecided → Medium
summary: - gtk-window-decorator needs to support anti aliased rounded corners
+ Decorations needs to support anti aliased rounded corners
Changed in unity:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
milestone: none → 7.2.1
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in unity:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (18.5 KiB)

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...

Changed in unity (Ubuntu):
status: New → Fix Released
Changed in unity:
milestone: 7.2.1 → 7.2.0
Stephen M. Webb (bregma) wrote :

Fix Released in Unity Unity 7.2.0.

Changed in unity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints