Re: [webkit-dev] Implement Geometry Interfaces
Why can't these data structures be implemented as JavaScript built-ins that behave as if they were DOM objects? -Filip On Jun 12, 2014, at 10:45 PM, Dirk Schulze k...@webkit.org wrote: On Jun 13, 2014, at 1:54 AM, Benjamin Poulain benja...@webkit.org wrote: On 6/12/14, 11:24 AM, Dirk Schulze wrote: I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. This is such a weird idea. Ideally, the JavaScript compiler should optimize the handling of all those types. By having them in the DOM, you will make those optimizations a lot harder to make. I don’t think that there is a real performance gain in comparison to a native implementation in DOM. Also, these interfaces are primarily designed as a way to communicate with CSS OM, DOM, SVG DOM and convenience for authors. Therefore, any performance optimizations in JavaScript should probably be more radical and address the DOM in general and not just a couple of APIs. Wouldn't those type suffer the same fate as WebKitCSSMatrix: being inefficient on a large scale? The performance problems of WebKitCSSMatrix can be found in two areas: * Even if the transformations are purely 2D, all matrix operations happen in 3D. This can be addressed. * All transformations return a new WebKitCSSMatrix which allocates more memory. DOMMatrix addressed this with in-place transformation where the matrix itself is transformed. DOMMatrix is still compatible to WebKitCSSMatrix and SVGMatrix. Furthermore * DOMMatrix supports Float32Array and Float64Array as interchange format to make its use in JS even faster. What is the rationale for not having JavaScript primitive types? I don’t think that any of the interfaces can be described as “primitive”. They rather seem specific for the designed purpose. Greetings, Dirk Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Jun 13, 2014, at 8:36 AM, Filip Pizlo fpi...@apple.com wrote: Why can't these data structures be implemented as JavaScript built-ins that behave as if they were DOM objects? I am not sure. What do you have in mind? How could it look like? Greetings, Dirk -Filip On Jun 12, 2014, at 10:45 PM, Dirk Schulze k...@webkit.org wrote: On Jun 13, 2014, at 1:54 AM, Benjamin Poulain benja...@webkit.org wrote: On 6/12/14, 11:24 AM, Dirk Schulze wrote: I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. This is such a weird idea. Ideally, the JavaScript compiler should optimize the handling of all those types. By having them in the DOM, you will make those optimizations a lot harder to make. I don’t think that there is a real performance gain in comparison to a native implementation in DOM. Also, these interfaces are primarily designed as a way to communicate with CSS OM, DOM, SVG DOM and convenience for authors. Therefore, any performance optimizations in JavaScript should probably be more radical and address the DOM in general and not just a couple of APIs. Wouldn't those type suffer the same fate as WebKitCSSMatrix: being inefficient on a large scale? The performance problems of WebKitCSSMatrix can be found in two areas: * Even if the transformations are purely 2D, all matrix operations happen in 3D. This can be addressed. * All transformations return a new WebKitCSSMatrix which allocates more memory. DOMMatrix addressed this with in-place transformation where the matrix itself is transformed. DOMMatrix is still compatible to WebKitCSSMatrix and SVGMatrix. Furthermore * DOMMatrix supports Float32Array and Float64Array as interchange format to make its use in JS even faster. What is the rationale for not having JavaScript primitive types? I don’t think that any of the interfaces can be described as “primitive”. They rather seem specific for the designed purpose. Greetings, Dirk Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Thu, Jun 12, 2014 at 11:42 PM, Dirk Schulze k...@webkit.org wrote: On Jun 13, 2014, at 8:36 AM, Filip Pizlo fpi...@apple.com wrote: Why can't these data structures be implemented as JavaScript built-ins that behave as if they were DOM objects? I am not sure. What do you have in mind? How could it look like? I think Phil and Ben are suggesting to implement these types in JSC like we did for typed arrays. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 9:53 AM, Ryosuke Niwa rn...@webkit.org wrote: I think Phil and Ben are suggesting to implement these types in JSC like we did for typed arrays. If you were to do that you probably want to ping TC39 this time around. -- http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On 6/13/14, 12:53 AM, Ryosuke Niwa wrote: On Thu, Jun 12, 2014 at 11:42 PM, Dirk Schulze k...@webkit.org mailto:k...@webkit.org wrote: On Jun 13, 2014, at 8:36 AM, Filip Pizlo fpi...@apple.com mailto:fpi...@apple.com wrote: Why can't these data structures be implemented as JavaScript built-ins that behave as if they were DOM objects? I am not sure. What do you have in mind? How could it look like? I think Phil and Ben are suggesting to implement these types in JSC like we did for typed arrays. Yeah, sorry, I kind of jumped to the conclusion than the DOM prefix implied WebCore objects with wrappers, etc. If they are built-ins, that would be a nice tool for 2D/3D work. It would suck a bit to have the DOM prefix on basic types but I can live with that. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 12:59 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 9:53 AM, Ryosuke Niwa rn...@webkit.org wrote: I think Phil and Ben are suggesting to implement these types in JSC like we did for typed arrays. If you were to do that you probably want to ping TC39 this time around. I'm not certain if we're suggesting to change the semantics although that might make sense. What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org wrote: What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. I understand that, but given that it is in the JavaScript engine at that point, they cannot realistically standardize on a different abstraction later on. And I got the impression typed arrays caught them off guard, so giving them a heads up this time around might be good. -- http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Jun 13, 2014, at 10:17 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org wrote: What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. I understand that, but given that it is in the JavaScript engine at that point, they cannot realistically standardize on a different abstraction later on. And I got the impression typed arrays caught them off guard, so giving them a heads up this time around might be good. Blink is slowly moving the DOM into the JS engine. That doesn't make the DOM part of ECMAScript or needs approval of TC39. I do not think that typed arrays can be compared to DOMPoint or DOMMatrix. But DOMPoint to the plans of implementing DOM in JSC. I am interested in implementing the geometry interfaces into JSC. I wonder if we could generate the code from IDL as well. I do not think that this is possible with our code generators today. Is it? Greetings Dirk -- http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 1:16 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org wrote: What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. I understand that, but given that it is in the JavaScript engine at that point, they cannot realistically standardize on a different abstraction later on. What kind of abstraction layer are you thinking of? As far as I looked at the working draft, DOMPoint, etc... are regular DOM objects specifically created for DOM APIs. I can't think of use cases for these kinds of objects without DOM. I feel like we're talking past each other so let me rephrase it again. All I'm saying is that whether something is implemented in JSC or WebCore is a pure implementation detail. We should be able to do whatever the heck we please to do as long as our implementations adhere to respect specifications. Heck, JSC and WebCore could be a single project called WebKit that can't be separately built. And I got the impression typed arrays caught them off guard, so giving them a heads up this time around might be good. I understand your concern and sentiment but I'm having a hard time imagining what kind of problems/concerns would TC39 have with these interfaces that are clearly prefixed with DOM. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 1:27 AM, Dirk Schulze dschu...@adobe.com wrote: On Jun 13, 2014, at 10:17 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 10:12 AM, Ryosuke Niwa rn...@webkit.org wrote: What I'm saying is that we can implement it in JavaScriptCore for performance and we still make it look like a regular DOM object with wrappers to preserve the semantics. I understand that, but given that it is in the JavaScript engine at that point, they cannot realistically standardize on a different abstraction later on. And I got the impression typed arrays caught them off guard, so giving them a heads up this time around might be good. Blink is slowly moving the DOM into the JS engine. That doesn't make the DOM part of ECMAScript or needs approval of TC39. I do not think that typed arrays can be compared to DOMPoint or DOMMatrix. But DOMPoint to the plans of implementing DOM in JSC. I am interested in implementing the geometry interfaces into JSC. I wonder if we could generate the code from IDL as well. I do not think that this is possible with our code generators today. Is it? I bet we can make sufficient improvements to our code generator such that these objects are as fast as pure JavaScript objects but I don't think it does so today as far as I looked at. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 10:32 AM, Ryosuke Niwa rn...@webkit.org wrote: I understand your concern and sentiment but I'm having a hard time imagining what kind of problems/concerns would TC39 have with these interfaces that are clearly prefixed with DOM. That if they end up as objects in JavaScript engines they end up leaking outside of browsers affecting other parts of the JavaScript ecosystem. (And actually, we do run new APIs by TC39 for review, so if these have passed for review on public-script-co...@w3.org, perhaps calling out this implementation tactic, that might be sufficient.) -- http://annevankesteren.nl/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 1:53 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 10:32 AM, Ryosuke Niwa rn...@webkit.org wrote: I understand your concern and sentiment but I'm having a hard time imagining what kind of problems/concerns would TC39 have with these interfaces that are clearly prefixed with DOM. That if they end up as objects in JavaScript engines they end up leaking outside of browsers affecting other parts of the JavaScript ecosystem. (And actually, we do run new APIs by TC39 for review, so if these have passed for review on public-script-co...@w3.org, perhaps calling out this implementation tactic, that might be sufficient.) If that were the concern, we can simply add a private API that WebCore uses to enable these objects at run time. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Fri, Jun 13, 2014 at 2:05 AM, Ryosuke Niwa rn...@webkit.org wrote: On Fri, Jun 13, 2014 at 1:53 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jun 13, 2014 at 10:32 AM, Ryosuke Niwa rn...@webkit.org wrote: I understand your concern and sentiment but I'm having a hard time imagining what kind of problems/concerns would TC39 have with these interfaces that are clearly prefixed with DOM. That if they end up as objects in JavaScript engines they end up leaking outside of browsers affecting other parts of the JavaScript ecosystem. (And actually, we do run new APIs by TC39 for review, so if these have passed for review on public-script-co...@w3.org, perhaps calling out this implementation tactic, that might be sufficient.) If that were the concern, we can simply add a private API that WebCore uses to enable these objects at run time. Having said that, it would be much cleaner to improve our binding code and do it in WebCore. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Implement Geometry Interfaces
Hi, I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. Greetings, Dirk [1] http://dev.w3.org/fxtf/geometry/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On 6/12/14, 11:24 AM, Dirk Schulze wrote: I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. This is such a weird idea. Ideally, the JavaScript compiler should optimize the handling of all those types. By having them in the DOM, you will make those optimizations a lot harder to make. Wouldn't those type suffer the same fate as WebKitCSSMatrix: being inefficient on a large scale? What is the rationale for not having JavaScript primitive types? Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Implement Geometry Interfaces
On Jun 13, 2014, at 1:54 AM, Benjamin Poulain benja...@webkit.org wrote: On 6/12/14, 11:24 AM, Dirk Schulze wrote: I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. These interfaces are more or less specified versions of proprietary interfaces like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect or SVGMatrix that get unified between HTML/CSS and SVG. The specification progressed fast and is going to LC within the next weeks. I am going to start with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other interfaces one by one. With the exception of DOMMatrix, all interfaces are implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be implemented in Gecko soon. These interfaces will be used by other specifications like CSS OM View or SVG. I am going to implement these APIs behind a compiler flag called GEOMETRY. I would like to enable the compiler flag by default for better testing. Production builds should disable the compiler flag. I will pull out stable APIs from the flag when appropriate. This is such a weird idea. Ideally, the JavaScript compiler should optimize the handling of all those types. By having them in the DOM, you will make those optimizations a lot harder to make. I don’t think that there is a real performance gain in comparison to a native implementation in DOM. Also, these interfaces are primarily designed as a way to communicate with CSS OM, DOM, SVG DOM and convenience for authors. Therefore, any performance optimizations in JavaScript should probably be more radical and address the DOM in general and not just a couple of APIs. Wouldn't those type suffer the same fate as WebKitCSSMatrix: being inefficient on a large scale? The performance problems of WebKitCSSMatrix can be found in two areas: * Even if the transformations are purely 2D, all matrix operations happen in 3D. This can be addressed. * All transformations return a new WebKitCSSMatrix which allocates more memory. DOMMatrix addressed this with in-place transformation where the matrix itself is transformed. DOMMatrix is still compatible to WebKitCSSMatrix and SVGMatrix. Furthermore * DOMMatrix supports Float32Array and Float64Array as interchange format to make its use in JS even faster. What is the rationale for not having JavaScript primitive types? I don’t think that any of the interfaces can be described as “primitive”. They rather seem specific for the designed purpose. Greetings, Dirk Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
