Re: [whatwg] Canvas in workers

On Thu, Oct 24, 2013 at 6:59 AM, Glenn Maynard <glenn@zewt.org> wrote:

> >
> > ----- Original Message -----
> > From: "Robert O'Callahan" <robert@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@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
>

Received on Thursday, 24 October 2013 17:33:56 UTC