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
