Intent to implement: CSS Typed OM

141 views
Skip to first unread message

Eddy Mead

unread,
Oct 20, 2015, 10:45:37 PM10/20/15
to blink-dev
Contact emails

Spec (in progress)

Summary
Implement a MVP for a rewrite of the CSSOM

Motivation
The new CSSOM aims to provide typed style access for developers. This will  generally improve performance primarily by removing the need to do lots of string parsing. In addition to this, it will enable performant development of various new Houdini specifications (including custom properties, layout and paint).

Compatibility Risk
Firefox: No public signals
Edge: Public support
Safari: No public signals
Web developers: Mixed signals

Describe the degree of compatibility risk you believe this change poses
None yet as not requesting permission to ship. This is meant to allow experimentation to gauge what the performance improvements will be and to shape the evolution of the specification. 

Ongoing technical constraints
No technical constraints on existing platform, but other houdini APIs will be shaped by this.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes

OWP launch tracking bug

Link to entry on the feature dashboard

Requesting Approval to ship?
No

Rick Byers

unread,
Oct 20, 2015, 11:11:46 PM10/20/15
to Eddy Mead, blink-dev, sh...@chromium.org
+1 - yay!

Note that Firefox and Safari representatives were present at the Houdini meeting in Paris where this was discussed.  IIRC there was some support from everyone for making typed OM a priority, but I forget the details and it looks like the notes were never posted.  Shane did we capture the results of the voting at the end somewhere - it's not in the IRC log.

Rick

Philip Jägenstedt

unread,
Oct 21, 2015, 8:06:45 AM10/21/15
to Rick Byers, Eddy Mead, blink-dev, sh...@chromium.org
How confident can we be that this will actually be a performance
improvement? CSSStyleRule, which has been given a new styleMap
attribute, is already a wrapper around a compat internal
representation, so I presume that every new interface introduced by
CSS Typed OM will similarly be wrappers? If so, it seems like
interacting with this API would have to create a lot of new objects
with hooks to keep them in sync with the internal representation. At
first glance, it doesn't seem like a given that this would be faster
than string parsing, and at the very least it ought to use more
memory.

Implementing may of course help answer questions like these, but I'm
curious to know if I'm being too pessimistic.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

Rick Byers

unread,
Oct 21, 2015, 12:29:40 PM10/21/15
to Philip Jägenstedt, Eddy Mead, blink-dev, sh...@chromium.org
On Wed, Oct 21, 2015 at 8:06 AM, Philip Jägenstedt <phi...@opera.com> wrote:
How confident can we be that this will actually be a performance
improvement? CSSStyleRule, which has been given a new styleMap
attribute, is already a wrapper around a compat internal
representation, so I presume that every new interface introduced by
CSS Typed OM will similarly be wrappers? If so, it seems like
interacting with this API would have to create a lot of new objects
with hooks to keep them in sync with the internal representation. At
first glance, it doesn't seem like a given that this would be faster
than string parsing, and at the very least it ought to use more
memory.

Implementing may of course help answer questions like these, but I'm
curious to know if I'm being too pessimistic.

The plan, as I understood it, was definitely to have a fast implementation that avoided conversion back and forth between strings.  Not sure if we have any data yet on what to expect.  It's probably a good idea to do some microbenchmarks early in the implementation to get some concrete data.  Eddy / Shane, do you have any particular target scenario to focus measurements on?  Eg. what's the string parsing overhead of common scenarios like animating the position of a bunch of elements by changing their style.transform?

Dimitri Glazkov

unread,
Oct 21, 2015, 12:36:06 PM10/21/15
to Rick Byers, Philip Jägenstedt, Eddy Mead, blink-dev, sh...@chromium.org
FWIW, instrumenting and setting experiment exit goals around perf/memory sound like a great idea to me.

:DG<

Ojan Vafai

unread,
Oct 21, 2015, 12:38:35 PM10/21/15
to Rick Byers, Philip Jägenstedt, Ian Kilpatrick, Eddy Mead, blink-dev, sh...@chromium.org
On Wed, Oct 21, 2015 at 9:29 AM Rick Byers <rby...@chromium.org> wrote:
On Wed, Oct 21, 2015 at 8:06 AM, Philip Jägenstedt <phi...@opera.com> wrote:
How confident can we be that this will actually be a performance
improvement? CSSStyleRule, which has been given a new styleMap
attribute, is already a wrapper around a compat internal
representation, so I presume that every new interface introduced by
CSS Typed OM will similarly be wrappers? If so, it seems like
interacting with this API would have to create a lot of new objects
with hooks to keep them in sync with the internal representation.

The design is that the things exposed are copies (not the styleMap itself, but the things you query out of the styleMap). So they are not live (i.e. not kept in sync with the internal representation). This was done specifically for the performance/memory/complexity reasons you cite.
 
At
first glance, it doesn't seem like a given that this would be faster
than string parsing, and at the very least it ought to use more
memory.

Implementing may of course help answer questions like these, but I'm
curious to know if I'm being too pessimistic.

The plan, as I understood it, was definitely to have a fast implementation that avoided conversion back and forth between strings.  Not sure if we have any data yet on what to expect.  It's probably a good idea to do some microbenchmarks early in the implementation to get some concrete data.  Eddy / Shane, do you have any particular target scenario to focus measurements on?  Eg. what's the string parsing overhead of common scenarios like animating the position of a bunch of elements by changing their style.transform?

The primary benefit was in Ian's prototype of custom layout where string parsing was by far the dominant factor (e.g. 2x!). The same benefit should apply outside of custom layout, but the codepaths likely won't be as hot.

Philip Jägenstedt

unread,
Oct 22, 2015, 3:29:04 AM10/22/15
to Ojan Vafai, Rick Byers, Ian Kilpatrick, Eddy Mead, blink-dev, sh...@chromium.org
On Wed, Oct 21, 2015 at 6:38 PM, Ojan Vafai <oj...@chromium.org> wrote:
On Wed, Oct 21, 2015 at 9:29 AM Rick Byers <rby...@chromium.org> wrote:
On Wed, Oct 21, 2015 at 8:06 AM, Philip Jägenstedt <phi...@opera.com> wrote:
How confident can we be that this will actually be a performance
improvement? CSSStyleRule, which has been given a new styleMap
attribute, is already a wrapper around a compat internal
representation, so I presume that every new interface introduced by
CSS Typed OM will similarly be wrappers? If so, it seems like
interacting with this API would have to create a lot of new objects
with hooks to keep them in sync with the internal representation.

The design is that the things exposed are copies (not the styleMap itself, but the things you query out of the styleMap). So they are not live (i.e. not kept in sync with the internal representation). This was done specifically for the performance/memory/complexity reasons you cite.

I see, that makes me far more optimistic. It still doesn't seem like a given that the overhead of allocating many StyleValue object will be less than the overhead of string parsing, but it will be very interesting to find out!

Philip

Eddy Mead

unread,
Oct 27, 2015, 12:24:05 AM10/27/15
to Philip Jägenstedt, Ojan Vafai, Rick Byers, Ian Kilpatrick, Eddy Mead, blink-dev, sh...@chromium.org
Dimitiri/Rick - we definitely plan to do some perf/memory testing. We don't have detailed plans for exactly what we'll do yet - but we'll definitely some around transforms + animation where string parsing is currently slow.
--
Regards,


Edwina Mead
Software Engineer
Google Australia
Reply all
Reply to author
Forward
0 new messages