The main benefit of using CSS Transitions and Animations on the accelerated properties (transform & opacity) is that the animation will be run by the compositor (at least in WebKit browsers; I think Blink's new animation engine changes this).
Running the animation in the compositor means:
1. You avoid a style recalc on every frame (which can be a big deal).
2. The animation keeps running even if the WebProcess gets contended (by painting new content, handling slow JavaScript, GC).
It's fine to mess with transform and opacity from JavaScript, and for gesture handling you have to, so it needs to be fast, but it has more overhead than a CSS Animation would have.
My understanding is that human-neanderthal interbreeding rarely resulted in viable offspring (though some did, and is where blonde/ginger hair and blue eyes come from in modern humans).
Is that similar here? Are there traits in modern goats or sheep that came from the other?
I imagine not shipping a derivative SDK is to prevent one vendor from making an incompatible "Android+" (and the next vendor, etc) which would cause fragmentation. Instead they get to expose extra APIs through the updater app in the one true Google Android SDK (and you use the same mechanism to get the Google APIs).
Yeah, the CSS OM is really horrible too. CSS Animations is another area where you end up feeding huge generated strings into the DOM -- in theory Web Animations is meant to improve this, though personally I feel like the API too high level and ends up being really large because of this :(.
In your example, I think it'd only be a small patch (for WebKit, where my experience is) to optimize "elem.style.transform = new WebKitCSSMatrix(a,b,c,d)" without intermediate stringification. Mozilla doesn't expose a CSSMatrix type unfortunately. I've done some similar things for other CSS properties in WebKit -- have you considered submitting a patch? I've found the WK guys super receptive to small optimizations which don't change observable behavior (i.e.: you can't tell if the WebKitCSSMatrix was stringified or not currently) like that.
I'm saying that DOM through its relationship to HTML has weaknesses that make it unsuitable for building application components out of. "jQuery-enabled div-soup" is an example of how mixing presentation with model and logic yields unmaintainable results.
I have been interested in React.js recently, since it provides an interface to create reusable components and to use them inside a rich programming language with full types. I think that's a better example of a competing idea.
My experience is with building single page apps from scratch, so maybe there's a common use-case (embedding a twitter widget, or a 3rd party comment system in a blog) that Shadow DOM and Custom Components will address that I'm not familiar with.
I disagree that the Shadow DOM is pretty awesome. I think scoping style is valuable, but building components that are exposed as new tags is not appealing given the vast complexity of the implementation and the limitations of tags.
Markup has a very weak type system (strings and children) which makes building complex UIs more painful than it has to be (this also stands for markup driven toolkits like angular and knockout -- where the equivalent of main() is HTML markup and mostly declarative). Markup isn't a real programming language, and it's very weak compared to a true declarative programming language.
JavaScript however is a real programming language with all of the constructs you need for building extensible systems. For building anything complex (which is where Shadow DOM should shine) you will need to use extensive JS, you will need your Shadow DOM components to expose rich interfaces to JS... At which point, why are you still trying to do mark-up first -- it's something that's more "in your way" than helpful.
It's interesting that the advantage for LLVM is that it was used to create a compiler for a processor with a secret and proprietary instruction set.
If NVIDIA had to use GCC (surely they'd have just done their own instead, but for the sake of argument) then we'd all get to learn more about their architecture and maybe make compilers for different languages that natively target their processors...
No, translateZ just makes it a composited layer. Hardware comes much later in the pipeline and possibly in another process.
The content of the layer isn't hardware rendered. It's rendered by the CPU and uploaded to a texture. In WebKit and probably Blink there's a fast path for images, canvas and video so that they can be directly uploaded or (on some platforms like Mac) bound to a texture avoiding an upload copy.
Microsoft and (maybe) Mozilla have a "hardware rendering" path via Direct2D, but Chrome and WebKit don't, they have compositors which can use the graphics hardware to perform compositing, but not rendering.
The "translateZ: 0" description is a bit misleading -- I wish he'd provided numbers for the improvement. In general using composited layers is more expensive (since the CPU still does rendering of the image, must upload it to texture, etc).
It might be a win if the thing you apply it to:
1. Never changes, but the content around it changes often.
2. Is hard to render (lots of shadows, etc).
The layout and paint thrashing is a really good optimization though. You should be able to insert as many things into the DOM as you like without triggering a layout SO long as you don't read back (like consulting offsetLeft). I think the Chrome inspector will mark read backs with a little exclamation point in the timeline with a tooltip "synchronous layout forced" and a backtrace to your JS...
Chromium is _huge_. If I just wanted to use the HTTP library (with tls and spdy) then how would I build just that, and cleanly integrate the build into my own project in a way that won't require constant revisiting every time I update my chromium sources?
They have a lot of tables which are (depending on the browser) interpreted by OS functions, so if there was a buffer overflow bug in the OS font code then you could exploit it with a webfont.
Most (all? Not sure about Safari) use the "OpenType Sanitizer" on all webfonts, which parses and validates all of the tables and all of the offsets contained within them. http://code.google.com/p/ots
What is this? Python? Why "standardize" Cairo? I can already use Cairo if I want to.
I'd rather they provided some standard template interfaces to all of the common 2D graphics algorithms (simple line clipping, tessellation, polygon clipping, bezier subdivision, etc) and not couple it to a classical scanline rasterizer CPU graphics library. But I don't think that even this belongs in the language standard.
There are a bunch of other opensource libraries they'd need to "standardize" if they want to draw text...
They stipulated that the player use HTML5 so that it could show all of their ads and overlays correctly. That seems pretty reasonable.
Microsoft couldn't have just the player in HTML5 because their embedded webview can't play video -- which is where the stories of "Google wanted the whole app to be done in HTML5" came from.
IMO an embedded webview should be able to play video, or Microsoft should have been able to get something together just for youtube.
Running the animation in the compositor means:
1. You avoid a style recalc on every frame (which can be a big deal).
2. The animation keeps running even if the WebProcess gets contended (by painting new content, handling slow JavaScript, GC).
It's fine to mess with transform and opacity from JavaScript, and for gesture handling you have to, so it needs to be fast, but it has more overhead than a CSS Animation would have.