(Memo - Google I/O 2013) Web Page Design with the GPU in Mind
- Web Page Design with the GPU in Mind
---------------------------------------------------------------
chrome rasterises the entire page into a single large bitmap.
when scrolling, chrome does a series of memory copy operations,
effectively take all those lines and the bitmaps and mem-copy them
to the higher postion in the bitmap and goes back through & only software rasterise
what has not seen on the page. So, it's only updating what's new.
- animation & rasterization
High DPI = Hight amounts of work
HiDPI screens require 4x pixels!
which means 4x the amount of work to paint!
for every frame, we do memcopy, and that's not free.
- Hardware compositioning
-- using the GPU to make even faster.
-- GPU does really well in rasterization, amazingly capable
How chrome utilizes GPU to render page faster:
cpu can do a single upload to the GPU and GPU does final positioning on the screen.
->this reduces the amount of cpu needs to do.
With cpu mode, the one big bitmap was allocated to cover the entire visible region.
with GPU, divide the page into smaller tiles, each tile is cached into the gpu memory as a texture.
when scrolling down, we can get rid of mem-copy. As new content shown, render it in the cpu and upload to the gpu textures.
when scrolling up, the old tiles are still in the GPU memory; thus, no need to repaint in the cpu.
if keep scrolling down and ran out of gpu memory, recycles old tiles.
-> in idle cycle, chrome does proactively paint the area just outside the visible region.
this is gesture-aware-> sort of predicts which way to go
touching more pixels during animation coz they are in tiles now.
background is static in this example. (page with static BG and moving object)
using annotation on your css, chrome can separate elements into separate gpu layers.
(ex...moving object and static background)
- Controlling Layers with CSS
hands-free layer promotion
- canvas, video, plugins are automatically promoted to their own layers
- manually promote to layers using 3d transform == layer promotion
- CSS animations (set of css properties which push things into layers at runtime)
cssスタイルの調整でgpuのレンダリングを調整できるが、too many layersは
もちろんNG。メモリ資源は有限だし、each layer of tiles must be sorted every frame when gets drawn to decide draw/not.
- Layering and animation tradeoffs
translateZ(0)==>Layer promotion==>memory usage
this starts animation instantly but consumes more memory
when sliding some content on screen / off screen
display:none invalidates pre-painting
display:none -> display:block and start animation (triggers paint)
-> animation doesn't start right away
-> display:block + translate(z) -> load time paint
(even if not used, the cpu and gpu gets used though)
- Input with Threaded compositing
some workflow of chrome changes if GPU is injected in the process -> how input is handled.
threaded compositing is the concept newly added to chrome
->when something changes, chrome'll do paint and composite on the blink thread &
present content to the gpu driver -> can consume gpu command/frame at refresh rate timeframe (~16ms)
no need to paint twice or more within 16ms timeframe.
on single threaded model, there're lots of tasks/events need to be handled such as parsing, layout, paint, js event, composite,….etc
->the thread sometimes may not have a chance to paint
some tasks can be offloaded to a different thread
->chrome moves composite task into the compositor thread to offload some task from the blink thread.
another key change is let the compositor thread to accept input events when possible.
Scroll events can be received/processed on the compositor thread.
This can process scroll events as fast as possible even when the blink thread is busy.
if u using touch events for scrolling, the benefits of the compositor thread is great.
So, don't use custom scroll handler coz it leads to the slow performance. just let the browser scroll.
memo: Chrome does multithreaded painting, too
For static headers, use the static header. don't use scroll handler.
->promotes the header into its only layer.
How to see what layers you have
-> turn on "show layer borders" in chrome devtools options
chrome://tracing ->tells you what chrome is doing under the hood. hierarchy view of call stacks
recap: Webpage design with the GPU in mind
- GPU + Layers = faster rendering
- Too many layers = seriously bad time
- Let browser handle scrolling = steady frame rate
- Use tooling to show off how many layers you have
Use #perfmatters for web performance questions
