►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
You
might
think
it
would
be
the
layout
code,
but
it's
actually
the
paint
code,
because
we
care
about
the
visual
rect
anyway,
when
we're
done,
painting
we've
accumulated
this
list
of
rects
and
we
added
anytime,
we
noticed
an
element
had
shifted,
we
added
old
wrapped
in
its
new
rect,
so
you
can
imagine
a
page
with
a
lot
of
elements
that
could
be
a
big
list
and
so
cls
has
to
calculate
a
score,
and
the
hard
part
which
is
sort
of
algorithmically
interesting
is
to
calculate
the
area
of
the
union
of
those
rects,
which
is
this
sort
of
region
of
arbitrary
complexity,
and
our
first
attempt
was
n
squared
in
the
number
of
rect.
A
Basically,
every
time
we
add
a
new
rect,
we
had
to
compare
its
overlap
with
all
of
the
previous
rects,
and
this
showed
up
in
our
perf
alerts.
A
They
said
pages
with
lots
of
elements
moving
around
are
measurably
slower
because
of
this
we
actually
found
two
ways
this
could
be
fixed.
The
first
was
to
snap
the
region
to
a
grid.
If
you
imagine
sort
of
a
coarse
grid
with
lines
50
pixels
apart
overlaid
on
the
page,
then
align
each
rect
to
that
grid
and
sort
of
scale
them
down
before
you
calculate
the
area.
A
This
sacrifices
precision
and
potentially
introduces
a
new
way
for
browsers
to
diverge,
which
is
you
could
say
it's
an
interrupt
problem.
We
actually
put
into
the
spec
that
the
user
agent
can
make
these
kinds
of
trade-offs.
So,
in
my
view
it
would
be.
It
would
be
perfectly
okay
to
do
this
kind
of
thing,
but
we
found
a
new
way.
That's
both
fast
and
precise.
It
uses
a
data
structure
called
a
segment
tree.
A
So
imagine
your
input
rex
and
just
look
at
the
y-axis
get
all
the
end
points
where
any
rect
starts
or
ends,
and
the
segment
tree
is
like
a
balanced
binary
tree
where
the
nodes
are
the
intervals
between
those
endpoints
and
then
finally
imagine
a
sweep
line
on
the
other
axis.
So
we're
sweeping
from
left
to
right
and
at
each
x
end
point.
We
update
that
segment
free
to
reflect
which
parts
of
the
sweep
line
are
overlapping
the
region,
and
so
we
accumulate
the
area
as
we
go
so
each
step.
A
The
segment
tree
tells
us
the
total
vertical
overlap
length
and
we
multiply
by
how
far
the
sweep
line
is
moved
horizontally
since
the
last
endpoint.
So
the
time
cost
for
n
rect
is
log
n.
Every
time
we
update
the
segment
tree
and
we
update
once
for
each
endpoint,
so
n
log
n
overall
to
get
area
for
a
single
animation
frame
and
the
other
half
of
cls
is
move
distance.
But
that's
trivial
because
again
the
pain
code
notices
when
an
element
has
moved.
So
we
just
keep
track
of
the
biggest
move
that
we've
seen.
A
If
anyone
feels
like
inspecting
the
chromium
code,
the
interesting
bits
are
in
this
class
called
layout
shift
region.
I
haven't
really
studied
the
mozilla
or
webkit
rendering
architecture
lately,
but
I
would
imagine
a
similar
approach
could
be
taken
there
or
at
the
very
least
I
don't
think,
there's
anything
inherent
in
the
cls
spec
or
the
web
platform
that
makes
this
computationally
intractable.