Update gnomestripe arrow panel (doorhanger) styling for translucent windows

RESOLVED FIXED in mozilla18



7 years ago
7 years ago


(Reporter: karlt, Assigned: karlt)


Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)



(10 attachments)



7 years ago
Bug 408284 is close to adding support for 0-255 alpha translucent windows on X11 systems with compositing window managers.

This will mean that alpha and color levels are treated differently and so the theming of arrow panels will need updating.

When ARGB visuals are used, it becomes clear that there are no borders around the arrows.  See attachment.

Comment 1

7 years ago
This is based on the winstripe theme, but the width of the border is extended to roughly 1 pixel for consistency with the 1 pixel border around the rest of the panel.  Winstripe uses a border width of 1/sqrt(2) around the arrow.

The border is intentionally centered on the 0.5,10 10,0.5 like the winstripe theme instead of on 0.7,10 10,0.7, for two reasons:

1) It theoretically aligns with the 0.5 center of the border around the rest of the panel.

2) It avoids problems when pixels are exactly half-filled.  With a 0.5 alpha threshold for shaped windows, rounding errors can mean that pixels on one side of the arrow is considered transparent, while their reflections on the other are opaque.
Attachment #666446 - Flags: review?(dao)

Comment 2

7 years ago

Comment 3

7 years ago
Not all systems with have compositing window managers.
On those systems, we'll still need to shape windows.
This is essentially a single bit 0/1 alpha channel.

I assume this is why the existing theming does not use borders.

Currently alpha > 0, even 1/255, is considered opaque, but colors are not unpremultiplied, and so pixels with low alpha end up black.
We can improve this.

Comment 4

7 years ago
This changes the threshold for considering a pixel to be transparent.
A threshold of 0.5 is rounding alpha to the nearer of 0 or 1.
Attachment #666451 - Flags: review?(roc)

Comment 5

7 years ago
We could do better by unpremultiplying the colors, which is similar to CAIRO_OPERATOR_SATURATE but we don't need to consider the destination surface.
However, this isn't too bad.

Comment 6

7 years ago
This is the current rendering, before any patches here, for reference.

We're getting a bit lucky with this and attachment 666454 [details] because the border in this theme happens to be darker than the panel background.  Current behavior would be completely wrong with light-border themes.  Attachment 666451 [details] [diff] should improve things a bit there, but not fully address the issue.
How do things look if you copy the winstripe styling one-to-one?

Comment 8

7 years ago
Posted image ARGB winstripe arrow
Exactly how this looks will depend a bit on the monitor's gamma response.
The gamma curve should make the half-filled pixels look a little darker and so would help with dark borders, but make light borders look thinner.

To me, the arrow border still looks a little light compared to the rest of the panel.

Comment 9

7 years ago
Same as attachment 666447 [details], but more context to compare the rest of the panel border.  The gamma curve may overdo this a touch, but to me it looks more consistent.

The difference is not major, but ...

Comment 10

7 years ago
... the exactly half filled pixels from the diagonals through pixel corners are the worst case for shaped windows where the window manager is not compositing.
A half filled pixel is not exactly representable in the 0-255 scale, so sometimes we get 127 and sometimes 128.
127 is considered transparent and so the left hand side of the arrow looks too thin, and 128 is considered opaque and so the right hand side is too heavy.
Attachment #666446 - Flags: review?(dao) → review+
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
You need to log in before you can comment on or make changes to this bug.