YI XU: Hello, everyone.
My name is Yi.
I'm here to talk about
new futures in Canvas,
OffscreenCanvas.
To understand offscreenCanvas,
let me first talk about Canvas.
Canvas is a popular way of
doing all kinds of graphics
on the screen, and is an entry
point to the world of WebGL.
WebGL allows you,
the web developers,
to run their interactive 2D
and 3D graphics on Chrome
without using any
[? applied inks. ?]
However, [? all ?] Canvas
logic, rendering computations,
user interactions,
and much more are all
happening in the main thread.
When the main thread busy
with critical computations,
the Canvas becomes very
junky and slow to use.
It is a big drawback for Canvas.
How can we improve performance?
Fortunately, offscreenCanvas
is a solution.
As the name may
suggest, it allows users
to run tasks in the background.
That is, it can be
detached from DOM
and move Canvas logic and
computations to a Web Worker.
Web Worker is a web
version of thread.
So, in other words, we move
all those Canvas computations
to a different thread.
And the Canvas like this--
canvas logics and
computations-- can
be done in parallel
with computations
on the main thread.
And by moving these
computations away,
main thread will have
more room for rendering
logic and other things.
One way to create
offscreenCanvas
is by calling transfer
control to offscreen.
It mirrors the regular
Canvas to a offscreenCanvas.
So what happened in the
offscreenCanvas will
be rendered automatically to
the source Canvas, the one that
is shown on screen.
I want to highlight that
image bitmap rendering context
is also available
for offscreenCanvas.
It can be accessed
via offscreenCanvas.
getContext("bitmaprenderer"),
as shown in this slide.
We can then load
bitmap to the context
by calling transfer
from image bitmap.
Image bitmap can
be from any source,
including other Canvas, or
even other offscreenCanvas.
The advantage is that the image
bitmap, it's just a texture.
And it can be draw
without any undo latency.
Without further ado,
here is an example
of performance
differences between Canvas
and OffscreenCanvas.
In both case, the main
thread is very busy.
On the left, with
the busy main thread,
it doesn't have time to do any
computations for the Canvas.
The animation is
very junky and slow.
On the right, since the
computation for Canvas
are sent to different
thread, the busy main thread
doesn't effect Canvas
performance at all.
The animation is very smooth.
Coding offscreenCanvas
is very easy.
You can simply create
up worker.js file.
Then, you can create this
worker in your JavaScript
and start to use it.
Here, I'm showing an
example of implementation
of such a worker.
As it is a new future, you may
wonder if it is safe to use.
In fact, we're using
offscreenCanvas in production
today.
Before this talk, I looked it
into Chrome [? futures ?] test
to get some exact
data on the usage.
It is used in almost
32% of all pages loaded
by Chrome across all
channels and platforms.
80% of Chrome users
interact with a page that
contains offscreenCanvas daily.
I think most of you who
are listening to my talk
have used it today already.
It is a top 200 CSS properties
among the 3,000 properties
available.
And I hope it will get even
more popular after this talk.
Moving Canvas computations
to a different thread
is not the only advantage
of offscreenCanvas.
Even when it's running
on the main thread,
it's still faster than Canvas.
We have run a micro
benchmark on creating Canvas,
then get its context.
Performing these operations
on offscreenCanvas
is 50% faster than
performing them on a Canvas.
I'm showing one particular round
of many rounds we have done.
It has a particular advantage
on text-related operations.
It is consistently
15% to 45% faster.
Speaking of text, it
leads to our next topic,
what's new in text metrics?
We've added actualBoundingBox
measurements
in major text functions.
The actualBoundingBox
measurements--
it measures the smallest
rect that can bend the text.
It ignores the space at the
beginning and at the end.
In this example
in the slide, I'm
measuring space space
ABC space space.
The only measurement we
support before in measured text
is width, which includes
a lens of space.
And the actual BoundingBox will
only contain the size of ABC.
In fact, actual BoundingBox
left will be a negative value
due to the indentation.
I will also take
this opportunity
to share with you what we
are working on right now.
Batch drawImage-- this is
where multiple image can
be draw using a single API cut.
Recorded pictures--
this is where
you can create a
record object that
receive all the commands
from a Canvas 2D
and can be replayed
multiple times.
With these two
features, we are hoping
to get some good performance
improvement in Canvas.
There are few new
primitives, such as RoundRect
and oval primitives.
We will also improve all of
our support to text and color.
Thank you very much for
listening to my talk.
Of course, I did not
code everything I
presented today, not even half.
This was a joint effort
with all my teammates.
They are here on this slide.
I want to give a special
thanks to Fernando,
our tech lead for this project.
[MUSIC PLAYING]
