If we aren't going to fill the content area of the node with a solid
background color, then we need to clear it of any artifacts left over
from drawing the border.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
This reverts commit b4ec342d06.
The alpha > 0 checks should actually be alpha < 255 for the commit to
make sense as designed. The design isn't right either, though,
since we need to preserve the translucency in translucent gradients,
not block it with a solid color fill.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
If a background gradient isn't fully opaque, then we need to first
fill in the background color so the border color doesn't leak into
the interior.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
We need to be careful to ignore any preexisting color information
in the interior of the node when filling it with the background color,
since the border color may have leaked into the interior and the
background color may be translucent.
https://bugzilla.gnome.org/show_bug.cgi?id=640465
The material of prerendered backgrounds is now painted in the
rectangle determined by st_theme_node_get_paint_box(). As the
ClutterActorBox returned from that function includes the space
needed to draw the box shadow, the background ends up occluding
the shadow.
As the box shadow is not part of the background, factor out a new
helper function which excludes the box shadow, and use it to
prerender and place the background material.
https://bugzilla.gnome.org/show_bug.cgi?id=641522
Previously, trying to use a background image and border on
the same node resulted in the background drawing over the border.
This commit adds support for background images to
st_theme_node_render_background_with_border
and changes the code to call that function when appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
A lot of the border drawing logic in st_theme_node_render_gradient is
applicable to other non-solid background types than gradients.
This commit refactors that code so that support for other non-solid
background types can be more easily integrated later.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
When drawing the background image shadow, we need to clip it
to the node's background color, gradient, or borders if present.
If the background color is transparent, and there aren't any
borders, then we don't clip the shadow since there is nothing
to confine it.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
The border_texture (and border_material) variable is being
overloaded for two purposes: it's used as a source
to 9-slice the border from, and it's used as place to prerender
the background and border together for gradients.
While we only do one or the other for any given node, the two cases
are distinct, and should use distinct variables for readability.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
Currently, "-st-shadow" can mean one of three very
different things:
1) shadow based on alpha of the background image
2) shadow the "border box" of the node
3) shadow applied to the content of a StIcon
It isn't well defined which of the above 3 cases
-st-shadow will mean for any given node, however.
This commit splits the property into three
different properties, "box-shadow",
"-st-background-image-shadow", and "icon-shadow"
to make it all very explicit.
https://bugzilla.gnome.org/show_bug.cgi?id=636976
While non-uniform border widths were parsed correctly, an arbitrary
side's width was picked when painting, so that each border ended up
with the same width and the widths specified in CSS were ignored.
At least for sides between non-rounded corners, using a different
border width can be reasonable, for instance at screen edges.
Different border widths around rounded corners are kind of crack,
but then it would be lame not to support it ...
https://bugzilla.gnome.org/show_bug.cgi?id=607500
For gradient backgrounds, borders were implemented by filling the
background shape with the border color first, and then scaling down
the path to draw the background.
The result is not correct[0], which is especially visible if the border
width is greater than the border radius - so instead of scaling down
the original path, use a separate path for the background.
The result is consistent with the borders we draw for non-gradient
backgrounds, and much closer to the correct standard behavior.
[0] http://www.w3.org/TR/css3-background/#the-border-radiushttps://bugzilla.gnome.org/show_bug.cgi?id=607500
We were always drawing the border and background of each
StThemeNode, even if they were transparent. The simple
optimization of checking the alpha provides a significant
performance boost (in a quick test, it increased the
overviewFpsSubsequent metric in the core performance test
from 28fps to 35fps).
https://bugzilla.gnome.org/show_bug.cgi?id=634752
* Make sure all source files have a LGPL copyright header, and standardize
non-standard variations of the header to a common form.
* Check and update all copyright notices.
* Remove 'Written By:' lines. They are universally incomplete and
typically indicate only who started a particular file.
https://bugzilla.gnome.org/show_bug.cgi?id=634550
In d66e7dd49 I got confused between border_texture and
background_texture. The background_texture was being created as normal
but in the one place that it gets drawn I accidentally made it use the
border_material instead. This patch makes it create a
background_material similar to the border_material and uses it to
paint.
A few places in st-theme-node-drawing create one-shot material, paint
with it and then free it. This is suboptimal with current Cogl because
it will end up compiling an ARBfp program just for that single paint
and then it will throw it away when the material is destroyed.
There is a new function in st-private.c called
_st_create_texture_material. This creates a simple material for a
texture based on a common parent material that points to a dummy
texture. Any materials created with this function are likely to be
able to share the same program unless the material is further modified
to contain a different number of layers. It would be possible to use
cogl_set_source_texture for this instead except that it's not possible
to modify the material's color in that case so we couldn't render the
texture with opacity.
The corner textures are now stored as a handle to a material that
references the texture rather than storing the texure directly. There
is also a separate border_material member which always points to
border_texture as the only layer.
https://bugzilla.gnome.org/show_bug.cgi?id=633340
Non-uniform border-radii are already supported when using a gradient
background, this patch adds support for solid colors as well.
The currently applied technique of using corner textures and filling
the remaining area with rectangles is extended, so that each corner is
padded with rectangles to the size of the largest corner.
Add border-radius.js to test cases, to test non-uniform border-radii
with both solid color and gradient backgrounds.
https://bugzilla.gnome.org/show_bug.cgi?id=631091
Move shadow helper functions from st-theme-node-drawing to st-private
to make them available to widgets which want to add shadows to internal
actors.
Also add a new helper function for creating the shadow material from a
ClutterActor.
https://bugzilla.gnome.org/show_bug.cgi?id=624384
Add basic support for background-position, which only supports absolute
values.
Also don't require an unit to be specified for 0 (because the unit does not
really matter here 0 is 0 regardless of the unit).
https://bugzilla.gnome.org/show_bug.cgi?id=624375
Add st_theme_node_paint_equal() and use that to do two things:
1) Avoid animating transitions where nothing changes.
2) Copy cached painting state from the old theme node to the new
theme node.
https://bugzilla.gnome.org/show_bug.cgi?id=627083
There's an assertion in calculate_gaussian_kernel() to avoid a division
by zero - due to an unnecessary cast from float to int this assertion
is triggered incorrectly for small (but non-zero) values, e.g. a blur
radius of 1px.
StThemeNodes may have properties - namely shadows - which paint
outside an actor's allocation. This is not a problem unless drawing
is redirected to an offscreen buffer, in which case the actually
painted size is needed in advance when setting up the buffer.
Add a convenience method to calculate an allocation large enough to
paint the node.
https://bugzilla.gnome.org/show_bug.cgi?id=619025
Currently shadows disregard the overall opacity, so e.g. setting
an ancestor's opacity does not effect the shadow. Fix this by
deferring the setting of the shadow's color until it is painted.
Also move duplicated drawing code from st_theme_node_paint() into
its own function.
https://bugzilla.gnome.org/show_bug.cgi?id=619083
The (optional) spread radius allows to make the shadow bigger without
enlarging the blur value. Mozilla supports this parameter for the
-moz-box-shadow property.
https://bugzilla.gnome.org/show_bug.cgi?id=613832
The idea behind this move is that we have a lot more control over
rendering if StWidget isn't a big pile of actors, and things are
more efficient.
https://bugzilla.gnome.org/show_bug.cgi?id=607500
