[whatwg] Canvas in workers
James Robinson
jamesr at google.com
Thu Oct 24 10:33:29 PDT 2013
On Thu, Oct 24, 2013 at 6:59 AM, Glenn Maynard <glenn at zewt.org> wrote:
> >
> > ----- Original Message -----
> > From: "Robert O'Callahan" <robert at ocallahan.org>
> >
> > We talked through this proposal with a lot of Mozilla people in a meeting
> > and collectively decided that we don't care about the case of workers
> that
> > commit multiple frames to a canvas without yielding --- at least for now.
> > So we want to remove commit() and copy the main-thread semantics that a
> > canvas frame is eligible for presentation whenever script is not running
> in
> > the worker.
> >
>
> On Thu, Oct 24, 2013 at 7:25 AM, Jeff Gilbert <jgilbert at mozilla.com>
> wrote:
>
> > This is not the current WebGL semantics:
> > WebGL presents its drawing buffer to the HTML page compositor
> > immediately before a compositing operation[...]
> >
>
> (Can you please quote correctly? Having one person top-quoting makes a
> mess of the whole thread, and it looked like you were saying that the WebGL
> spec language you were quoting was incorrect.)
>
> The assumption WebGL is making here is that compositing is a synchronous
> task in the event loop, which happens while no script is running. That is,
> the semantics Robert describes are the same as what the WebGL spec is
> trying to say. That's not necessarily how compositing actually works,
> though, and that language also won't make sense with threaded rendering.
> It might be better for WebGL to define this using the "global script
> clean-up jobs" task that HTML now defines.
>
> http://www.whatwg.org/specs/web-apps/current-work/#run-the-global-script-clean-up-jobs
> I'd recommend spinning off a separate thread if we want to go into this
> further.
>
The time that compositing occurs is already specified by the HTML event
loop processing model (7.1.4.2):
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#processing-model-4
An event loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
must
continually run through the following steps for as long as it exists:
1.
Run the oldest
task<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task>
on
one of the event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
's task queues<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue>,
if any, ignoring tasks whose associated
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document>s
are not fully
active<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#fully-active>.
The user agent may pick any task
queue<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue>
.
2.
If the storage
mutex<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#storage-mutex>
is
now owned by the event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>,
release it so that it is once again free.
3.
If a task was run in the first step above, remove that task from its task
queue<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue>
.
4.
If this event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
is
not a worker's event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>,
run these substeps:
1.
Perform a microtask
checkpoint<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#perform-a-microtask-checkpoint>
.
2.
Provide a stable
state<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#provide-a-stable-state>
.
3.
If necessary, update the rendering or user interface of any
Document<http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document>
or browsing
context<http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context>
to
reflect the current state.
5.
Otherwise, if this event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
is
running for a
WorkerGlobalScope<http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#workerglobalscope>,
but there are no events in the event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
's task queues<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue>
and
the WorkerGlobalScope<http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#workerglobalscope>
object's closing<http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-workerglobalscope-closing>
flag
is true, then destroy the event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>,
aborting these steps.
6. Return to the first step of the event
loop<http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop>
.
My reading is that "update the rendering" includes any main-thread-visible
side effects of compositing. Since this occurs outside of the operation of
running a task (barring a task spinning the event loop) it'll happen when
no script is running.
- James
>
> --
> Glenn Maynard
>
More information about the whatwg
mailing list