This now allows passing a 'fill_color' to the blur, any fully
transparent pixels will be replaced with this color (with the alpha
set to 0).
For box-shadows, if this color is set to the same as the shadow,
the issues around the fringes are fixed. This also fixes some places
where dark shadows appeared light / the wrong color.
With this change the blur no longer dominates the profile. On my PC
it is down to 27% (which is the same as the AA ellipse painting).
The box-shadow.html test page now also feels more responsive.
This adds an implementation of StackBlur which is a very efficient
blur that closely approximates a gaussian blur. It has a number of
benefits over the existing FastBoxBlurFilter:
1. It's faster (~half the pixel lookups of a single box blur pass)
2. It only requires a single pass over image to produce good results
- (Rather than the 3 the box blur requires)
3. It only needs to allocate a buffer of `blur_radius * 2 + 1` colors
- These easily fits on the stack for any reasonable radius
For a detailed explanation of the algorithm check out this link:
https://observablehq.com/@jobleonard/mario-klingemans-stackblur
I saw one site relying on this, where they are trying to set
XHR.responseType to "text/plain", which is not a valid responseType.
However, they also don't expect it to throw. The IDL spec special cases
enumerations to make it return instead of throwing in this case.
Previously we forwarded all event handler attributes to Window from
these two elements, however, we are only supposed to forward blur,
error, focus, load, resize and scroll.
Because the content widget gets modified when resizing, the usual way of
calculating the min_size won't work for the Terminal window. So the
automatic min_size calculation will be disabled for now.
This allows us to skip storing the actual backing data in a separate
`Vector`, as we know that we are working with `environ`-backed storage
here.
Also, while the logic is currently very similar to what `getenv` does
internally, this allows us to eventually implement custom environment
variable filters while remaining linear in run time.
Before this, the spacers were handled as just another child widget, and
as such could take away space from real widgets when growing.
This also fixes the problem of effectively 0 sized spacers, that doubled
the spacing between the widgets they were placed between.
Effective sizes are the ones that are actually to be used for layout.
They are just their respective propertys value, or the value returned
by the calculated_<min/preferred>_size, when the respective property
is set to shrink or fit.
The "calculated" values in turn are specific to the widget. Container
widgets for example can calculate their values depending on their
layout and child widget requirement.
Simple widgets like labels and buttons can for example calculate their
values based upon their current text.
