PAUL IRISH: We have Tom
Wiltzius and Nat Duca.
They are on the Chrome
Graphics team and hack all day
on the graphic stack.
They're dedicated to making
you as a developer understand
what's going on so that you can
make sure that your apps are
fast, fluid, and awesome and
then simultaneously dedicated
to improving that platform
so that you don't have
to work so hard to do that,
and you just get it for free.
I'm really excited, and
please put your hands together
for Nat and Tom.
[APPLAUSE]
TOM WILTZIUS: Hello, everyone.
My name's Tom
Wiltzius, as Paul said.
NAT DUCA: I'm Nat Duca.
Nice to see everybody here.
TOM WILTZIUS: Yeah.
And we're from the
Chrome Graphics team.
I'm going to use the laptop
instead of the clicker
so we can play videos.
We're here today to talk
about rendering performance.
And we want to start
off with a few basics
that we're not going to
cover in much detail,
because there is a ton of great
content available on the web
about this stuff already.
We've talked about it before.
Other folks on our
Developer Relations team
have talked about it before.
But we want to make sure
we're all on the same page.
NAT DUCA: So the pages
that we want you to be on
are the following, right?
You got the screens
here, lots of them.
They're all running at about
60 hertz, but maybe not.
16 milliseconds is a number that
you want to keep in your mind.
We heard [? Elia ?] talking
about numbers much bigger
than 16 milliseconds, so this
is a much smaller time frame.
But it's super, super important
that if you want to be smooth,
you've got to hit that budget.
TOM WILTZIUS: That's right.
And there's a lot
of stuff that needs
to go into that 16 milliseconds.
The rendering system's
really complicated.
We're going to walk through the
various stages in the rendering
pipeline in this talk.
But it's challenging
to fit everything
into 16 milliseconds.
And this means that
you should be working
with the browser
whenever possible.
This means using things
like requestAnimationFrame
rather than a timer
to run animations.
This means using things like
CSS animations, when possible,
rather than doing everything
yourself in JavaScript.
And yeah, just
trying to play nice.
NAT DUCA: Please be nice.
TOM WILTZIUS: There's
more content available
at those links.
NAT DUCA: Yeah.
So we all know, and we've
known for many years,
that if you have good
load times for your pages,
your user engagement will
be much better than if you
have bad load times.
There's another part
of this business
that we don't talk
about but that's
obvious to mobile developers,
which is your responsiveness,
right?
We've got two videos
here going that are
a good responsive page that is
smooth, and one that's janky.
You've got to think of
this as a first order
part of your business
as creating a web app.
I think most of you know this.
But it's really worth hammering
that home up to the bosses
that this is something
you don't fix at the end,
you think about
throughout the life cycle
of whatever it is
that you're building.
TOM WILTZIUS: That's right.
And especially, we're going to
talk a lot today about things
that impact mobile
devices more than they
impact, say, this laptop.
And this kind of
difference, this difference
in responsiveness,
the difference
comes out much more on
said mobile devices, right?
This is one of the
key distinctions
between native
application development
platforms on Android or
iOS and the mobile web
is that things feel webby when
they lag, when they're slow,
when they're jittery.
And your users are going to
notice the difference, even
if they're not conscious of it.
It doesn't feel as nice.
It's one of the tells, so
to speak, of a web app.
And that's unfortunate, and
that's what we want to avoid.
NAT DUCA: So we've been nice.
And now let's talk tech.
TOM WILTZIUS: That's right.
So if any of you have
seen us talk before,
we're going to go
through some content that
should be fairly familiar about
how the painting system works,
how the compositing
system works.
And then we're going to
talk about some stuff
that we haven't
talked about before.
So with that in mind, we're
going to kind of fast,
but bear with us.
If you think about
how pixels get
on the screen of,
say, a mobile phone,
there's a whole slew of
stuff that needs to happen.
From the perspective
of JavaScript,
it's all of this stuff.
NAT DUCA: Yeah.
So this sort of thing makes
the actual Chrome engineers
try to kill themselves,
because it's all a lie.
But from the point of
view of the web developer,
there are these
various pipeline stages
that your content goes through.
You start off with
your JS and your DOM.
It has to be styled.
That has sort of two big
steps-- layout and recalc style.
The first part is where you're
taking all your CSS selectors
and figuring out
which apply to what.
Second part is figuring out
where things are positionally.
Eventually you've got
all that stuff done.
You're still not done.
You've got to basically take
all of that computed stuff
and turn it in to actual pixels,
RGB values, in memory somewhere
or on a GPU.
And we do that in
two parts right now.
First we paint, which is
where we take all of the lines
and we rasterize them.
And the second part is we take
all those textures that we made
and we smash them
together on the screen
using the compositor.
And that's the stage where
you hear layers come about.
TOM WILTZIUS: That's right.
And so you can actually see this
pipeline in action in DevTools.
We really, really like
the DevTools timeline view
because it not only shows you
each of these pipeline stages
happening, but it also shows
you how long each stage took.
Which means that you have some
sense of where the time may
be eaten up if you have some
janky interaction on your page.
And usually the
first thing I do when
I'm trying to debug some
slow site for whatever reason
is I open it up and I take a
timeline recording of whatever
it was that was slow.
And I start to get some sense
of the breakdown of where
that time is going and what it
is that's causing a lot of time
to be eaten.
NAT DUCA: This is your
first line of defense,
really, when it comes
to jank busting.
TOM WILTZIUS: That's right.
And if you think
about what properties
you can animate in CSS, you
know CSS will let you animate
whatever you want, right?
But it's important to realize
that not all of these things
are created equal.
If you change something like the
opacity value on some element,
then all we need to do behind
the scenes is recomposite.
Turns out compositing
is fairly cheap.
We can do it on the GPU.
And we can composite
every frame, no problem.
In fact, Chrome needs to
composite every frame just
to make a new screen image.
But then you compare that to
something like width or top.
And all of a sudden, you modify
the width property and maybe
some text [? tree ?] flows.
We need to do a
lot of re-layout.
And everything that
got re-layed out,
and maybe more stuff around
it, needs to be repainted.
And then everything
that got repainted
needs to be recomposited.
And all of a sudden,
this whole pipeline
is kind of in action,
which is very difficult
to fit in 16 milliseconds.
NAT DUCA: You're now
in danger territory.
The more left you
go in this pipeline,
the more you're risking jank.
TOM WILTZIUS: Yeah.
But it's not just the
more left, there's
kind of a big cliff
right about there.
One of these things is
not like the others.
Painting is really slow.
NAT DUCA: It's
like, really slow.
And we wanted to
share some numbers.
TOM WILTZIUS: Right.
So this is data from
Chrome Perf, which
is the dashboard that was
mentioned earlier this morning.
We have a rasterization
time metric.
And if you look at
a Nexus 10 and you
take a site like the
"New York Times,"
takes 10 milliseconds
to raster just
the content that's
currently visible, say,
during the page load.
NAT DUCA: So that's better.
I mean 10 is not--
OK, sure, fine.
Like, eh, why are
you on about this?
TOM WILTZIUS: Because then you
go to a site like The Verge,
and all of a sudden, it takes
107 milliseconds to raster.
NAT DUCA: This is not fast.
TOM WILTZIUS: Right.
And then you go
to Cute Overload,
and it takes 214 milliseconds
to raster, right?
NAT DUCA: Which is a
lovely site, right?
TOM WILTZIUS: Right.
I'm not pooh-poohing
any of these sites.
I'm just saying, there
is an incredible amount
of unpredictability in how
long things take to paint.
And if you think about this
in terms of frames, which
is kind of a good
logical unit to consider,
then all of a
sudden, you can see
that 214 milliseconds,
that's 13 frames at 16
milliseconds a frame.
That means that you
end up in this position
where if you really
want to be repainting
all that content every frame,
there's just no way, right?
NAT DUCA: Seconds per frame.
TOM WILTZIUS: This means
that your frames per second
goes way, way, way down.
You're nowhere near 60.
NAT DUCA: Four.
Is that smooth?
TOM WILTZIUS: Right.
And this is exacerbated
when, as I kind of alluded
on the last slide, you end
up in this position where
you need to paint things
on a per frame basis.
So we call this a paint storm.
If you go into DevTools and you
turn on Show Paint Rectangles,
you'll get a red flash on
the part of the screen that
repaints every time it repaints.
This is cool because it means
that you can see that during
this interaction-- this is Nat's
fat finger moving up and down
on--
NAT DUCA: It's a fine
finger, isn't it?
TOM WILTZIUS: --a demo he made.
You can see that there are
key points in that interaction
where, all of a sudden, there
are these red flashes that
show up and cover the screen.
And this is really bad, right?
Because that means that every
time one of those red flashes
shows up, then we're paying a
lot of this significant paint
cost, right?
And if you were to show sort
of like a timeline view of this
in Developer Tools, you'd
be able to see exactly how
long each of those
paints were taking.
NAT DUCA: Yeah.
And we see a lot of sites
that basically get pretty far
along in their lifetime before
they even look at paint rects.
And at that point, you've added
so much complexity to your DOM.
You've got 73 different
things all going on.
You no longer know
which is the one that's
causing the storm,
what's going wrong.
And so you want to
keep your eye out
for this from the
beginning of your content
through its lifetime in
order to defend against this.
Now the defense.
You know, the first line
of defense in this space
is layers, right?
We've alluded to it.
We've talked a lot
about it on Jank Free.
You can look at that demo and
think about it in your head
and go, well, yeah.
They're these pieces, and
they're just moving around.
So what we can do to
make this smoother
is keep each one
of those in a layer
and add them all together.
And if you sort of think about,
then, the movement from frame
to frame to frame is us just
moving these layers around
on the screen, no
repainting is necessary.
So that means we
don't have to get
those left parts of the
pipeline running that are slow,
the purples and the greens.
And so in theory, this
is smoother, right?
And so this is
just the same thing
but redone to be no
repaints, or very few.
And so it's a lot smoother.
TOM WILTZIUS: Yeah.
And actually, you can
see-- it's probably
pretty small on
the screen, but you
can see that there are some
red flashes still happening
along the far right side of
the mobile device screen.
That's just us repainting
the scroll bar, which we do
[INAUDIBLE].
NAT DUCA: Scroll bars.
We haven't optimized them.
They're small.
TOM WILTZIUS: But you can
see that other than that,
there are no red flashes.
NAT DUCA: So that's better.
TOM WILTZIUS: This is good.
The point here is
that you want to try
to decompose the
structure of your page
into logical units that
map well to layers.
And these logical units should
be things that move together,
that fade together, or that,
maybe, stretch together.
These are things that
are easy to express
in terms of the
layering triggers
that we have on the
web platform today.
NAT DUCA: We should make
a postcard that says that.
Like move together,
stretch together.
TOM WILTZIUS: And basically,
this maps to the set
of things--
NAT DUCA: Anybody?
TOM WILTZIUS: This
maps to the set
of things that GPUs are good at.
Like GPUs are OK at the
kind of rasterization
that Nat was talking
about earlier.
But they're really good at
these bulk pixel operations.
NAT DUCA: Yeah.
So think in terms of layers.
It's really, really that
key building block right now
for getting speed on mobile.
But that having been said--
TOM WILTZIUS: Great, right?
What sucks about this?
NAT DUCA: The fine print.
TOM WILTZIUS: Lots of
things suck about this.
We try to make
layers automatically,
but we can't always do it.
Like one of the common questions
we get is always, OK, so great,
I see how you guys
are explaining
the rendering system working.
Why can't the browser do
all of this on my behalf?
And believe me, we are trying.
But there are some
fundamental limitations
that we more or
less can't get over.
The most mundane of these, in
my mind, is text antialiasing.
You'll drop from subpixel, like
LCD screen text antialiasing,
to grayscale text antialiasing.
NAT DUCA: This is
like ClearType.
TOM WILTZIUS: Yeah.
If you're on a
composited layer that
doesn't have a solid
color background.
So if you're concerned
about text quality
and you maybe manually
promoted something to a layer,
try to make it a
solid color background
and you won't have that problem.
This is the same reason that
we have different criteria
for automatically promoting
certain content to layers
on high DPI versus
low DPI devices
and on Android versus desktop.
So you need to be testing
all of these places.
This sucks--
NAT DUCA: This is the
reality that we live in.
TOM WILTZIUS: --but there's
not a lot we can do about it.
NAT DUCA: There are
other things, too.
So for example,
position sticky is
one of the looks du jour, right?
And understandably so.
When you try to
emulate that, a lot
of the times what you
end up having is you
have a div that you're
moving up and down.
And inside it, you want
a position fixed child
of that div that's
your sticky element.
Unfortunately, when you
put translateZ(0) on that,
that redefines at
the spec level what
the position fixed
is relative to.
If you go and do a little
JS fiddle on your own,
you'll find that position
fixed on something
that is a layer
through translateZ(0)
is relative to the actual layer.
So then you can't do
sticky, because you
want sticky to stick
to the viewport.
If you use this nasty
little dirty trick,
you might have more headway.
And we're going to leave
it at that, because this
is unblessed, but the reality
of the world we live in.
And this is, in fact,
the reality, right?
TOM WILTZIUS: This
is the web, right?
NAT DUCA: And here's another
little unfortunate reality.
Web pages are tall, right?
You've got lots
of things in them.
10,000, 20,000 pixels
tall is not unusual.
Chrome's rendering
system uses layers
in order to warm things up.
So we are looking at
all layers assuming
that they might come on
the screen imminently.
Has anybody ever done
a trick in their app
where they put something
at negative 10,000 pixels
and then they fly it
in with an animation?
Right?
It looks really pretty.
But the problem with
that is we, Chrome,
have no idea if something
is negative 10,000 pixels
from the viewport and can't
become visible next frame,
versus it's negative
10,000 pixels
and the user can't get there.
So this is a thing where we
don't have that understanding.
So if you hide stuff that the
user can't get to any time
soon, that gives
us less work to do.
We use less CPU, and
you're less janky.
TOM WILTZIUS: Yeah.
And that's--
NAT DUCA: That's a good thing.
TOM WILTZIUS: --all really good.
OK.
This is a lot of content
that we just blew through.
And we didn't do any kind
of live demos the way
we usually do.
But I want to break this down
into simple takeaway messages,
which is that, you want to be
looking for these paint storms.
You can find them
with DevTools and
the showPaintRects function.
If you find these
paint storms, you
want to try to avoid them
through implicit or explicit
layer creation, if
at all possible.
You can see the layer
borders really nicely
if you go into DevTools and
turn on Show Composited Layer
Borders.
This is a very nice
visual aid to help you
with this sort of layer
decomposition process.
And if you're doing
everything right
and you're still finding that
you have these paint storms
and you just can't figure out
why it's repainting, because it
doesn't seem like anything
needs to, you may be right.
NAT DUCA: Chrome isn't perfect.
We've spent a lot of time
making this just work.
There are cases where
Chrome's tiny little brain,
or Blink's tiny little
brain, gets confused,
and it repaints the universe.
If you're hitting that,
try to reduce it down,
pare it down, and email
Tom or I or file a bug.
We'll try to get
that sorted out.
TOM WILTZIUS: We've
been, recently,
on a spree of stamping out
what we call spurious paint
invalidations, and we
would love to have more.
NAT DUCA: Bugs welcome.
TOM WILTZIUS: That's right.
OK, so that's
rendering performance
from the perspective
of JavaScript, right?
But if what we really
want to talk about
is responsiveness on
a touch based device,
like a mobile phone,
there's another component
to the entire story
that we haven't really
talked about yet.
And that's the input, right?
Particularly on a
touch device, latency
can be absolutely killer.
And Nat's going to walk through
a couple examples of that.
NAT DUCA: We've got two videos
going here, a good and a bad,
right?
This should jump
right out at you.
If you drag something
around with your finger,
you want it to stick
to your finger.
And on the left, you've got
something that's definitely not
sticky, feels a little laggy
if you're doing this yourself.
On the right is sort of a
little closer to what you want.
And ideally you get even
closer, as much as you can.
Now getting there
on the web, that's
the leading edge of innovation
for both Chrome and really
everyone.
This is a hard problem.
But we'd like to share what
we know about it today.
TOM WILTZIUS: Right,
and a little bit
about what we've been doing.
So if you're trying to get the
page to stick to your finger,
or say, maybe you
have a slider widget
and you really want
the slider widget
to stay under your finger when
you slide the widget around,
then you've kind
of got two options.
Option A is you
get lucky and you
happen to have an effect
that can be expressed
in terms of the
fast scroll path.
If you're on this
fast scroll path
and the browser is sort of
doing the scrolling for you,
then you just happen to get
all of the best possible touch
input latency.
Because we built
that part, and we
tried to make it as
good as possible.
NAT DUCA: But the
option B happens
when you're in a
situation where you've
got to implement a
drawer or a slider
where the actual
thing-- or a drawing
app-- the actual
thing that happens
in response to that input
is necessarily programmatic.
That is not a scroll.
You need to handle
that yourself.
There's a different set of
rules for making that fast.
TOM WILTZIUS: That's right.
So let's say you
go with option A.
NAT DUCA: Because
that's fun, right?
TOM WILTZIUS: Right.
And often, that totally works.
Depending on your
content, like scrolling,
the reason we have done all
this work about scrolling
is that scrolling
is one of the most
common operations
on the web, right?
And even on mobile devices.
So if you're going
to go this route,
you want to make sure
that the layers you expect
to have gotten created
were, in fact, created.
And that they're
working as intended.
So this means that whatever
the kind of content area that
is scrolling should
be in its own layer.
And when it scrolls,
you shouldn't
see it all repainting, right?
And again, the same couple
of basic DevTools features
will let you very
easily visualize
this, along with timeline.
NAT DUCA: We're just
hitting this point again,
which is layers are
good, but they're
very hard to persuade to exist.
And so you have to be
constant vigilance here
in order to catch
that fast path.
TOM WILTZIUS: Exactly.
And a lot of that
vigilance comes down
to testing the right places.
So it is very tempting
as a developer
to do everything on
your laptop, right?
Or on your work station.
But the unfortunate reality
is it's basically impossible
to emulate the performance
characteristics of an Android
device on, say,
this nice laptop.
That's not just to do with CPU
versus GPU speed, et cetera.
But it has a lot
to do with the fact
that Chrome actually will behave
slightly differently on Android
than it does on desktop.
The DPI matters.
And all of this is subtle,
and that's unfortunate,
but the reality is building
high performance rendering
systems is complicated.
And you need to test
on the target devices.
NAT DUCA: So if you
do hit the fast path,
you're in a good position.
We're doing a lot of work to
make that feel less laggy.
Chrome has been particularly
kind of not good at that.
Notice I didn't say bad.
TOM WILTZIUS: And it's
gotten a lot better.
NAT DUCA: We're working
hard to make that better.
But that is the case
for native scrolling.
TOM WILTZIUS: Right.
So what about option B?
NAT DUCA: So OK,
I'm going to attempt
to do a little bit
of footwork here
to try to say how you
can make this work.
This is really bleeding edge.
If you want to do something with
a touch listener and be smooth,
you have to do these
two things-- you
got to keep all of your
costs, all of them,
to less than seven
milliseconds, and you
have to avoid foot guns.
Push stack on the foot guns and
talk about why I said seven.
TOM WILTZIUS: Yeah, why not 16?
NAT DUCA: Because I
felt like it, really.
OK, we have Chrome running
and then we have your code.
And we're sort of
sharing that system.
In order to get zero
latency, we have
to run your stuff,
then our stuff, all
in that 16 millisecond budget.
And oh, by the way,
the operating system
also is there doing stuff.
TOM WILTZIUS: And this
is the kind of thing
that you don't generally
worry about on, say, a laptop,
because there's enough
performance overhead that you
don't really worry
about what Windows
is doing in the background.
But in fact, on most
modern mobile phones,
even, they're so
resource constrained
that, actually, some system
thing coming in and running
can deschedule all of
the browser's threads,
and then that crap.
NAT DUCA: So seven.
Keep that in mind.
Keep your stuff.
So this essentially means
don't paint at the moment.
Don't paint.
Don't do heavy JS.
Do as minimal JS as you can.
If you've got a
layout, be very careful
and avoid recalc style
if at all possible.
OK, foot guns.
So this is another one of
those laundry slides of,
like, there's that
nice theoretical world
that we talk about.
TOM WILTZIUS: And then
here's all the caveats.
The first one is
probably the craziest.
If you want to do
this, if you want
to handle touch events
yourself in JavaScript,
that means you need touch
event listeners, right?
If you're going to have
touch event listeners,
be judicious about when
and where you install them.
Particularly, be wary of
installing touch listeners
during the page
load, or you will
risk scrolling jank and
unpredictable delivery
of those touch events.
NAT DUCA: So we're simplifying
a very complex message
with this general rule.
And we'll come back to it
later about the details of it.
But just keep this in mind.
Big listeners, touch
listeners, in general,
have a lot of scary.
TOM WILTZIUS: Yeah.
Touchends.
I'm going to let you explain
because this is complicated,
too.
NAT DUCA: You want me
to talk about touchends?
This is also complicated.
So if you drag your
finger off a screen,
do you get a touchend
or a touchcancel?
TOM WILTZIUS: What?
NAT DUCA: Yeah.
So there's this
common set of problems
where people forget to
listen to touchcancel,
and so they get basically really
weird behavior in the field.
And they can't figure
out what's going on.
They forgot to listen
to touchcancel.
It's a minor point,
but very important
because people will say
that you're being janked.
And the reality is you just
forgot to get that one event.
We're so trained to think, mouse
down, mouse move, mouse up.
All of us grew up like that, so
this is a bit of an adaptation.
TOM WILTZIUS: Yeah.
The 300 millisecond
tap delay has
been mentioned in other talks
and will be pounded on more.
This is to disambiguate between
double tap to zoom and a click.
And yes, this is crappy.
And yes, the
browser tries to not
wait if it can determine
it's impossible to zoom.
NAT DUCA: Set your
viewport tag correctly
if you don't care
about [? the page. ?]
TOM WILTZIUS: Yeah,
just be careful.
There's a lot of good content
online about this one,
so we won't talk
about it too much.
And lastly, mouse wheels.
Mouse wheels,
obviously not so much
relevant on mobile, more
relevant on desktop platforms.
But mouse wheel listeners have
a lot of the same problems
that touch listeners do.
So lest you think that this
is sort of limited to touch.
In fact, you can shoot yourself
in the foot with mouse wheel
listeners, too.
NAT DUCA: And there's
some major websites
that actually have
touch listeners.
And so they technically could
hit all these fast paths
we've been talking
about about latency,
except they have a
mouse wheel listener.
They don't do anything
[INAUDIBLE], ironically.
TOM WILTZIUS: Nope.
Except blog about
how slow Chrome is.
NAT DUCA: But they've shot
themselves in the foot,
and there's nothing
we can do about.
TOM WILTZIUS: This is
all specced or de facto
standard behavior, which
means that this is not
going to change.
NAT DUCA: It's a
wild world out there.
TOM WILTZIUS: It is.
NAT DUCA: Yeah.
So remember we started off
with a video of a janky finger
moving this thing around.
So imagine your
PM is like, hey, I
want you to make that logo thing
draggable because I'm your boss
and I'm going to make you do it.
So you're a good [? dooby ?]
and you go code it up, right?
You document .addEventListener
and touchbegin
and addEventListener touchmove.
And you're like, look, it works.
It's awesome.
And then you get these
reports from the field
and they're like, yo,
this is really janky.
Like, I can't use my page.
I love that thing, but like,
you destroyed your page.
You go to these
options in DevTools
and you show scroll bottlenecks.
This is what you'll see on the
left with a global document
listener.
What's happened is
you've told Chrome
that your JavaScript wishes
to preempt any input received
by the user right into
JavaScript all the time.
We cannot think about doing
anything with your input,
do any sort of fanciness
that we can do,
until you say yes or no.
Specifically you
say prevent default
or fail to prevent
default that event.
And so if you're going
to listen to touch,
you need to do it on the most
specific thing you can do.
And because of this whole
prevent defaulting thing,
remember the thing we
pushed onto the stack
earlier about that mysterious
don't add touch before load?
It's the same thing.
If you have an input handler
and you've told Chrome
that, then any time you touch
the thing that has the handler,
you get automatic preempt
over anything we can do.
Which means that if the
browser is busy doing something
like recalc style, we can't
do anything in response
to user input.
And so you get a jank.
TOM WILTZIUS: That means we
can't scroll until your touch
listener runs or we
timeout and we give up.
NAT DUCA: So be
very, very careful
about when and where you
install these listeners.
TOM WILTZIUS: Yeah.
Not good.
OK, we've only got
five minutes left,
and we want to talk through
a little bit of where we've
come from in terms of
the Chrome rendering
stack and more importantly,
where we're going.
If you've seen us
give talks before,
you've probably heard
us kind of caveat
some of the differences
between desktop platforms
and Android, et cetera.
And there are still differences,
as we mentioned before.
But these days, that's
more about the actual power
of the device and less about
the rendering architecture.
This is really good
because it makes
your lives easier as developers.
It makes our lives
easier building Chrome.
And the pace of that catch
up of other platforms
has accelerated in
the last year or so.
NAT DUCA: But we have a lot
of really fancy technology
that enables us to run
smoothly on Android.
And it's unevenly
deployed right now.
It's a lot better in Chrome 32.
Hugely better, but
it's still not there.
So this is why we continue
to recommend testing
on all the platforms you intend
to support, at least for now.
At least in terms
of jank, because
of these nonuniformities.
It's the world we live in.
TOM WILTZIUS: Yeah.
The Android WebView,
though, is new
and is further bringing
everything in line.
NAT DUCA: We wish, though,
to share some things with you
because it's not
also caveat free.
TOM WILTZIUS: List
of caveats, right.
NAT DUCA: Sorry.
There is a rich tradition
on the Android WebView
to disable hardware
acceleration.
There were good reasons for
this in Android WebView.
There still are
some good reasons
to do this with the
Chrome-based WebView
but fewer and different.
We're not going to explain
that sort of curvature space
directly, but the
thing is, please,
if you were, in the past,
disabling acceleration
on your WebView, please
revisit that decision.
Check your content
out in Chrome WebView.
See if it's better.
If it is, Chrome will
reward you in scores.
The hardware-based rendering
is really, really good
compared to the software one.
TOM WILTZIUS: Another
important caveat, there
are differences
between Chrome itself
on Android and the WebView.
One of the most significant
is that the DOM size
matters a lot more.
Chrome tries to be smart
about culling stuff
that's way away
from the viewport.
But this gets a lot easier
if the developer just
says, no, this is
right out invisible.
This is particularly
relevant to the WebView
because part of the
WebView API contract
is you can ask for
the whole document.
Which means that
every time we go
to record things
to paint later, we
have to record the
entire document.
We can't do any of the
smartness around culling
that we're trying to do.
This means that we
incur a lot more memory,
and so you need to be
careful about this.
So you want to try to
do your own viewporting,
if at all possible.
NAT DUCA: Yeah.
And this is just
that basic thing.
Maybe someday
we'll revisit that,
but please keep it in mind.
And just sort of a
more broad thing,
jank busting in a WebView
Android sort of combined app
means keeping the UI thread
free for both components.
They're sharing the same thread.
You've got great tooling to
show which one's eating time,
but you got to keep
an eye on both.
There's nothing that we've
got that protects you
against janking each other.
TOM WILTZIUS: That's right.
So where are we going next?
There are these fast paths, but
it's hard to get on to them,
and it's easy to
fall off of them.
We think this sucks just
as much as you guys do.
And we want to make it
better through a combination
of improving Chrome and
improving Chrome's tooling.
So about tooling--
NAT DUCA: Yeah.
I mean, so you've seen
a couple little pictures
like this where we tilt
the web page to the side.
We think that these
things, these questions,
need to be easily and without
a lot of thought answerable
for you all to be
more productive.
It should be possible
to see the layers.
It should be possible to see why
something became a layer, why
something didn't become a layer.
You should see your
scroll bottlenecks.
None of this should be
so hard as it is now.
And it certainly shouldn't
be a soup of check boxes.
This is coming.
TOM WILTZIUS: It's difficult
to visually inspect this.
So we need Richard [INAUDIBLE].
NAT DUCA: Mr. Paul
Irish is going
to be talking about this
in more detail tomorrow.
TOM WILTZIUS: That's right.
Meanwhile, there's a lot that
we can do behind the scenes
to keep making Chrome faster.
And there's a lot of
people working on this.
We're trying to fix a
lot of the issues that
make the slow stages in
the pipeline so slow.
So if you can't just
express yourself
in terms of
compositing operations,
there are some basic
changes to layout
that actually should
be very cheap, right?
Why can't you move something
around with [? top ?]
if it's absolutely
positioned and doesn't
affect anything else?
In theory, this should work.
But Blink is just
not that smart.
And so we're trying to
sort of improve that.
And there's a slew of
things along those lines
that are just under optimized.
NAT DUCA: And so we're going
to start thinking about.
But in parallel with
that, we're also
starting to get out
of the monofocus
that we've had for
the last two years
to try to just survive
the transition to mobile.
We've been just trying to
scroll a web page basically,
and that was hard.
Surprisingly hard.
We are now getting
to a point where
we can contemplate what should
the mobile web really be
from a jank perspective.
How do you all want to express
your intent to the browser
so that we do the right
thing from the beginning?
We put up a list of
intentionally provocative ideas
here, just to whet
your appetite.
If anybody has other
ideas, if you've
got strong opinions about
one of these, if one of these
makes you want to
storm out of the room,
stay and storm out of the
room after you tell me
why you hated it.
TOM WILTZIUS: Yeah.
We'd love to talk about this.
NAT DUCA: But we want
to make this better.
And the reason is, we know
that it's not good enough.
And we know that,
now that we've got
scrolling sort of
figured out, we
need to go and make
the tools better,
we need to make this
more accessible, we need
to make just jank on the web
sort of a solved you don't
think about it problem.
TOM WILTZIUS: That's right.
So with that, we're
going to wrap up.
Thank you very much for
your time and attention.
I'm Tom, and this is Nat.
And thanks again.
NAT DUCA: Cheers.
[APPLAUSE]
