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
