After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734668 - Properly handle alpha in fg color when rendering symbolic icons
Properly handle alpha in fg color when rendering symbolic icons
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: .General
3.13.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-08-12 13:51 UTC by Alexander Larsson
Modified: 2018-05-02 16:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Change way alpha is used when recoloring symbolics (4.41 KB, patch)
2014-08-12 13:51 UTC, Alexander Larsson
committed Details | Review
Fix symbolic-icon-translucent-color reftest (2.01 KB, patch)
2014-08-12 13:51 UTC, Alexander Larsson
committed Details | Review

Description Alexander Larsson 2014-08-12 13:51:10 UTC
You don't really want to just re-render the icon with a color with alpha, but rather you want to apply the alpha as a group. That way the alpha applies to other colors too, handles overlapped draws of the fg color, and allows the prerendered pngs symbolics to work.
Comment 1 Alexander Larsson 2014-08-12 13:51:37 UTC
Created attachment 283201 [details] [review]
Change way alpha is used when recoloring symbolics

If the foreground color has an alpha != 1 we used to just pass that into
the svg. This is useful to e.g. render an insensitive icon. However,
that is not an ideal model for symbolics. For instance, if the icon uses
overlapping areas when drawing, expecting these to be opaque then the
transparent color will result in a different alpha value for the overlapping
area. Also, non-foreground symbolic colors are still rendered opaque, and
the recoloring of pngs can't handle transparent colors.

So, instead we extract any alpha from the foreground, render using the
opaque colors and then apply the foreground alpha to the entire result.
This means we get an even transparency, even for other colors, and we
can apply alpha for the pngs too.
Comment 2 Alexander Larsson 2014-08-12 13:51:41 UTC
Created attachment 283202 [details] [review]
Fix symbolic-icon-translucent-color reftest

When using the pre-rendered png symbolics it seems that we're off a
tiny bit in a few of the pixels on the antialiased borders of a
stroke. To fix this we switch the icon to media-playback-stop-symbolic
which has no such antialiased borders.

I don't quite understand why the pixels are off, this needs more
research.
Comment 3 Alexander Larsson 2014-08-12 13:56:39 UTC
Attachment 283201 [details] pushed as afeb500 - Change way alpha is used when recoloring symbolics
Attachment 283202 [details] pushed as f3b5626 - Fix symbolic-icon-translucent-color reftest
Comment 4 Lapo Calamandrei 2017-06-07 16:04:25 UTC
This isn't necesary anymore, the "opacity" css prop seems to work all over the place, and Adwaita (at least) avoids using trasparent colors for symbolics. The lack of alpha channel hurts the use of -gtk-recolor(), for example, in other contests and makes the css code not doing what it's supposed to do.
Please revert or at least document this behaviour in the css docs.
Comment 5 GNOME Infrastructure Team 2018-05-02 16:12:08 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/502.