Re: [whatwg] The behaviour of Notification.requestPermission() in Workers
On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe nsm.nik...@gmail.com wrote: The easiest solution for implementors and authors is to make the requestPermission() call in a HTML page before spawning a worker or registering a service worker. Inside the Worker scope we then have two options: 1) requestPermission() is not defined. 2) requestPermission() does not ask the user, but uses the permission associated with that origin, or denied. I believe option 2 is better in terms of having a complete API. Feedback is appreciated about what the right approach should be. Given that Notificaiton.permission exists, I'm not sure what the additional value of Notification.requestPermission() in a worker context would be. -- http://annevankesteren.nl/
Re: [whatwg] Canvas in workers
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. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] The behaviour of Notification.requestPermission() in Workers
Agreed with Anne - I don't see the value in exposing a non-functional requestPermission(). Certainly on Chrome (which only allows invoking requestPermission in the context of user input to prevent abuse) we would be unlikely to support requestPermission() from workers, at least unless we decide to change that behavior. On Thu, Oct 24, 2013 at 11:05 AM, Anne van Kesteren ann...@annevk.nlwrote: On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe nsm.nik...@gmail.com wrote: The easiest solution for implementors and authors is to make the requestPermission() call in a HTML page before spawning a worker or registering a service worker. Inside the Worker scope we then have two options: 1) requestPermission() is not defined. 2) requestPermission() does not ask the user, but uses the permission associated with that origin, or denied. I believe option 2 is better in terms of having a complete API. Feedback is appreciated about what the right approach should be. Given that Notificaiton.permission exists, I'm not sure what the additional value of Notification.requestPermission() in a worker context would be. -- http://annevankesteren.nl/
Re: [whatwg] The behaviour of Notification.requestPermission() in Workers
On Thursday, October 24, 2013 at 11:05 AM, Anne van Kesteren wrote: On Thu, Oct 24, 2013 at 2:19 AM, Nikhil Marathe nsm.nik...@gmail.com (mailto:nsm.nik...@gmail.com) wrote: The easiest solution for implementors and authors is to make the requestPermission() call in a HTML page before spawning a worker or registering a service worker. Inside the Worker scope we then have two options: 1) requestPermission() is not defined. 2) requestPermission() does not ask the user, but uses the permission associated with that origin, or denied. I believe option 2 is better in terms of having a complete API. Feedback is appreciated about what the right approach should be. Given that Notificaiton.permission exists, I'm not sure what the additional value of Notification.requestPermission() in a worker context would be. Portability of code between worker and non worker? --tobie
Re: [whatwg] Canvas in workers
This is not the current WebGL semantics: WebGL presents its drawing buffer to the HTML page compositor immediately before a compositing operation[...] I can't find where this is specified for canvas, though I assume it's all implied. -Jeff - Original Message - From: Robert O'Callahan rob...@ocallahan.org To: Justin Novosad ju...@google.com Cc: WHAT Working Group wha...@whatwg.org, Glenn Maynard gl...@zewt.org, Kenneth Russell k...@google.com, Kyle Huey m...@kylehuey.com Sent: Thursday, October 24, 2013 2:24:27 AM Subject: Re: [whatwg] Canvas in workers 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. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * *
Re: [whatwg] The behaviour of Notification.requestPermission() in Workers
On Thu, Oct 24, 2013 at 12:46 PM, Tobie Langel tobie.lan...@gmail.com wrote: On Thursday, October 24, 2013 at 11:05 AM, Anne van Kesteren wrote: Given that Notificaiton.permission exists, I'm not sure what the additional value of Notification.requestPermission() in a worker context would be. Portability of code between worker and non worker? The code that is portable will remain portable. The code that only works in one context cannot be ported. Seems fine. In particular Notification.requestPermission() will be part of a UI-flow that has no business in a worker. -- http://annevankesteren.nl/
Re: [whatwg] Canvas in workers
- Original Message - From: Robert O'Callahan rob...@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 jgilb...@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. -- Glenn Maynard
Re: [whatwg] Canvas in workers
On Thu, Oct 24, 2013 at 6:59 AM, Glenn Maynard gl...@zewt.org wrote: - Original Message - From: Robert O'Callahan rob...@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 jgilb...@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 loophttp://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 taskhttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task on one of the event loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop 's task queueshttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue, if any, ignoring tasks whose associated Documenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#documents are not fully activehttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#fully-active. The user agent may pick any task queuehttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue . 2. If the storage mutexhttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#storage-mutex is now owned by the event loophttp://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 queuehttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue . 4. If this event loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop is not a worker's event loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop, run these substeps: 1. Perform a microtask checkpointhttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#perform-a-microtask-checkpoint . 2. Provide a stable statehttp://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 Documenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#document or browsing contexthttp://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context to reflect the current state. 5. Otherwise, if this event loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop is running for a WorkerGlobalScopehttp://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#workerglobalscope, but there are no events in the event loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop 's task queueshttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#task-queue and the WorkerGlobalScopehttp://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#workerglobalscope object's closinghttp://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#dom-workerglobalscope-closing flag is true, then destroy the event loophttp://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loop, aborting these steps. 6. Return to the
