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
