Re: [webkit-dev] Implement Geometry Interfaces

2014-06-13 Thread Filip Pizlo
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

2014-06-13 Thread Dirk Schulze

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

2014-06-13 Thread Ryosuke Niwa
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

2014-06-13 Thread Anne van Kesteren
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

2014-06-13 Thread Benjamin Poulain

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

2014-06-13 Thread Ryosuke Niwa
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

2014-06-13 Thread Anne van Kesteren
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

2014-06-13 Thread Dirk Schulze


 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

2014-06-13 Thread Ryosuke Niwa
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

2014-06-13 Thread Ryosuke Niwa
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

2014-06-13 Thread Anne van Kesteren
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

2014-06-13 Thread Ryosuke Niwa
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

2014-06-13 Thread Ryosuke Niwa
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