GNOME Bugzilla – Bug 731365
Problem with "border-color" property on the popover's arrow
Last modified: 2018-04-15 00:29:25 UTC
Created attachment 278093 [details] Screenshot of the issue Please see attached screenshot. The border color here is set to “alpha (#000, 0.3)” You can see that the arrow's border is a different color because the popover background is being drawn behind it instead of being clipped like the other sides of the widget.
It appears GtkPopover is using 'cairo_stroke' for the arrow's border (L889, gtkpopover.c), and this doesn't respect the background-clip property. The rectangle's borders are rendered using 'gtk_render_frame_gap', and it properly applies background-clip.
It seems to be fixed in GTK+ 3.18, at least with the Adwaita theme. Can you still reproduce the bug?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
It's actually fixed, try this CSS snippet in the GTK+ inspector: GtkPopover { border-color: red; } So it's no longer the background-clip property, it's border-color.
Hey Sébastien, The issue is not fixed as of Gtk 3.18. As noted in the original report, you can reproduce the issue by using a transparent (not solid) border color.
Works fine here, try: GtkPopover { border-color: alpha (#ff0000, 0.3); }
Created attachment 316811 [details] Screenshot of the issue on Gtk 3.18 Please see the screenshot taken today (December 5th) with Gtk 3.18.5 This popover has a semi-transparent border: alpha (#000, 0.3) You can see that along the edges of the popover you get very sharp, crisp borders over both light and dark backgrounds. However, the arrow appears blurry. This is because the border is being drawn on top of the arrow instead of around it. It's not being "clipped" as the other portions of the popover background are.
FWIW, drawing the border over the background is how CSS gets drawn, e.g. https://jsfiddle.net/rapLz4vx/ and 4d075cf202ae428652 made GtkPopover do exactly that for the rest of it. That looks like http://i.imgur.com/hSTd2hk.png currently. What exactly the issue is here is hard to diagnose, i.e. the color is fine if I just use GDK_SCALE=4 and look at popover borders. Isn't the issue here more that the box-shadow does not get applied to the tail at all *and* that's just a slim vertical line that gets pixelated?
@Timm, that is why Victor's comment specifically mentions the background-clip property: https://bugzilla.gnome.org/show_bug.cgi?id=731365#c1 Notice how it changes when you add "background-clip: padding-box;" If box-shadow applied to the popover tail, that would be a good solution as well. It would fit better with how these borders are applied in other widgets, I think.
I can make the tail border see-through here: http://i.imgur.com/yqH4yS7.png (not that it's particularly pretty, but at least they don't seem to overlap) and as far as I can see, gtk_popover_get_gap_coords cares about the border-width a lot.
Unclear whats missing here. A patch would help
Created attachment 324869 [details] Screenshot of the fixed rendering Hello. Here is my solution to the problem: https://github.com/Vort/gtk/commit/50a1198231d0e20487cab21e49b0165e6e6ddc75 Please check it. This is my first patch to GTK project, so there can be newbie mistakes. One thing that I want to note specially: there is no call to gtk_render_frame_gap in this version.
I have found that my solution works bad in some cases. I will look if it is possible to modify its algorithm.
Created attachment 325320 [details] popover_fix_v2 rendering with default clipping Here is the second version of my fix: https://github.com/Vort/gtk/commit/1c6457d4f7eb2a1010b6bd456890f8ef08350f87 It uses cairo groups and different composition modes to eliminate the seams between box and arrow objects. This fix allows to use not only transparent border, but also transparent background (see attachment). However, its work is not perfect in case of complex backgrounds. Please take a look at this patch.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new