Profile

Cover photo
Nat Duca
Works at Google
458,931 views
AboutPosts

Stream

Nat Duca

Shared publicly  - 
 
 
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
Animations in your web app should run at 60fps. Not always easy to achieve that,and it really depends on what you're trying to do, but I'm here to help. With FLIP.
8 comments on original post
1
1
Scott Olcott's profile photo
Add a comment...

Nat Duca

Shared publicly  - 
 
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
5 comments on original post
2
Add a comment...

Nat Duca

Shared publicly  - 
 
 
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  
View original post
6
Add a comment...

Nat Duca

Shared publicly  - 
 
 
In London on August 26 and love web performance? Come and join us!

Featuring A+ speakers: +Nat Duca +Addy Osmani and +Patrick Hamann
We have a special event this month courtesy of the Chrome Dev Rel team - 3 speakers on Web Perf topics!  • 1830 – Arrive and sign-in  • 1900 – Nat Duca - The Pursuit of 60fps Everywhere • 1940 – Addy Osmani - Memory Management Masterclass  • 2020 - 10 min comfort break • 2030 – Patrick Hamman - Breaking News at 1000ms • 2100 – Pizza & Beer courtesy of Google Speaker: Nat Duca, Software Engineer - Google Title: The Pursuit of 60fps Everywhere  B...
3 comments on original post
1
1
Alessandro Artoni's profile photo
Add a comment...

Nat Duca

Shared publicly  - 
 
 
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
19 comments on original post
9
2
Dana Jansens's profile photoPaul Lewis's profile photoDan Kalivoda's profile photoMark Bridge's profile photo
5 comments
 
+Dana Jansens So I hide the 'noop' ones for vertical mode, i.e. those where changing the CSS from the default will trigger something, but updating the value does nothing different... something like border-top-color would count as that. Is that confusing? It's easy enough to ditch that if so.
Add a comment...

Nat Duca

Shared publicly  - 
 
 
The one where I ruminate of layers, platforms, cabbages, and kings.

cross-posting from blink-dev
5 comments on original post
1
Add a comment...

Nat Duca

Shared publicly  - 
 
 
+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
View original post
3
1
Sergio Ramirez's profile photo
Add a comment...

Nat Duca

Shared publicly  - 
 
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.
8 comments on original post
2
Stephen South's profile photoNat Duca's profile photoMalte Ubl's profile photo
3 comments
 
+Stephen South It is very similar. Main difference is that goog.dom.animationFrame's API is particularly designed to make it so that the most obvious usage only requires minimal per frame memory allocation. 2 design decisions helps with this:
- the notion of tasks that get scheduled and can be rescheduled.
- a mechanism to transport state between the read and write phases.

My experience is that not-as-experienced engineers would use something like fastdom's API and often allocate a new pair of closures each time anything is scheduled for reading and writing, so I was trying to come up with a design that makes the obvious usage not require that. Another thing that the notion of tasks help with is throttling. I've seen it many times that if e.g. mousemove or scrollwheel fires 2x per animation frame that requestAnimationFrame is called twice and the program draws the same thing 2x in the same frame.

On the other hand, fastdom comes with a package.json, bower.json and component.json, so if you like any of those you should probably use it!
Add a comment...

Nat Duca

Shared publicly  - 
 
 
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.
5 comments on original post
3
1
James Garcia's profile photo
Add a comment...

Nat Duca

Shared publicly  - 
 
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?"
63
103
Jacek Zakowicz's profile photo白丞祐's profile photoStuart Coe's profile photoMarri Goodie's profile photo
14 comments
 
That last bit seems to be the most important - will-change gives you layers without a stacking context.  I'm curious - how do you achieve that?
Add a comment...

Nat Duca

Shared publicly  - 
 
:)
 
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.
3 comments on original post
2
2
Jason Proulx's profile photoMark Bridge's profile photo
Add a comment...

Nat Duca

Shared publicly  - 
 
I'd like to soapbox about the need for rationality in the web platform, using position:sticky as a guinea-pig to explain my perspective.

