Also removes some mozilla:: where its no longer needed
Note that this patch was created by running
sed -e -i '.bak' 's/typedef ([a-zA-Z0-9:]+) ([a-zA-Z0-9:]+)/using \2 = \1/'
and then fixing up a few cases that didn't work.
Differential Revision: https://phabricator.services.mozilla.com/D83294
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--HG--
extra : moz-landing-system : lando
In bug 1488300 xidorn make us kick off loading of masks/filters/clipPaths in
resource documents when the style context is set so that the 'load' event
will be blocked until they load. I missed that in 5177bb8cb2ce (bug 1494355)
where we stopped creating the SVGFilterObserverList in
SVGObserverUtils::GetEffectProperties since I missed that creating that object
looks up the target element (without observing it), which triggers loading of
external resources as necessary.
Differential Revision: https://phabricator.services.mozilla.com/D7188
--HG--
extra : rebase_source : 698fe4b437660761e457ecf54d8d604a098229db
extra : amend_source : 3ae9f25761372ee6a33bd4043c7bf6183361ca58
The lack of clarity over which functions initiate observing and which don't
is a headache since it makes it hard to reason about what's going on. This
rename makes it explicit in the function names.
Differential Revision: https://phabricator.services.mozilla.com/D7187
--HG--
extra : rebase_source : 1f2f86423a9bee7843533c09b3ea78416b233bcd
extra : amend_source : a89125d6a3b7b75a4056c4d600de74a5386ac4ff
This code is no longer necessary since we now invalidate using Display List
Based Invalidation instead of using recursive calls up the frame tree.
The tests that are marked as failing have only been passing due to a bug in the
code that's being removed from nsSVGIntegrationUtils.cpp which coincidentally
hides the fact that we are actually invalidating in those tests given their
particular structure (which the tests are supposed to be checking we're not
doing).
Differential Revision: https://phabricator.services.mozilla.com/D6850
--HG--
extra : rebase_source : cb95359d694dafeca915a22b3c48f580a69679ef
extra : amend_source : 7074f5837170ce0a9243811291782f689666e122
Using nsSVGPaintingProperty to observe SVG "template" elements means that we
unnecessarily call InvalidateFrameSubtree(), and unnecessarily call
InvalidateRenderingObservers instead of just calling
InvalidateDirectRenderingObservers. Besides that it's confusing to anyone
trying to understand the code why href-to-template is a "painting" property.
Creating a new type solves all these issues.
Differential Revision: https://phabricator.services.mozilla.com/D6453
--HG--
extra : rebase_source : cd3e731cf08d008096bf5ff20592a28fdfaf4a1b
This is necessary to keep the GET_MARKER macro in the next patch clean.
Differential Revision: https://phabricator.services.mozilla.com/D6409
--HG--
extra : rebase_source : 44a6eb861a1fd8d2037eda05c0f99c0bba3f1417
Simon Giesecke
Ting-Yu Lin
longsonr
Mihai Alexandru Michis
Mirko Brodesser
Thomas Nguyen
Emilio Cobos Álvarez
Jonathan Watt
Brindusan Cristian
Matt Woodrow
Sylvestre Ledru
Cameron McCormack
Narcis Beleuzu