We always serialize as an atom, which is the previous behavior (though previous
code was using string escaping which I think was not totally sound either...).
Differential Revision: https://phabricator.services.mozilla.com/D4753
--HG--
extra : moz-landing-system : lando
We're wasting 1kb there, which is kind of stupid.
The only advantage of using a bloom filter is that memory usage doesn't increase
even if there's a gazillion attribute selectors and such. But:
* For IDs we already have a bunch of data structures for invalidation and such
which key on the id, so the bloom filter would be a very minor thing.
* For attribute selectors we don't have such a data structure, but if people
used a gazillion attribute selectors we should!
Differential Revision: https://phabricator.services.mozilla.com/D4668
--HG--
extra : moz-landing-system : lando
So that we don't waste a bunch of memory with stuff like <svg:use>. I
plan to shrink AuthorStyles further, but this should help regardless, and isn't
very complex.
Differential Revision: https://phabricator.services.mozilla.com/D4618
--HG--
extra : moz-landing-system : lando
We only care about ascii char for svg path, so we could parse the string
as byte slice.
Differential Revision: https://phabricator.services.mozilla.com/D4168
--HG--
extra : moz-landing-system : lando
For now, |clip-path: path()| is chrome-only, and not for shape-outside,
so we only implement the parser for clip-path. Besides, I didn't put
path() in BasicShape because path() doesn't use the reference box to
resolve the percentage or keywords (i.e. SVG path only accept floating
point or integer number as the css pixel value). Therefore, I add it into
ShapeSource, instead of BasicShape.
Differential Revision: https://phabricator.services.mozilla.com/D3633
SVGPathData will be used by clip-path and offset-path (and/or more on the
properties which support <basic-shape>). Therefore, let's move
SVGPathData out of motion.rs.
Differential Revision: https://phabricator.services.mozilla.com/D3631
Just a minor fix to use cbindgen to avoid the conversion between
basic_shape::FillRule and mozilla::StyleFillRule.
Differential Revision: https://phabricator.services.mozilla.com/D4171
--HG--
extra : moz-landing-system : lando
The implementation of ToCSS for Polygon has some rule, and we could use skip_if
to handle and serialization of fill-rule. However, we should derive ToCSS for
the pair of LengthOrPercentages, so define a new type for it.
Differential Revision: https://phabricator.services.mozilla.com/D4153
--HG--
extra : moz-landing-system : lando
This was consistently faster in the benchmark (even when counters were disabled,
which was slightly suspicious, but...).
Anyway, it's not really much code, most of it is FFI copy-pasta.
Differential Revision: https://phabricator.services.mozilla.com/D3874
Mostly testing that they work, and that they record what we expect them to
record, that is, the actual property that was parsed, and not the properties
that it'd resolve or expand to.
That may be another tricky part for CSSOM, I think style setters would fail an
alias test if implemented with the current setup (we do the property lookup in
C++).
Differential Revision: https://phabricator.services.mozilla.com/D3829
Still not hooked into telemetry, I talked with :janerik and :gfritzsche about
that, but test incoming!
This intentionally doesn't handle CSSOM and such for now, will file followups
for those, though should be trivial.
I want to unify / clean up how we do the use counters and the error reporting
stuff for CSSOM, since the current function call still shows up in profiles,
but that should be a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D3828
There are a lot of duplicates, so we use macro to refine them.
Depends on D2963
Differential Revision: https://phabricator.services.mozilla.com/D2966
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
- Parse SVG Path String into SVGPathData (in Rust).
- Use cbindgen to make sure the layout of PathCommand and StylePathCommand, and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
- Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Depends on D2962
Differential Revision: https://phabricator.services.mozilla.com/D2963
--HG--
extra : moz-landing-system : lando
Define OffsetPath & SVGPathData on the servo-side, and StyleMotion &
StyleSVGPath on the gecko-side. We parse the SVG Path string into a
vector of PathCommand. To build the gfx::Path, we will convert it into
gfx::Path later in a different patch.
The basic flow is:
* Parse SVG Path String into SVGPathData (in Rust).
* Use cbindgen to make sure the layout of PathCommand and StylePathCommand,
and then set the Box[PathCommand] into nsTArray<StylePathCommand>.
* Try to convert nsTArray<StylePathCommand> into gfx::Path. (This part
will be implemented in a different patch.)
Finally, we use the gfx::Path to create a motion path transform.
The layout implementation is in the later patch.
Differential Revision: https://phabricator.services.mozilla.com/D2963
Port `width`, and also add the `scan` media feature so I don't need to add
ugliness just to workaround the unused keyword_evaluator macro.
This is not part of the Gecko build in any case.