The thing that bugs me about position:sticky is that is entangled with the magical nature of scrolling on the web. Per spec, the browser can scroll the page up and down without telling JS: you get a scroll event, but it happens after the scroll has actually happened.

Wat.

Here's the thing: this ability in browsers is super important, because scrolling is super duper important to get right for users. Without it, going to espn.com and scrolling is a really horrible user experience. On mobile, that poor site janks for a half second while it loads. I NEED MY SPORTS SCORES TO SCROLL AT 60FPS. The browser works around this by making scroll asynchronous. A simpler example is this: http://jankfree.org/examples/simple_jank.html : on mobile browsers, this scrolls smoothly, even though in devtools you'll see that the page is a cataclysm of jank.

Unfortunately, we've painted ourselves into a corner here, with regard to position:sticky and all other scroll coupled effects. If you try to polyfill sticky positioning, you get jitter. Typically, the user's scroll is immediately handled by the browser, drawn to the screen as fast as possible so it feels responsive. THEN the browser tells JS about it. The polyfill thus hears about the onscroll too late: it valiantly tries to update the sticky position, but the page has been sent to the screen with the movement already applied, so the user perceives a little jump in the next frame as the polyfill's reaction finally makes it onscreen. Designers get cranky, and you don't get to go to space.

Because of this, we have a promulgation of urgent-for-some spec needs: anytime a user wants a scroll-coupled effect, they need need new spec. That gets scary quickly, because lets face it, there's a ton of cool stuff you an do in response to scroll. We articulated this concern once for snap points, here: http://lists.w3.org/Archives/Public/www-style/2014Feb/0769.html 

Sticky positioning is in this space too. A common misconception is that position:sticky is an easily speccable, ready to go, kind of thing. In reality, there many many many variations on position:sticky-ish behavior out there for every simple use case, so speccing it is all about compromises and generalization. Even if we implement a common form of position:sticky, there will be corner cases we don't implement. Want your element to sing a sea shanty and then shrink to scale(0) as it falls offscreen? Sorry, please wait for Level 2 version, tentatively titled "position: even-more-sticky."

So, what to do?

As some might recall, +Dimitri Glazkov wrote a great essay on our need for a rational web platform a while back (https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4jBAnIVwrt0). In it, he points out that we must first and foremost "explain the magic" behind our browser.

I submit that much of the sticky positioning debacle is fallout from the browser being magical about scroll. First and foremost, in this space, we need to explain the magic to the page: that way when the magic isn't quite right, you can get around it to do things your way.

What form should this particular fix to the magic take? Not sure, yet! Maybe we need to explain browser-side scrolling using some new APIs. Or maybe we need to allow content to opt-out of this magic. +Rick Byers has some much more formed ideas on how this might be done.

Important for me is embracing the idea of layering and accidental magic, recognizing that the lack of layering can take a basic feature request and turn it into a much bigger problem.

Consider: if we had a web that had an opt-out for magical scrolling, then we'd have plenty of content out there today doing position:sticky effects. Sure, there'd be the odd incurably janky page out there that wanted sticky, too. And there'd be people asking for sticky effects to be easier to author.

Both are great feature requests. With the immediate "I CANT IMPLEMENT THIS" fires resolved, we can then work through those goals at a normal and healthy web platform pace.

So, here's to identifying layers in the web platform, and fixing the bugs that cause layering to go wonky. And, here's to picking a subset of the most commonly occurring cases on the web and making those easy (https://code.google.com/p/chromium/issues/detail?id=231752).
24
14
Jake Archibald's profile photoMichael-Rainabba Richardson's profile photoTom Turton's profile photoLike Able's profile photo
13 comments
 
Unless the spec has changed, position: sticky would not necessarily solve the table example. It unfortunately described changing an element that is absolute on the page to stuck to the top of the viewport, so it's only page / viewport-related, instead of to the top of any scroll container , making the proposal extremely shortsighted IMO.
Add a comment...
Story
Tagline
Do you like my hat?
Introduction
Making Chrome run at 60 fps, or bust.
Work
Employment
  • Google
    present