Contact emails
jinho...@samsung.com, caba...@adobe.com, dsch...@chromium.org, esprehn@chromium.org,
chri...@chromium.org, p...@chromium.org
Spec
https://drafts.fxtf.org/geometry/
Summary
The specification provides basic geometric interfaces to represent points, rectangles,
quadrilaterals and transformation matrices that can be used by other modules or specifications.
We will ship following interfaces:
- DOMMatrix and DOMMatrixReadOnly
- DOMRect and DOMRectReadOnly
- DOMQuad
- DOMPoint and DOMPointReadOnly
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/lECG9SikFwEJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
http://test.csswg.org/suites/geometry-1_dev/nightly-unstable/html/toc.htm
More conformance tests will be followed up.
Debuggability
You can enable the geometry interfaces by passing "--enable-blink-features=GeometryInterfaces" to Chrome and try the constructors and functions of these interfaces.
Interoperability and Compatibility Risk
The specification has been proposed in 2013 and some browsers have shipped the interfaces since 2014, so generally the risk is low.
As the specification has undergone several changes (https://drafts.fxtf.org/geometry/#changes) since 2014, other browsers have not picked up the new constructors for
several ReadOnly interfaces yet; but such a non-interoperability will be short-termed as other browsers match the latest specification in the future.
Edge: No signals
Firefox: Shipped
Safari: Shipped
Web developers: Positive
OWP launch tracking bug
Entry on the feature dashboard
I think it is unreasonable to make such assumptions. For example, it would be quite possible to develop and use widely a polyfill (that matches the Gecko implementation), which uses the native implementation if available. That would then break in Chromium if they use rotate(angle, originX, originY) semantics instead of rotate(rotX, rotY, rotZ).On Mon, 13 Mar 2017 02:55:27 +0100, Rik Cabanier <caba...@gmail.com> wrote:
On Fri, Mar 10, 2017 at 2:30 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
On 3/10/17 5:16 PM, Boris Zbarsky wrote:
Specifically, the behavior of rotate/rotateSelf was totally changed
without an easy way to detect it without actually trying to rotate a
matrix.
I guess all the args became optional, so the .length changed here too. So
the real question is how likely sites are to be checking .length.
It's probably very unlikely as few sites are using the API since it only
shipped in Firefox.,
On 3/17/17 12:56 PM, gog...@gmail.com wrote:
WebKitCSSMatrix(undefined) throws no exception.
But DOMMatrix(undefined) throws SyntaxError.
This seems like a spec bug in DOMMatrix to me, coming from its arguable misuse of overloads.
It could be addressed in the spec simply by replacing this:
Constructor,
Constructor(DOMString transformList),
with:
Constructor(optional DOMString transformList)
and defining the "not passed" behavior to create an identity matrix.
Of course the spec could also move entirely away from overloads to a single optional union-typed argument.
I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.
On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.CSS supports the transform syntax, so DOMMatrix has to support it as well.
On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.CSS supports the transform syntax, so DOMMatrix has to support it as well.That's not how Typed OM works. It represents transforms as an operation list:To parse to a transform list you'd use this API:
The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.
On Mon, Mar 20, 2017 at 12:57 PM, Elliott Sprehn <esp...@chromium.org> wrote:On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.CSS supports the transform syntax, so DOMMatrix has to support it as well.That's not how Typed OM works. It represents transforms as an operation list:To parse to a transform list you'd use this API:I see.That functionality wasn't specified when DOMMatrix was designed. I agree that it removes the original reason for supporting this constructor.The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.It's still valuable to parse a transform string directly into a matrix. I suspect that developers prefer the direct approach of the string, as opposed to going though the extra constructor of CSSStyleValue and all the checking
On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.CSS supports the transform syntax, so DOMMatrix has to support it as well.That's not how Typed OM works. It represents transforms as an operation list:To parse to a transform list you'd use this API:The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.
Contact emails
jinho...@samsung.com, caba...@adobe.com, dsch...@chromium.org, esp...@chromium.org,
chri...@chromium.org, p...@chromium.org
Spec
https://drafts.fxtf.org/geometry/
Summary
The specification provides basic geometric interfaces to represent points, rectangles,
quadrilaterals and transformation matrices that can be used by other modules or specifications.
We will ship following interfaces:
- DOMMatrix and DOMMatrixReadOnly
- DOMRect and DOMRectReadOnly
- DOMQuad
- DOMPoint and DOMPointReadOnly
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/d/msg/blink-dev/V_bJNtOg0oM/lECG9SikFwEJ
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
http://test.csswg.org/suites/geometry-1_dev/nightly-unstable/html/toc.htm
More conformance tests will be followed up.
Debuggability
You can enable the geometry interfaces by passing "--enable-blink-features=GeometryInterfaces" to Chrome and try the constructors and functions of these interfaces.
Interoperability and Compatibility Risk
The specification has been proposed in 2013 and some browsers have shipped the interfaces since 2014, so generally the risk is low.
As the specification has undergone several changes (https://drafts.fxtf.org/geometry/#changes) since 2014, other browsers have not picked up the new constructors for
several ReadOnly interfaces yet; but such a non-interoperability will be short-termed as other browsers match the latest specification in the future.
Edge: No signals
Firefox: Shipped
Safari: Shipped
Web developers: Positive
OWP launch tracking bug
Entry on the feature dashboard
Hi all,What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?
On Thu, Mar 9, 2017 at 2:57 AM xlai <xl...@chromium.org> wrote:
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
On Mon, Mar 20, 2017 at 8:59 PM, Philip Jägenstedt <foo...@chromium.org> wrote:Hi all,What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?Would the advantage be that there will only ever be 1 matrix interface in the platform? If so, yes, that makes sense.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.Concretely, this is how I think we should ship the Geometry interfaces:
- Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
- Exposing DOMRect* and making ClientRect* an alias of those.
- Exposing the other geometry interfaces at the same time that we ship some API that takes or returns one of those types.
It would be nice to do all of that in a single milestone, but not necessary.xlai@, do you think doing it like this makes sense, or would you prefer another path?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
The Chrome 58 beta blog post mentions -"To improve JavaScript parsing time, SVGPoint, SVGRect, and SVGMatrix have been transferred to new interfaces outside of Geometry."Looks like those were aliased (not transferred, unless "transferred" means "copied") and not outside of Geometry (what does that even mean? The specification? Some interface?), but into Geometry (the specification, as constructors with new names on the global object).Is my understanding correct?
Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.Concretely, this is how I think we should ship the Geometry interfaces:
- Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
- Exposing DOMRect* and making ClientRect* an alias of those.
- Exposing the other geometry interfaces at the same time that we ship some API that takes or returns one of those types.
It would be nice to do all of that in a single milestone, but not necessary.xlai@, do you think doing it like this makes sense, or would you prefer another path?
On Tue, Mar 21, 2017 at 8:41 PM Fredrik Söderquist <f...@opera.com> wrote:
On Tue, Mar 21, 2017 at 6:37 AM, Philip Jägenstedt <foo...@chromium.org> wrote:On Tue, Mar 21, 2017 at 2:35 PM Rik Cabanier <caba...@gmail.com> wrote:On Mon, Mar 20, 2017 at 8:59 PM, Philip Jägenstedt <foo...@chromium.org> wrote:Hi all,What is the plan for ClientRect vs. DOMRect? It would make sense, I think, to try replacing use of ClientRect with DOMRect in the same milestone that ships DOMRect. Otherwise, we will simultaneously ship two rect interfaces and not be sure if we could reduce that to one interface again.Similarly, I think that shipping DOMMatrix ought to be coupled with making it an alias of WebKitCSSMatrix. Does that make sense?Would the advantage be that there will only ever be 1 matrix interface in the platform? If so, yes, that makes sense.Right, I think we should avoid a situation where we hope to replace WebKitCSSMatrix with DOMMatrix, but fail to actually do so and end up with both in perpetuity.There'd still be two (DOMMatrix and SVGMatrix[1]) though, so maybe you should phrase that as "one matrix interface per usage domain" (since AFAICS, WebKitCSSMatrix is only a "loose data type" ATM - i.e not used for data-exchange like SVGMatrix is.)/fs[1] SVGMatrix should be replaced by DOMMatrix, but that will need to be done in a reasonably "atomic" fashion. Probably while doing all the other SVG{Point,Rect,...} to DOM{Point,Rect,...} at the same time.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.Concretely, this is how I think we should ship the Geometry interfaces:
- Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.
On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.Concretely, this is how I think we should ship the Geometry interfaces:
- Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.
There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.
On Tue, Mar 21, 2017 at 5:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.Concretely, this is how I think we should ship the Geometry interfaces:
- Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.Would the only measurable side effect be that that constructor is not available in workers?
There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.Is that a problem?It seems that this is another reason to support this constructor since CSSStyleValue is not supported in workers so you won't be able to parse a transform string there.
On Tue, Mar 21, 2017 at 7:41 PM, Rik Cabanier <caba...@gmail.com> wrote:On Tue, Mar 21, 2017 at 5:32 PM, Elliott Sprehn <esp...@chromium.org> wrote:On Tue, Mar 21, 2017 at 6:09 AM, Philip Jägenstedt <foo...@chromium.org> wrote:Good points, thanks fs. It would be neat to get rid of the SVG* geometry interfaces at the same time, but Gecko still has these, so it's probably OK to have DOM* and SVG* at the same time, like them.Concretely, this is how I think we should ship the Geometry interfaces:
- Exposing DOMMatrix and making WebKitCSSMatrix an alias of it.
I would like to see us drop the CSS parsing from DOMMatrix to fix the layering and make the geometry types into a stand alone set of low level concepts.To retain backwards compatibility for WebKitCSSMatrix we can introduce a separate constructor that takes a string and has the legacy behavior, just like we have Image(width, height) and HTMLImageElement.Would the only measurable side effect be that that constructor is not available in workers?It also avoids the unnecessary coupling in the codebase and makes more sense at the platform level.There's no reason to ever ship WebKitCSSMatrix in workers or anywhere besides the main thread, and right now shipping DOMMatrix is implicitly shipping the CSS parser and tokenizer to background threads.Is that a problem?It seems that this is another reason to support this constructor since CSSStyleValue is not supported in workers so you won't be able to parse a transform string there.If we want to expose the CSS parser inside workers we should do that, we shouldn't be coupling the CSS parser to the low level geometry types. Just like new Array() shouldn't parse JSON.
--
There were several potential concerns I heard on this thread and some others. They included: (a) performance, (b) API layering, (c) compatibility with the existing matrix class, and (d) potential duplication or different implementation of geometric types in different places in various web APIs.I think we need to put this intent on hold for a bit while these items are discussed some more. I will consult with the various people who have raised ideas or concerns, coordinate finding answers to these questions that we can get consensus on, and come back to this thread with the results.
On Tue, Mar 28, 2017 at 9:23 AM, Chris Harrelson <chri...@chromium.org> wrote:There were several potential concerns I heard on this thread and some others. They included: (a) performance, (b) API layering, (c) compatibility with the existing matrix class, and (d) potential duplication or different implementation of geometric types in different places in various web APIs.I think we need to put this intent on hold for a bit while these items are discussed some more. I will consult with the various people who have raised ideas or concerns, coordinate finding answers to these questions that we can get consensus on, and come back to this thread with the results.I'm unsure how much is left to discuss.Mozilla already implemented them and WebKit is in the process of adding them [1]
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.Elliott?
For DOMPoint and DOMQuad, I would prefer to ship those together with some API that makes use of them, is that on the horizon?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.Elliott?I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it.
Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!
I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).
On Mon, Apr 3, 2017 at 11:00 PM, Elliott Sprehn <esp...@chromium.org> wrote:On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.Elliott?I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it.In a previous message, you mentioned that we could add a separate constructor that would only be available in the main thread, That might be a good compromise since there won't be css parsing in a worker and people will likely use this constructor on the main thread.Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!I agree.I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).We tried to make DOMMatrix palatable to all people by providing low level constructors and attributes for arrays and high level matrix functions. The interface caters to easy of use and not high performance.We discussed a similar proposal to yours a couple of years ago and the conclusion was that people that use array buffers, likely want to use their own library so there would be little upside of having built-in matrix operators.
On Wed, Apr 5, 2017 at 8:08 PM, Rik Cabanier <caba...@gmail.com> wrote:On Mon, Apr 3, 2017 at 11:00 PM, Elliott Sprehn <esp...@chromium.org> wrote:On Thu, Mar 30, 2017 at 8:47 AM, Philip Jägenstedt <foo...@chromium.org> wrote:There is one part of this intent that I think should be entirely unproblematic, and that is replacing ClientRect* with DOMRect*.Gecko seems to only expose the geometry APIs on Window. If we did the same, the DOMMatrix off-main-thread parsing problem would go away. The remaining issue with DOMMatrix would be that it does any parsing at all, but to make real progress on that we'd have to pry it out of WebKitCSSMatrix and convince Gecko to try the same for their DOMMatrix.Elliott?I'd much prefer we avoided coupling the Matrix type to the parser (for the reasons listed above and a few others that come from bringing in the whole CSS parser), that does make aliasing this hard of course so perhaps we just need to live with it.In a previous message, you mentioned that we could add a separate constructor that would only be available in the main thread, That might be a good compromise since there won't be css parsing in a worker and people will likely use this constructor on the main thread.Certainly we need to fix the bug where the code is trying to use ComputedStyle from the wrong thread before shipping!I agree.I also filed some bugs against the spec, having thought about integration with the various specs and existing ecosystem more I do wonder if exposing the matrix operations as something that takes a typed array is actually better since it composes with the existing WebGL API without having to go through 3 copies or a large spec retrofit, could be easily invoked from wasm, and similarly lets you use it with a SharedArrayBuffer in a simple way (though maybe that requires specing the order of operations to avoid exposing intermediate state? What does SAB say about concurrent writes/reads and consistency?).We tried to make DOMMatrix palatable to all people by providing low level constructors and attributes for arrays and high level matrix functions. The interface caters to easy of use and not high performance.We discussed a similar proposal to yours a couple of years ago and the conclusion was that people that use array buffers, likely want to use their own library so there would be little upside of having built-in matrix operators.The upsides are:- Fewer bytes over the wire since you don't need to send a whole geometry library.- Can use SSE and Neon to be faster.I also want to challenge the idea that good ergonomics and performance are mutually exclusive. I don't believe we should ship things that are designed to be "easy but slow".
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Folks, as a meta-point: I see y'all having what looks like a design discussion on the intent to ship for and I am worried: 1) it seems pretty late in the process to have a discussion of this kind, and 2) blink-dev is a Chromium's web platform implementation mailing list, rather than a more inclusive W3C list. Would y'all consider gathering the stakeholders, sync-ing up offline on the course of action and come back with a clear resolution?
:DG<
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
:DG<
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
...
[Message clipped]
A very helpful writeup, and illuminating use counters, thanks Chris!It looks like the WebKitCSSMatrix(string) constructor stands in the way of really splitting WebKitCSSMatrix from CSS parsing. I looked for "new WebKitCSSMatrix(" in httparchive, 5843 hits. It looks like the most common thing was this:This uses getComputedStyle(el).transform/webkitTransform as the input, and so presumably will break. Another similar and frequent pattern was `new WebKitCSSMatrix(window.getComputedStyle(e).webkitTransform)`.That combined with Edge's support of the string constructor suggests that the compat constraint is real, and that it'd be a serious undertaking to get rid of it. For the purposes of this intent, I think we should accept it and assume it will not go away.With that starting point, getting rid of just setMatrixValue does not fix the layering problems, so although the risk is lower, I wonder if it's really worth trying to remove it?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
On Tue, Apr 25, 2017 at 6:10 AM, Philip Jägenstedt <foo...@chromium.org> wrote:A very helpful writeup, and illuminating use counters, thanks Chris!It looks like the WebKitCSSMatrix(string) constructor stands in the way of really splitting WebKitCSSMatrix from CSS parsing. I looked for "new WebKitCSSMatrix(" in httparchive, 5843 hits. It looks like the most common thing was this:This uses getComputedStyle(el).transform/webkitTransform as the input, and so presumably will break. Another similar and frequent pattern was `new WebKitCSSMatrix(window.getComputedStyle(e).webkitTransform)`.That combined with Edge's support of the string constructor suggests that the compat constraint is real, and that it'd be a serious undertaking to get rid of it. For the purposes of this intent, I think we should accept it and assume it will not go away.With that starting point, getting rid of just setMatrixValue does not fix the layering problems, so although the risk is lower, I wonder if it's really worth trying to remove it?You make a reasonable point. I think leaving setMatrixValue and limiting to the main thread would be an ok compromise given the compatibility situation.Given that, LGTY?
I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.On Sat, Mar 18, 2017 at 5:17 AM, Boris Zbarsky <bzba...@mit.edu> wrote:On 3/17/17 1:14 PM, Rik Cabanier wrote:
Can that be done later, or will that move have other subtle side effects?
Moving from an overload set where all overloads have one argument, with one of them possibly optional, to a single overload with a single possibly optional union should not have caller-observable effects. If it does, that's a bug in the webidl spec which we should fix forthwith.
I'm not aware of such bugs at the present time, though they have existed in the past (e.g. <https://github.com/heycam/webidl/issues/123>).
-Boris
On Mon, Mar 20, 2017 at 12:57 PM, Elliott Sprehn <esp...@chromium.org> wrote:On Sat, Mar 18, 2017 at 10:57 AM, Rik Cabanier <caba...@gmail.com> wrote:
On Sat, Mar 18, 2017 at 7:58 AM, Elliott Sprehn <esp...@chromium.org> wrote:I'd prefer we actually removed the css parsing feature of DOMMatrix, that's better suited for Typed OM. It's unfortunate layering that the primitive geometry types need to depend on the CSS parser. It feels a bit like new Array() accepting a JSON serialized array. It's also unusual as it's not mirrored anywhere else, ex. DOMRect doesn't accept rect() syntax.
One of the main reason for DOMMatrix was to make it part of Typed OM. That way one could get/set the matrix without stringifying.CSS supports the transform syntax, so DOMMatrix has to support it as well.That's not how Typed OM works. It represents transforms as an operation list:To parse to a transform list you'd use this API:I see.That functionality wasn't specified when DOMMatrix was designed. I agree that it removes the original reason for supporting this constructor.The only reason to support parsing of transform lists for CSSMatrix except for possibly backwards compatibility with WebKitCSSMatrix.I'd prefer we didn't though and kept the parsing as a layer on top of these low level math types.It's still valuable to parse a transform string directly into a matrix. I suspect that developers prefer the direct approach of the string, as opposed to going though the extra constructor of CSSStyleValue and all the checking
Hi all,As promised, I wrote up a doc and contacted many of the people on this thread for feedback. Sorry for the delay.A summary of proposed actions is below.For M60, I propose shipping the following:1. Ship DOMMatrix as-is, but *without* setMatrixValue.
\o/
:DG<
<div class="m_3562094609087605155m_-1457832378083732814m_-6494700340715770940m_-5004652172647091950m_-7259415047987974766m_-3211645023326551307m_-766980658197
Make DOMMatrix not depend on the CSS parser
/#!/JoePea
DOMMatrix
and DOMMatrixReadOnly
(r216959)--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUichEB%3D8Z%3DU7_3nN%3DS5NgQRuVRE6XwSb4ApAiC5mpQ3iY8ww%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUichEB%3D8Z%3DU7_3nN%3DS5NgQRuVRE6XwSb4ApAiC5mpQ3iY8ww%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADp2-T_d%2BH2XvQz1Q-xEhVag%2Bshisak2qztS0k%2Btp29Ur2B1pA%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUichEB%3D8Z%3DU7_3nN%3DS5NgQRuVRE6XwSb4ApAiC5mpQ3iY8ww%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.