How to use OffscreenCanvas to improve WebGL game performance?

121 views
Skip to first unread message

Roger Yi

unread,
Jan 24, 2018, 2:47:02 AM1/24/18
to Graphics-dev
My understanding is when *commit* a drawn buffer in worker thread, the buffer will send to compositor directly (active layer tree's corresponding texture layer), so we can skip the mainframe's layout, update layers, commit, active sync tree, blabla... Is my understanding is correct? and any showcase demo in present?

dan...@chromium.org

unread,
Jan 24, 2018, 11:36:36 AM1/24/18
to Roger Yi, Graphics-dev
On Wed, Jan 24, 2018 at 2:47 AM, Roger Yi <roge...@gmail.com> wrote:
My understanding is when *commit* a drawn buffer in worker thread, the buffer will send to compositor directly (active layer tree's corresponding texture layer),

This reads like it is given to the renderer's blink compositor, but rather it goes directly to the display compositor which can display it on screen, without involving any other renderer code in the critical path.

Roger Yi

unread,
Jan 24, 2018, 8:25:24 PM1/24/18
to Graphics-dev, roge...@gmail.com
Sounds great, even better than I thought, is there any technical document about its design and implementation detail can provide?

在 2018年1月25日星期四 UTC+8上午12:36:36,danakj写道:

Ken Russell

unread,
Jan 24, 2018, 8:37:21 PM1/24/18
to Roger Yi, Justin Novosad, Olivia Lai, Graphics-dev
xlai@ or junov@ can surely point you to more details, and some demos.

Note that it isn't even necessary to draw to the OffscreenCanvas from a worker thread in order to get some of the performance gains. Just calling HTMLCanvasElement.transferControlToOffscreen() is enough to give a hint that the canvas is "decoupled" from normal page compositing.

Roger Yi

unread,
Jan 25, 2018, 1:43:07 AM1/25/18
to Graphics-dev, roge...@gmail.com, ju...@chromium.org, xl...@chromium.org
Another question, if we commit a buffer of OffscreenCanvas then do some DOM modification, both in Render thread, but the new buffer of OffscreenCanvas may present on screen in advance of the new DOM content (maybe lead one frame), they are not synchronization, right?

在 2018年1月25日星期四 UTC+8上午9:37:21,Kenneth Russell写道:

Justin Novosad

unread,
Jan 25, 2018, 12:57:30 PM1/25/18
to Roger Yi, Graphics-dev, Olivia
What Ken says is correct and I don't have much to add to that.  

FWIW, the commit() method is probably going away soon.  The spec review is going in another direction.  You may want to follow this thread: https://github.com/w3ctag/design-reviews/issues/141

Roger Yi

unread,
Mar 14, 2018, 4:45:48 AM3/14/18
to Graphics-dev, roge...@gmail.com, xl...@chromium.org


在 2018年1月26日星期五 UTC+8上午1:57:30,Justin Novosad写道:
What Ken says is correct and I don't have much to add to that.  

FWIW, the commit() method is probably going away soon.  The spec review is going in another direction.  You may want to follow this thread: https://github.com/w3ctag/design-reviews/issues/141

From the information of this document - https://github.com/junov/OffscreenCanvasAnimation/blob/master/OffscreenCanvasAnimation.md, and wrote a demo to verify it on Chrome 67 canary by myself, looks like:

1. Use context.commit to commit a new buffer to display compositor;
2. Commit will return a promise, which will be resolved at next BeginFrame (vsync), can be used to drive the animation;

Any possible changed in future?
Reply all
Reply to author
Forward
0 new messages