randallu

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?

hterm -- the terminal implementation that the Chrome ssh plugin and crosh is based on is pretty hackable, too.

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.

No, that's not what I meant.

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...

Oh, nice! For some reason I thought that was only for canvas.

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...

Model S has a fast pulsing green light around the charge port when it's charging.

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?

We're already half way there: http://kripken.github.io/clangor/demo.html (Clang compiled by Emscripten).

It's pretty depressing they spent all that money on apps and seemed to go nowhere with any of them.

If you have something hot then what can Yahoo possibly offer you to go and work there, knowing that everything else they touched went nowhere?

Also: http://www.businessinsider.com/yahoo-coo-henrique-de-castro-...

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

AGG is pretty nasty to use and has worse performance than Cairo on basics like alpha blends and copies (bitblts).

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.

Is there a better write up of the exploit? How did they escape the renderer sandbox?

(I ask, because I theorize that it's really easy to escape the Chrome renderer sandbox because the renderer is attached to Binder and thus has access to the whole system_server interface and everything else registered through the magic android.os.ServiceManager).

Hopefully the new window.crypto stuff could be used to createa a hosted webmail service where the private key is generated in the browser and never leaves the browser.

I thought Dalvik was quiet because the principal author (Dan Bornstein) left Google a while ago.

Is ART from the recent FlexyCore acquisition, or something else that has been going on for a while?

Qualcomm being at the bottom is counter to my experience in writing GL ES 2.0 apps on Android (since the Motorola Droid!). Adreno generally performs very well, and doesn't have weird performance characteristics like Mali and SGX. I also like Tegra because it has solid predictable performance. A big part of why Qualcomm have been cleaning house in the Android world is because they have a more solid BSP, so compared to the other ARM guys they have a pretty good software group.

I don't use most of the extensions that the Dolphin guys are using, though, and I wouldn't expect anything but the most basic ES 3.0 stuff to work. But maybe spending so many years on mobile has taught me to have low expectations! :).

Mali has a different architecture than desktop GPUs, so glClear generally isn't implemented as a clear op (or drawing two triangles that cover the viewport, etc). It clears out all of the commands that were previously scheduled for that target.

But yeah, the Mali driver has various performance quirks and oddities (there used to be a lot of weird stuff around how you updated index buffers too).

What about WebKit! Now they're down to Apple, GTK+, EFL and BlackBerry (until they go bankrupt).

EFL is funded by Intel and Samsung for Tizen (insurance policy against Android?). GTK+ is supported by consulting and occasional grants. If everyone but Apple leave WebKit will it stay open?

I agree with you, but I suppose the point is to make it the child's decision to share or not when they become mature enough to make that choice.

(Personally my wife and I have no information on our kids online, save a self-hosted blog with a password that only family know...).

Aren't you more uniquely identifiable on a native app, though?

Was he brilliant? Or is that just a story -- "nobody else out of NSA's 20,000 employees is spying on people they shouldn't because they're just "great" not "brilliant", so don't worry!"

To why they didn't go to court:

@dansabbagh "Reason Gdn destroyed the computers was to avoid a lengthy legal UK battle that wld have prevented more reporting of Snowden files."

https://twitter.com/dansabbagh/status/369794535464767488