►
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
Right
so
Hello
friends,
I'm
Michael
from
Google
I'll
talk
to
them,
paint
climbing,
potentially
exposing
more
paint
timings.
Quick
summary
of
the
problem.
There
are
several
specs
that
expose
some
concept
of
paint.
Timing,
also
known
as
render
time
good
segue
from
the
stack,
and
there
are
I
think
several
reasonable
interpretations
of
when
to
mark
this
timing,
I
think
it's
a
bit
underspecified
and
we
already
have
interrupt
differences
across
implementers
now.
A
So
we
wanted
to
discuss
some
of
the
motivations
there
and
the
goal
for
today
I
have
no
specific
proposal
that
I'm
making
it's
just
wanted
to
drive
towards
Clarity.
In
particular,
this
issue
has
come
up
over
and
over
I
think
there's
terms
that
get
mixed
up
and
Sean's
been
working
on
lcpl
or
Amazon.
Some
of
these
questions
have
been
very
recently
brought
up
again,
so
we're
trying
to
I'm
trying
to
hope
to
drive
towards
consistency
in
terms
and
understand
it.
A
Okay,
so
paint
timing,
attempts
to
Mark
the
point
in
time
when
the
browser
renders
a
given
document.
Now
those
terms
are
kind
of
loose
interpreted
by
us.
Of
course,
we
have
Mark
paint
timing
at
a
very
specific
step
in
the
HTML
update,
rendering
this
is
exposed
through
the
starting
value,
which
is
time.
Origin
and
duration
is
always
zero
on
the.
A
A
Element
timing
is
the
same
as
LCP,
because
it's
built
on
top
of
that.
The
one
thing
I
wanted
to
call
out
is
LCP
is
implicitly
document
timeline,
starting
at
time
margin,
but
individual
elements
have
implicitly
non-zero
time
margin,
or
at
least
they
could.
So
you
might
use
resource
time
and
start
time,
but
when
the
resource
began
fetching
you
might
use
the
the
moment
in
time
that
you
added
a
resource
to
the
down
if
you're
tracking
it
yourself.
So
there
are,
you
know
and
finally,
there's
event
typing
so
event.
A
Timing
exposed
to
the
start
time
of
the
event
is
timestamp,
as
well
as
the
duration,
the
total
time
it
takes
to
render
that
event.
But
the
start
time
plus
the
duration
is
effectively
a
vector
time,
which
was
a
few
more
time
points
and
we
and
we
modified
HTML
in
different
way
to
expose
those
values.
A
Okay,
so
thanks
for
help
issues
aside,
there's
some
automations
there.
So
I
wanted
to
start
with
a
quick
example
showcasing
where
it
can
be
confusing.
That
is
how
do
you
do
Peak
timing
and
image
decode,
so
the
task
is
to
load
an
image
decode.
That
image
render
that
image.
I
built
a
test
page
and
I,
used
three
different
strategies,
so
you
can
create
an
image,
make
sure
it's
loaded
and
use
the
decoding
equals
sync
attribute.
A
We
can
use
decoding
equals
async
or
you
can
explicitly
call
T
code
and
wait
for
D
code
to
complete
before
you
attach
it
to
that.
Okay
and
I
just
have
CP
for
testing
since
it's
widely
supported,
so
the
easiest
of
those
is
the
last
one.
So
in
the
last
case,
you
wait
for
the
image
to
load.
Wait
for
the
image
to
decode,
attach
it
to
Dom,
wait
for
rendering
and
access
Stitch.
A
A
A
If
you
set
the
attribute
decoding
as
async
whatever
bins
is
that
the
image
will
be
loaded,
you
attach
it
to
the
dong
immediately
and
we
will
proceed
with
render
and
presenting
the
frames
not
waiting
for
that
decode
to
complete
on
all
of
the
browsers.
That
means
that
you
will
see
a
visual
update
to
the
page
without
seeing
the
image
decoded
if
decode
takes
a
long
time,
and
it
can
take
a
long
time
to
decode
the
image
so
decode
async
does
not
speed
up
decoding
it.
Doesn't
it's
not
a
performance
Improvement?
A
So,
in
this
case,
it
actually
gets
labeled
very
similarly,
but
it
ends
up
being
kind
of
decoupled
from
when
the
image
becomes
physically
available.
As
far
as
I'm
aware
on
all
of
the
collectors,
there
are
some
open
issues
to
solve
this
problem
to
actually
track
the
time
it
takes
to
decode
basic
images.
A
In
the
last
case
is
the
most
common
case
of
which
is
decoding
sync.
This
is
not
the
default.
The
default
is
Auto
and
there
are
some
differences
as
far
as
I'm
aware
on
Firefox,
the
default
is
async,
but
if
you
explicitly
ask
for
decoding
to
resync
it's
kind
of
a
swapped
from
the
first
example
I
should
so
you
load
the
image
you
wait
for
it,
you
ask
for
the
you
have
attach
it
to
the
Dom.
You
wait
for
rendering
to
happen.
A
A
So
these
are
the
time
points
as
far
as
I'm
aware
that
I
figured
out
Safari's
a
bit
different
and
it
might
actually
be
similar
to
Firefox,
because
to
the
best
of
my
ability
in
testing,
there
are
two
different
rendering
tasks
that
will
happen
with
an
async
decode,
the
initial
rendering
task
that
discovers
the
need
to
paint
an
image,
we'll
kick
off
some
decode
work
and
then
a
future
rendering
task
once
that
P
code
is
complete,
we'll
actually
try
to
render
the
image
okay.
A
So
there
are
two
rendering
tasks
or
two
paint
opportunities
that
are
co-involved
in
a
sync
decode
code
opportunity.
So
there's
Mark
paint
timing,
but
witch
paint
as
far
as
I'm
aware,
it
might
even
depend
on
conditions
of
a
pitch.
I
had
seen
some
evidence
to
suggest
that
Safari
uses
the
second
rendering
opportunity,
but
then
also
saw
lots
of
evidence
that
use
the
first
I
believe
Firefox
also
uses
the
earlier
type.
A
A
A
This
has
been
noticed
by
others
from
Catholic
wrote
a
really
nice
blog
post
a
while
back
talking
about
why
first
content
propane
it
doesn't
work
as
a
cross
browser
metric,
and
you
pointed
on
some
time,
differences
between
if
you
use
film
strips
to
analyze
and
use
the
metrics
that
are
shared,
how
there
are
differences.
A
One
thing
I'll
point
out
is
that
the
difference
on
Firefox
between
the
FCP
reported
times
is
pretty
small,
but
I
think
that's
a
side
effect
of
the
fact
that
there's
default
async
code,
and
so
the
FCP
values
here
I
believe
so
the
best
of
my
ability
were
for
other
content
on
the
page
image.
The
image
was
more
similar
to
Safari
that
it
took
much
longer
where
safaris
default
sync.
A
Does
that
make
sense?
Okay,
so
why?
Why
is
this
so
difficult?
Why
are
these
values
so
different?
Well,
according
to
spec,
plus
all
of
the
patching
that
we
do
in
the
spec
there's
this
linear
process
for
how
to
do
rendering
and
where
to
Mark
paint
timing,
it
should
be
pretty
obvious,
but
that
step
16
is
pretty
big,
pretty
loaded
and
pretty
underspecified
in
general
of
how
we
could
record
and
in
reality
this
is
what
running
direct
looks
like
this
is
the
architecture
for
chromium,
rendering
and
G
architecture.
A
A
Chris
Harrison
wrote
up
a
really
nice
summary
about
how
to
interpret
the
event
Loop
steps
and
especially
the
update,
the
rendering
steps
and
how
the
implications
are
that
it
must
happen
in
series,
but
that
there
are
certain
implicit
assumptions
that
allow
you
to
make
running
many
of
those
steps
in
parallel.
A
One
of
those
is
the
principle
of
script
observability,
but
I
think
the
performance
timeline
is
in
violation
of
this
principle
right
now.
That
makes
sense
anyway.
This
is
just
another
record
and
there
was
some
discussion
about
like.
Could
this
be
solved
differently?
Apparently,
the
original
paint
timing,
implementation
in
Safari
did
expose
something
more
akin
to
what
chromium
is
doing,
but
because
of
this
spec
problem
of
not
being
specified,
it
was
changed,
so
it
is
possible
if
we,
if
we
okay,
so
image
decode
is
I.
A
Think
a
lot
of
us
were
bitten
by
those
differences,
and
so
I
wanted
to
talk
about
that.
But
it
goes
beyond
image.
We
could
I,
myself
have
been
focusing
on
event
timing
through
our
efforts
to
on
interactions,
next
painting
and
working
on
responsiveness,
the
goal
for
events
and
event,
timing
and
responsiveness
is
more
to
to
be
under
100
milliseconds
of
latency
for
interactions,
and
you
should
never
be
above
200
milliseconds.
A
What
that
means
is
it's
a
much
tighter
timeline
as
relative
to
something
like
first
Contact
full
paint
where
you
have
much
more
time
to
get
those
renders
so
the
small
differences
of
what's
measured,
make
a
bigger
impact
and
when
looking
at
what
effects
like
performance
that
falls
for
about
timing,
what
actually
affects
long
events
for
responsiveness?
A
A
A
Even
once
you
start
a
rendering
task
on
the
browser,
there
are
things
you
can
do
to
make.
That
task
take
a
very
long
time
on
Main
thread.block,
even
before
starting
actual
rendering
work,
then
there's
the
time
it
takes
to
do
rendering
work
and,
finally,
the
how
long
it
takes
to
protect
a
frame
which
might
include
things
like
image,
decode,
but
other
rasterization
tasks
and
animations
Etc.
A
The
source
of
problems
so
breaking
down
these
time
points,
and
these
like
durations,
can
help
sort
of
narrow
down
Focus
as
to
where,
where
10
best
time,
perhaps
not
all
of
these
need
to
be
exposed
to
field
data,
but
but
certainly
a
lot
of
tooling
and
the
way
we
discuss
it.
A
There
are
other
issues
with
multiple
time
points
other
than
just
describing
a
thing.
So
we've
talked
about
Progressive
images,
placeholder
images
and
exposing
multiple
time
points.
Well,
I
mean
there
are
issues
right
now
where
first
contentful
paint
can
be
reported
as
larger
than
largest
contentful
paint
with
the
LCP
element
is
not
tile,
which
should
be
impossible,
but
it's
just.
We
have
two
very
far
away
templates.
A
We
fall
back
to
the
load
time
of
the
image,
which
is
where
they
are
also
cases
where
render
time
is
very
decoupled
from
load
time,
so
you
may
load
an
image
and
that'll
wait
a
very
long
time
to
swap
it
in
and
then
because
the
towel
check
fails,
we
can't
expose
record
type
but
there,
so
we
fall
back
to
this
really
early
time
as
opposed
to
multiple
Alternatives
available.
So
there
are
other
reasons
to
consider
not
trying
to
shoehorn
many
different
possible
values
into
very
few
slots.
A
Phillip
Walton
wrote
an
excellent
article
about
how
to
optimize
imp
and
I've
tried
to
narrow
Focus
down
into
these
areas
as
to
like
things
that
tend
to
affect,
and
the
guidance
was
that
last
portion
of
the
element
render
delay
just
take
10
of
the
overall
LGB
type,
but
in
practice
even
very
good
sites,
with
very
few
render
blocking
resources,
no
long
class,
nothing
that
tended
to
be
much
larger
than
we
were
expecting.
A
Okay,
so
Mark
pink
timing
is
technically
specified,
but
not
necessarily
which
paint
is
responsible
for
doing
work.
There
are
differences,
element,
timing,
introduced
in
more
timings
and
chromium
uses.
Those
for
its
paint,
timing
and
I
think
that
there
are
many
breakouts
which
will
be
very
useful
for
developers,
especially
so
for
that
type.
But
we
were
surprised
the
fact
that
even
for
lcpas.