Turns out our blurring function isn't very nice, it has a lot
of energy past the blur radius, so clipping at exactly the
blur radius causes ugly gradient stops. This just adds 4
extra pixels of slop, which makes this better in most cases.
We split up the rendering of blurred shadows into 9 parts, the
corners, the sides and the rest. This lets us only blur the "blurry"
part, and it lets us completely skip blurry parts that are fully
clipped.
As per css3-background 7.2. Drop Shadows: the ‘box-shadow’ property:
An outer box-shadow casts a shadow as if the border-box of the element
were opaque. The shadow is drawn outside the border edge only: it
is clipped inside the border-box of the element.
Also verified vs firefox behaviour.
Change the visibility handling to be the same way we do it in
GLib now. We pass -fvisibility=hidden to gcc and decorate public
functions with __attribute__((visibility("default"))).
This commit just does this for GDK, GTK+ will follow later.
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
Make all GDK_DEPRECATED and GDK_AVAILABLE macros use a
new _GDK_EXTERN macro. _GDK_EXTERN defaults to just 'extern'
but a subsequent commit will add visibility handling to it
while building GTK+.
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
Add a macro to declare that a particular symbol is available in all
versions of GTK+.
All newly-added symbols should have proper version macros (like
GDK_AVAILABLE_IN_3_4).
This avoids an evil trap when doing MAX (..., ... - 2 * border_width)
and the expression on the right gets promoted to unsigned, instead
of going negative as you would expect.
https://bugzilla.gnome.org/show_bug.cgi?id=699633
These tests check that a toplevel window ends up with the expected
size after setting default sizes or resizing. It currently passes
on X, but fails with client-side decorations under X and Wayland.
When we call _gdk_wayland_display_load_cursor_theme during
the initial opening of the first display, gdk_setting_get does
not work yet, since it relies on the default display/screen
being set, which only happens after open returns.
Instead, just use the screen of this display.
It's not necessary anymore because gdk_display_manager_get() always
succeeds and the value is independant of when it was called as it's no
longer backend specific.
