Re: Efficient Script Yielding - First Editors Draft

On Wed, Jun 29, 2011 at 8:33 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> Hi
>
> We (Opera) are not quite certain about this proposal. It seems to be
> offloading browser responsibilities onto developers, and not solving the
> issue in any case. As browsers have to implement the ability to yield in
> arbitrary locations to implement this spec, they might as well do it when
> there is a need, not just when it is called by developers. The spec will
> make no impact on the majority of scripts, make developers have to learn one
> more feature (and use it correctly), and won't fix much for mobiles anyway,
> as scripts there run much slower than on desktop. (To fix it for mobiles,
> developers have to sprinkle their code generously with yields everywhere, in
> which case there is little point.)
>
> It is also not going to fix e.g. long running regexps or other similar
> problems, those have to be fixed in the browser anyway.
>
> continues below...
>
>
> On Wed, 29 Jun 2011 00:17:06 +0200, Jason Weber <jweber@microsoft.com>
> wrote:
>
>  Today, browsers don't process events while long running scripts are
>> executing. This includes everything from UI updates, to user input, to end
>> user features like spell checking. Even though the JavaScript may be
>> manipulating the DOM or updating styles, these updates aren't presented to
>> the user until after the script yields. To allow applications to remain
>> responsive and to process visual changes, web developers are forced to
>> sprinkle setTimeouts throughout their code allowing the browser to process
>> pending work and then call script back at a future time.
>>
>
> This is only true for some browsers. Other browsers, like Opera, handle
> this without any issues, and has done so for many years. In our opinion,
> this is how it should be handled, feel free to try it out to see how this
> can be done. We have had to implement support for this to support the whole
> range of CPUs we ship on, where all, even slow, CPUs should be able to
> handle the same existing pages and scripts. The suggested spec would not
> solve this issue.
>

There are many things that a browser can do while a piece of script is
running (such as update the browser UI, etc), but a browser cannot service
any tasks in the HTML-defined task queues while script is running.  This
mean, for example, that a browser cannot dispatch DOM events, run other
pieces of javascript in the same document, or any other action defined in
terms of the event loop
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-loops
.


> But we remain realistic. Browsers need to implement support for yielding
> one way or another. A spec will not change the difficulty of doing so, but
> if having a spec is what is required for other browsers to implement this
> and move the web forwards, then we have no objections. We would implement
> support for the suggested javascript API, but might potentially ignore it
> and continue to use our existing implementation.
>
> A spec could instead simply say that browsers should yield regularily and
> automatically...
>

Browsers can't yield to the HTML-defined event loop while script is running,
that would obviously break the web.

- James


>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>