[prev in list] [next in list] [prev in thread] [next in thread] 

List:       whatwg
Subject:    Re: [whatwg] Canvas in workers
From:       James Robinson <jamesr () google ! com>
Date:       2013-10-24 17:33:29
Message-ID: CAD73md+nUPHtHTr0oh0DP3todnP3Ufi9kGF1JLaCq+aWqLKJjQ () mail ! gmail ! com
[Download RAW message or body]

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
> 


[prev in list] [next in list] [prev in thread] [next in thread]