Profile cover photo
Profile photo
Nat Duca
Do you like my hat?
Do you like my hat?
About
Posts

Post has shared content
Turn your animations on their head!

This is pretty much the technique I outlined at Chrome Dev Summit last year, but now it has a name: FLIP
Add a comment...

Post has shared content
+Paul Lewis bought me a hat. I talk about how to deal with dirty clothes when travelling. Oh, and we also talk about the Frame Timing API
Add a comment...

Post has shared content
Measure+Mutate is a fantastic idiom for performance. Use & enjoy.
Scaling usage requestAnimationFrame and a solution for avoiding style recalculation more than once per frame.

Recently some code that I wrote for Google internally was open sourced as part of the Closure library: "goog.dom.animationFrame"
https://github.com/google/closure-library/blob/master/closure/goog/dom/animationframe/animationframe.js

The library is quite interesting as it solves a big issue when working with browser animations in larger teams:

2 or more tasks want to do work in the same animation frame.

Say task 1 is animating your navigation while task 2 is animating some parts of the content.

In the worst case now the DOM operations look like this:

Animation frame:
Task 1 measures position of object A.
 - Triggers style recalculation
Task 2 changes position of object A.
 - Invalidates previous style calculation.
Task 1 measure position of object B.
 - Triggers another style recalculation
Task 2 changes position of object B.

The new library solves this with the following API:

var animationTask = goog.dom.animationFrame.createTask({
  measure: function(state) {
    state.width = goog.style.getSize(elem).width;
  },
  mutate: function(state) {
    goog.style.setWidth(elem, Math.floor(state.width / 2));
    animationTask();
  }
});

When code wants to schedule an animation frame, they have to supply two functions: One to measure the DOM and one to mutate it.

Because of this separation the library can serialize all the measure and mutate operations to happen in 2 phases: First all the measurements and then all the mutations.

Thus the operations against the DOM per animation frame now look like this:

Animation frame:
Task 1 measures position of object A.
 - Triggers style recalculation
Task 1 measure position of object B.
Task 2 changes position of object A.
Task 2 changes position of object B.

Note, how one style recalculation disappeared – and as more tasks are added this scales further without introducing any additional recalculations.

Besides this major feature, the library also solves the following problems:
- designed to minimize per frame memory allocation.
- designed to avoid accidental scheduling of the same work more then once per animation frame.

If this sounds useful, go ahead wrap the code in some module system of your choice and make your app a little silkier.
Add a comment...

Post has shared content
HTTP 203: a brand new show all about web development!

Join +Paul Lewis and +Jake Archibald as they discuss CSS performance, and how you can gain insight into the impact your code has on browser rendering. 

Make sure to check out www.csstriggers.com to find out more. 

HTTP 203: CSS Triggers
Add a comment...

Post has shared content
A bit of armchair philosophy about what we want the web platform to be.

https://speakerdeck.com/paullewis/edge-layout-performance-panel-intro

I gave the intro to the Layout Performance Panel at Edge 4 today. Here's the deck, which does contain suggestions I don't necessarily hold to, but were intended to spark good discussions.
Photo
Add a comment...

Post has shared content
As of Chrome 37 (soon to be stable), we now report TouchEvent positions as floating-point values, giving your web app on Android the same input resolution that native apps enjoy.

For most uses of touch events this makes slow movement on high-dpi devices smoother without any change to the code.  For example, I drew the below pictures using http://www.rbyers.net/paint.html#points with and without this feature on a Nexus 5 (where each CSS px unit is 3x3 hardware pixels).

There's a draft "errata" of the TouchEvents spec with this API change here: https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#attributes.  There is a plan to bring this improvement to mobile Safari as well: https://bugs.webkit.org/show_bug.cgi?id=133180.  For more details see our bug: http://crbug.com/323935

#Chrome   #Touch  
PhotoPhotoPhotoPhoto
2014-08-28
4 Photos - View album
Add a comment...

Post has attachment
At first glance, HTML5/CSS seems to have amazing capabilities for next gen UIs: any of the 115 or so style-able properties can be animated. Yet, in modern browsers only two properties, transform, and opacity, can be mutated at 60fps. In this talk, I explain why thats the case, and ask the question, "Should we demand better?"
Add a comment...

Post has shared content
In London on August 26 and love web performance? Come and join us!

Featuring A+ speakers: +Nat Duca +Addy Osmani and +Patrick Hamann
Add a comment...

Post has shared content
See how your CSS affects layout, paint and composite.

http://csstriggers.com/

I've been cooking this little site up for the past week or so, and I'm super happy it's gone live. You should also check out the blog post (http://aerotwist.com/blog/css-triggers/) if you want to know more about how it's made (hint: totes automated thanks to Telemetry)

It's beta, so if you find bugs lemme know. <3
Animated Photo
Add a comment...

Post has shared content
:)
If you haven't seen Chrome's FrameViewer, you're in for a treat: http://bit.ly/1uItZvD - everything you ever wanted to know about Chrome's rendering stuck, plus more. Word of warning: chrome://tracing definitely takes some getting used to, but is definitely worth it.
Animated Photo
Add a comment...
Wait while more posts are being loaded