Re: Shrinking existing libraries as a goal
On Tue, May 15, 2012 at 9:32 PM, Yehuda Katz wyc...@gmail.com wrote: In the past year or so, I've participated in a number of threads that were implicitly about adding features to browsers that would shrink the size of existing libraries. Inevitably, those discussions end up litigating whether making it easier for jQuery (or some other library) to do the task is a good idea in the first place. While those discussions are extremely useful, I feel it would be useful for a group to focus on proposals that would shrink the size of existing libraries with the implicit assumption that it was a good idea. From some basic experimentation I've personally done with the jQuery codebase, I feel that such a group could rather quickly identify enough areas to make a much smaller version of jQuery that ran on modern browsers plausible. I also think that having data to support or refute that assertion would be useful, as it's often made casually in meta-discussions. If there is a strong reason that people feel that a focused effort to identify ways to shrink existing popular libraries in new browsers would be a bad idea, I'd be very interested to hear it. I think it's a great idea. Shipping less code over the wire seems like a win from any perspective. I support a focused effort like this. I know some folks will be hesitant to embrace it out of the tail-wag-dog fears that the unfortunate patterns in scripting libraries will result in misguided changes to the platform. My answer to this is: let's do research first and see what proposed changes come up. :DG Thanks so much for your consideration, Yehuda Katz jQuery Foundation (ph) 718.877.1325
Re: Shrinking existing libraries as a goal
On Wed, May 16, 2012 at 9:53 AM, Dimitri Glazkov dglaz...@chromium.org wrote: I think it's a great idea. Shipping less code over the wire seems like a win from any perspective. How about a cross-site secure (even pre-compiled) cache for JS libraries as well? We almost have this with CDN now, if it were formally supported by standards then every site using a common library would ship less code without compromises by the platform or libraries wrt API. jjb
Re: exposing CANVAS or something like it to Web Workers
So how to take this forward? My #1 priority is to get WebGL in workers. Lots of developers have expressed a need for this from decoding compressed textures in a worker to offloading thousands of draw calls per frame to a worker. WebGL already defines sharing mechanisms so at least for the WebGL case I don't need to solve how to display anything back in the main worker. The worker can draw to a texture. The main page can use that texture. WebGL/OpenGL already define that relationship. But, to get WebGL in a worker I need a way to get a WebGLRenderingContext into a worker. Some Ideas **) Create context in main page, pass to worker* Pros: . No new APIs or objects. Cons: . Transfer is messy. What happens to all the entry points and properties to the context object left in the main page? What happens to the cavnas parameter on the transferred context? How do you synchronize the main page setting canvas.width or canvas.height with the worker trying to render to it? **) Create a context directly in a Worker (or anywhere for that matter)* As in var gl = new WebGLRenderingContext Pros: . ??? Cons: . requires defining how the backbuffer size is set. Maybe there is no backbuffer for a directly created WebGLRenderingContext? . if there is no backbuffer then using one of these contexts to draw into a texture or 2d context is problematic **) Create an offscreen canvas like object minus HTMLElement parts* * * Pros: . same or nearly the API as already exists for canvas . flexible. getContext can return different kinds of context. Maybe only webgl for now? Cons: . ???
Re: exposing CANVAS or something like it to Web Workers
On Wed, May 16, 2012 at 12:30 PM, Gregg Tavares (勤) g...@google.com wrote: So how to take this forward? My #1 priority is to get WebGL in workers. Lots of developers have expressed a need for this from decoding compressed textures in a worker to offloading thousands of draw calls per frame to a worker. WebGL already defines sharing mechanisms so at least for the WebGL case I don't need to solve how to display anything back in the main worker. The worker can draw to a texture. The main page can use that texture. WebGL/OpenGL already define that relationship. But, to get WebGL in a worker I need a way to get a WebGLRenderingContext into a worker. Some Ideas *) Create context in main page, pass to worker Pros: . No new APIs or objects. Cons: . Transfer is messy. What happens to all the entry points and properties to the context object left in the main page? What happens to the cavnas parameter on the transferred context? How do you synchronize the main page setting canvas.width or canvas.height with the worker trying to render to it? *) Create a context directly in a Worker (or anywhere for that matter) As in var gl = new WebGLRenderingContext Pros: . ??? Cons: . requires defining how the backbuffer size is set. Maybe there is no backbuffer for a directly created WebGLRenderingContext? . if there is no backbuffer then using one of these contexts to draw into a texture or 2d context is problematic This alternative seems like the one that can be moved forward most easily, since essentially all of the changes would be within the WebGL spec. - Extend the spec to support context sharing. (Each WebGLRenderingContext points to an opaque WebGLContextGroup object.) - Define structured cloning semantics for WebGLContextGroup. - Add a constructor or factory method to WebGLRenderingContext allowing creation with a WebGLContextGroup. Contexts created in this manner would have no back buffer by default. (FBOs could still be used to do rendering with the context.) - Allow some or all of the WebGLObject types (textures, etc.) to be either copied during structured cloning or transferred. Then the worker can at least upload textures to the GPU completely asynchronously from the main thread, and inform the main thread via postMessage when they have finished uploading. That seems to be a tractable first step and one that would already have immediate benefits for developers. -Ken *) Create an offscreen canvas like object minus HTMLElement parts Pros: . same or nearly the API as already exists for canvas . flexible. getContext can return different kinds of context. Maybe only webgl for now? Cons: . ???
Re: exposing CANVAS or something like it to Web Workers
On Wed, May 16, 2012 at 12:42 PM, Kenneth Russell k...@google.com wrote: On Wed, May 16, 2012 at 12:30 PM, Gregg Tavares (勤) g...@google.com wrote: So how to take this forward? My #1 priority is to get WebGL in workers. Lots of developers have expressed a need for this from decoding compressed textures in a worker to offloading thousands of draw calls per frame to a worker. WebGL already defines sharing mechanisms so at least for the WebGL case I don't need to solve how to display anything back in the main worker. The worker can draw to a texture. The main page can use that texture. WebGL/OpenGL already define that relationship. But, to get WebGL in a worker I need a way to get a WebGLRenderingContext into a worker. Some Ideas *) Create context in main page, pass to worker Pros: . No new APIs or objects. Cons: . Transfer is messy. What happens to all the entry points and properties to the context object left in the main page? What happens to the cavnas parameter on the transferred context? How do you synchronize the main page setting canvas.width or canvas.height with the worker trying to render to it? *) Create a context directly in a Worker (or anywhere for that matter) As in var gl = new WebGLRenderingContext Pros: . ??? Cons: . requires defining how the backbuffer size is set. Maybe there is no backbuffer for a directly created WebGLRenderingContext? . if there is no backbuffer then using one of these contexts to draw into a texture or 2d context is problematic This alternative seems like the one that can be moved forward most easily, since essentially all of the changes would be within the WebGL spec. - Extend the spec to support context sharing. (Each WebGLRenderingContext points to an opaque WebGLContextGroup object.) - Define structured cloning semantics for WebGLContextGroup. - Add a constructor or factory method to WebGLRenderingContext allowing creation with a WebGLContextGroup. Contexts created in this manner would have no back buffer by default. (FBOs could still be used to do rendering with the context.) - Allow some or all of the WebGLObject types (textures, etc.) to be either copied during structured cloning or transferred. Then the worker can at least upload textures to the GPU completely asynchronously from the main thread, and inform the main thread via postMessage when they have finished uploading. That seems to be a tractable first step and one that would already have immediate benefits for developers. That problem I have with this path is the cons mentioned above. It's a dead end. With real contexts you can do this webglcontext1.texImage2D(..., webglcontext2.canvas); and this context2d.drawImage(webgl.canvas, ...) But with a context created with new WebGLRenderingContext you can't do anything like that because size of the backbuffer is not defined. Eventually we'll want to support operation like that and we'll likely end up with something like DrawingSurface or CanvasSurface or OffscreenCanvas. At that point this ability to go new WebGLRenderingContext will just be left over cruft. Also we'll have to define how to addEventListner for WebGLRenderContext for listening for lost context or for async context creation (yea, less important on workers). That stuff is currently not on WebGLRenderingContext. It seems like it should stay off if it. -Ken *) Create an offscreen canvas like object minus HTMLElement parts Pros: . same or nearly the API as already exists for canvas . flexible. getContext can return different kinds of context. Maybe only webgl for now? Cons: . ???
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
Ok. I think I'm convinced on all points.
I've uploaded a webkit patch which implements what we've agreed on here:
https://bugs.webkit.org/show_bug.cgi?id=84646
I'm happy to report that this patch is nicer than the queued-token
approach. Good call, Henri.
On Tue, May 15, 2012 at 9:39 PM, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, May 15, 2012 at 6:46 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein rafa...@google.com
wrote:
Issue 1: How to handle tokens which precede the first start tag
Options:
a) Queue them, and then later run them through tree construction once
the implied context element has been picked
b) Create a new insertion like waiting for context element, which
probably ignores end tags and doctype and inserts character tokens and
comments. Once the implied context element is picked, reset the
insertion mode appropriately, and procede normally.
I prefer b).
I like b as well. I assume it means that the waiting for context element
insertion mode would keep scanning until the ambiguity was resolved, and
then enter the appropriate insertion mode. Am I misunderstanding?
I think what Yehuda is getting at here is that there are a handful of
tags which are allowed to appear anywhere, so it doesn't make sense to
resolve the ambiguity based on their identity.
I talked with Tab about this, and happily, that set seems to be
style, script, meta, link. Happily, because this means that
the new ImpliedContext insertion mode can handle start tags as
follows (code from the above patch)
if (token.name() == styleTag
|| token.name() == scriptTag
|| token.name() == metaTag
|| token.name() == linkTag) {
processStartTagForInHead(token); // process following the rules
for the in head insertion mode
return;
}
m_fragmentContext.setContextTag(getImpliedContextTag(token.name()));
set the context element
resetInsertionModeAppropriately(); reset the insertion mode appropriately
processStartTag(token); // reprocess the token
I'm assuming the use case for this stuff isn't that authors throw
random stuff at the API and then insert the result somewhere. I expect
authors to pass string literals or somewhat cooked string literals to
the API knowing where they're going to insert the result but not
telling the insertion point to the API as a matter of convenience.
If you know you are planning to insert stuff as a child of tbody,
don't start your string literal with stuff that would tokenize as
characters!
(Firefox currently does not have the capability to queue tokens.
Speculative parsing in Firefox is not based on queuing tokens. See
https://developer.mozilla.org/en/Gecko/HTML_parser_threading for the
details.)
Issue 2: How to infer a non-HTML implied context element
Options:
a) By tagName alone. When multiple namespaces match, prefer HTML, and
then either SVG or MathML (possibly on a per-tagName basis)
b) Also inspect attributes for tagNames which may be in multiple
namespaces
AFAICT, the case where this really matters (if my assumptions about
use cases are right) is a. (Fragment parsing makes scripts useless
anyway by setting their already started flag, authors probably
shouldn't be adding styles by parsing style, both HTML and SVG
font are considered harmful and cross-browser support Content MathML
is far off in the horizon.)
So I prefer a) possibly with a-specific elaborations if we can come
up with some. Generic solutions seem to involve more complexity. For
example, if we supported a generic attribute for forcing SVG
interpretation, would it put us on a slippery slope to support it when
it appears on tokens that aren't the first start tag token in a
contextless fragment parse?
Issue 3: What form does the API take
a) Document.innerHTML
b) document.parse()
c) document.createDocumentFragment()
I prefer b) because:
* It doesn't involve creating the fragment as a separate step.
* It doesn't need to be foolishly consistent with the HTML vs. XML
design errors of innerHTML.
* It's shorted than document.createDocumentFragment().
* Unlike innerHTML, it is a method, so we can add more arguments
later (or right away) to refine its behavior.
--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/
Re: exposing CANVAS or something like it to Web Workers
On Wed, May 16, 2012 at 1:11 PM, Gregg Tavares (勤) g...@google.com wrote: On Wed, May 16, 2012 at 12:42 PM, Kenneth Russell k...@google.com wrote: On Wed, May 16, 2012 at 12:30 PM, Gregg Tavares (勤) g...@google.com wrote: So how to take this forward? My #1 priority is to get WebGL in workers. Lots of developers have expressed a need for this from decoding compressed textures in a worker to offloading thousands of draw calls per frame to a worker. WebGL already defines sharing mechanisms so at least for the WebGL case I don't need to solve how to display anything back in the main worker. The worker can draw to a texture. The main page can use that texture. WebGL/OpenGL already define that relationship. But, to get WebGL in a worker I need a way to get a WebGLRenderingContext into a worker. Some Ideas *) Create context in main page, pass to worker Pros: . No new APIs or objects. Cons: . Transfer is messy. What happens to all the entry points and properties to the context object left in the main page? What happens to the cavnas parameter on the transferred context? How do you synchronize the main page setting canvas.width or canvas.height with the worker trying to render to it? *) Create a context directly in a Worker (or anywhere for that matter) As in var gl = new WebGLRenderingContext Pros: . ??? Cons: . requires defining how the backbuffer size is set. Maybe there is no backbuffer for a directly created WebGLRenderingContext? . if there is no backbuffer then using one of these contexts to draw into a texture or 2d context is problematic This alternative seems like the one that can be moved forward most easily, since essentially all of the changes would be within the WebGL spec. - Extend the spec to support context sharing. (Each WebGLRenderingContext points to an opaque WebGLContextGroup object.) - Define structured cloning semantics for WebGLContextGroup. - Add a constructor or factory method to WebGLRenderingContext allowing creation with a WebGLContextGroup. Contexts created in this manner would have no back buffer by default. (FBOs could still be used to do rendering with the context.) - Allow some or all of the WebGLObject types (textures, etc.) to be either copied during structured cloning or transferred. Then the worker can at least upload textures to the GPU completely asynchronously from the main thread, and inform the main thread via postMessage when they have finished uploading. That seems to be a tractable first step and one that would already have immediate benefits for developers. That problem I have with this path is the cons mentioned above. It's a dead end. With real contexts you can do this webglcontext1.texImage2D(..., webglcontext2.canvas); and this context2d.drawImage(webgl.canvas, ...) But with a context created with new WebGLRenderingContext you can't do anything like that because size of the backbuffer is not defined. Eventually we'll want to support operation like that and we'll likely end up with something like DrawingSurface or CanvasSurface or OffscreenCanvas. At that point this ability to go new WebGLRenderingContext will just be left over cruft. Also we'll have to define how to addEventListner for WebGLRenderContext for listening for lost context or for async context creation (yea, less important on workers). That stuff is currently not on WebGLRenderingContext. It seems like it should stay off if it. These are all good points, and I agree that the ideal fix would be to use the Canvas element (or DrawingSurface, etc.) from a worker, rather than doing a WebGL-specific hack. Given how long discussions have been ongoing on this topic, though, I think this may just be too large a single step to take. Rather than add a constructor to WebGLRenderingContext that would need to remain there permanently, perhaps a factory method with a vendor prefix could be added (e.g. WebGLRenderingContext.webkitCreateOffscreenContext, WebGLRenderingContext.mozCreateOffscreenContext). The long-term plan could be to remove the factory method once a better solution is reached, as opposed to removing the vendor prefixes. This would at least allow some applications to explore the use of workers with WebGL, see whether this addresses any existing issues, and expose new issues. -Ken -Ken *) Create an offscreen canvas like object minus HTMLElement parts Pros: . same or nearly the API as already exists for canvas . flexible. getContext can return different kinds of context. Maybe only webgl for now? Cons: . ???
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Wed, May 16, 2012 at 4:29 PM, Rafael Weinstein rafa...@google.com wrote:
Ok. I think I'm convinced on all points.
I've uploaded a webkit patch which implements what we've agreed on here:
https://bugs.webkit.org/show_bug.cgi?id=84646
I'm happy to report that this patch is nicer than the queued-token
approach. Good call, Henri.
On Tue, May 15, 2012 at 9:39 PM, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, May 15, 2012 at 6:46 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein rafa...@google.com
wrote:
Issue 1: How to handle tokens which precede the first start tag
Options:
a) Queue them, and then later run them through tree construction once
the implied context element has been picked
b) Create a new insertion like waiting for context element, which
probably ignores end tags and doctype and inserts character tokens and
comments. Once the implied context element is picked, reset the
insertion mode appropriately, and procede normally.
I prefer b).
I like b as well. I assume it means that the waiting for context element
insertion mode would keep scanning until the ambiguity was resolved, and
then enter the appropriate insertion mode. Am I misunderstanding?
I think what Yehuda is getting at here is that there are a handful of
tags which are allowed to appear anywhere, so it doesn't make sense to
resolve the ambiguity based on their identity.
I talked with Tab about this, and happily, that set seems to be
style, script, meta, link. Happily, because this means that
the new ImpliedContext insertion mode can handle start tags as
follows (code from the above patch)
if (token.name() == styleTag
|| token.name() == scriptTag
|| token.name() == metaTag
|| token.name() == linkTag) {
processStartTagForInHead(token); // process following the rules
for the in head insertion mode
return;
}
m_fragmentContext.setContextTag(getImpliedContextTag(token.name()));
set the context element
resetInsertionModeAppropriately(); reset the insertion mode appropriately
processStartTag(token); // reprocess the token
So if I understand things correctly, that would mean that:
document.parse(parsed as textscriptparsed as script
content/scripttrtdtable content/td/tr);
would return a fragment like:
#fragment
#text parsed as text
script
#text parsed as script content
tr
td
#text table content
Is this correct? The important part here is that the contents of the
script element is parsed according to the rules which normally apply
when parsing scripts?
(That of course leaves the terrible situation that script parsing is
vastly different in HTML and SVG, but that's a bad problem that
already exists)
/ Jonas
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Wed, May 16, 2012 at 4:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 16, 2012 at 4:29 PM, Rafael Weinstein rafa...@google.com wrote:
Ok. I think I'm convinced on all points.
I've uploaded a webkit patch which implements what we've agreed on here:
https://bugs.webkit.org/show_bug.cgi?id=84646
I'm happy to report that this patch is nicer than the queued-token
approach. Good call, Henri.
On Tue, May 15, 2012 at 9:39 PM, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, May 15, 2012 at 6:46 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein rafa...@google.com
wrote:
Issue 1: How to handle tokens which precede the first start tag
Options:
a) Queue them, and then later run them through tree construction once
the implied context element has been picked
b) Create a new insertion like waiting for context element, which
probably ignores end tags and doctype and inserts character tokens and
comments. Once the implied context element is picked, reset the
insertion mode appropriately, and procede normally.
I prefer b).
I like b as well. I assume it means that the waiting for context element
insertion mode would keep scanning until the ambiguity was resolved, and
then enter the appropriate insertion mode. Am I misunderstanding?
I think what Yehuda is getting at here is that there are a handful of
tags which are allowed to appear anywhere, so it doesn't make sense to
resolve the ambiguity based on their identity.
I talked with Tab about this, and happily, that set seems to be
style, script, meta, link. Happily, because this means that
the new ImpliedContext insertion mode can handle start tags as
follows (code from the above patch)
if (token.name() == styleTag
|| token.name() == scriptTag
|| token.name() == metaTag
|| token.name() == linkTag) {
processStartTagForInHead(token); // process following the rules
for the in head insertion mode
return;
}
m_fragmentContext.setContextTag(getImpliedContextTag(token.name()));
set the context element
resetInsertionModeAppropriately(); reset the insertion mode appropriately
processStartTag(token); // reprocess the token
So if I understand things correctly, that would mean that:
document.parse(parsed as textscriptparsed as script
content/scripttrtdtable content/td/tr);
would return a fragment like:
#fragment
#text parsed as text
script
#text parsed as script content
tr
td
#text table content
Is this correct? The important part here is that the contents of the
script element is parsed according to the rules which normally apply
when parsing scripts?
(That of course leaves the terrible situation that script parsing is
vastly different in HTML and SVG, but that's a bad problem that
already exists)
Yes. Exactly.
/ Jonas
Re: Implied Context Parsing (DocumentFragment.innerHTML, or similar) proposal details to be sorted out
On Wed, May 16, 2012 at 4:52 PM, Rafael Weinstein rafa...@google.com wrote:
On Wed, May 16, 2012 at 4:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 16, 2012 at 4:29 PM, Rafael Weinstein rafa...@google.com wrote:
Ok. I think I'm convinced on all points.
I've uploaded a webkit patch which implements what we've agreed on here:
https://bugs.webkit.org/show_bug.cgi?id=84646
I'm happy to report that this patch is nicer than the queued-token
approach. Good call, Henri.
On Tue, May 15, 2012 at 9:39 PM, Yehuda Katz wyc...@gmail.com wrote:
Yehuda Katz
(ph) 718.877.1325
On Tue, May 15, 2012 at 6:46 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, May 11, 2012 at 10:04 PM, Rafael Weinstein rafa...@google.com
wrote:
Issue 1: How to handle tokens which precede the first start tag
Options:
a) Queue them, and then later run them through tree construction once
the implied context element has been picked
b) Create a new insertion like waiting for context element, which
probably ignores end tags and doctype and inserts character tokens and
comments. Once the implied context element is picked, reset the
insertion mode appropriately, and procede normally.
I prefer b).
I like b as well. I assume it means that the waiting for context element
insertion mode would keep scanning until the ambiguity was resolved, and
then enter the appropriate insertion mode. Am I misunderstanding?
I think what Yehuda is getting at here is that there are a handful of
tags which are allowed to appear anywhere, so it doesn't make sense to
resolve the ambiguity based on their identity.
I talked with Tab about this, and happily, that set seems to be
style, script, meta, link. Happily, because this means that
the new ImpliedContext insertion mode can handle start tags as
follows (code from the above patch)
if (token.name() == styleTag
|| token.name() == scriptTag
|| token.name() == metaTag
|| token.name() == linkTag) {
processStartTagForInHead(token); // process following the rules
for the in head insertion mode
return;
}
m_fragmentContext.setContextTag(getImpliedContextTag(token.name()));
set the context element
resetInsertionModeAppropriately(); reset the insertion mode appropriately
processStartTag(token); // reprocess the token
So if I understand things correctly, that would mean that:
document.parse(parsed as textscriptparsed as script
content/scripttrtdtable content/td/tr);
would return a fragment like:
#fragment
#text parsed as text
script
#text parsed as script content
tr
td
#text table content
Is this correct? The important part here is that the contents of the
script element is parsed according to the rules which normally apply
when parsing scripts?
(That of course leaves the terrible situation that script parsing is
vastly different in HTML and SVG, but that's a bad problem that
already exists)
Yes. Exactly.
That leaves the question of if the contents of the script should be
parsed as a HTML script or an SVG script. The same question applies to
style.
Of course, ideally we would make the two parse the same way, but so
far I've not been successful in convincing people here that that's a
good idea.
/ Jonas
Re: exposing CANVAS or something like it to Web Workers
On Wed, May 16, 2012 at 2:30 PM, Gregg Tavares (勤) g...@google.com wrote:
Some Ideas
**) Create context in main page, pass to worker*
Transferring an active context from one thread to another (at the
implementation level) can be hard. It's much simpler to only create new
the contexts in the thread they'll be used, never allowing contexts to be
moved from thread to thread.
Here's a first-pass approach:
1: Add HTMLCanvasElement.getBackbuffer, which returns a lightweight
Backbuffer interface associated with the HTMLCanvasElement. This has only
one method, getContext, which is equivalent to canvas.getContext. (This is
exactly like the suggestion for making images available in threads.)
2: Backbuffer can be transferred from one thread to another, using the
transfer mechanism. On transfer, any WebGL contexts (and other context
types) in the thread associated with the same backbuffer are destroyed
(putting exactly what destroyed means aside for later). Additionally,
when a Backbuffer is transferred, the underlying backbuffer of the
HTMLCanvasElement is considered owned by the new thread. All instances of
Backbuffer for that HTMLCanvasElement, including newly-created ones, are
neutered unless the backbuffer is transferred back to the UI thread.
3: As long as the backbuffer of an HTMLCanvasElement is owned by a thread
other than the UI thread, calls to the following methods on the associated
HTMLCanvasElement raise an exception: getBackbuffer, getContext,
toBlob, toDataURL.
This takes effect synchronously, as soon as transfer happens (right when
you postMessage the Backbuffer somewhere else).
4: When a Worker receives a Backbuffer, it can call Backbuffer.getContext
to create a WebGLContext (with exactly the same rules as
HTMLCanvasElement.getContext). The results of rendering to that context
are visible in the associated HTMLCanvasElement in the main thread.
This ensures that only one thread can ever have an open context for any
backbuffer, and that pixel readback functions (toBlob and toDataURL) can't
expose the asynchronous nature of what's going on. The transfer mechanics
are rough and need refining.
For offscreen rendering in a thread, just allow constructing Backbuffer;
for example,
var backbuffer = new Backbuffer(1024, 768);
var ctx = backbuffer.getContext(webgl);
backbuffer.resize(1920, 1200);
Backbuffer.resize is equivalent to resizing a Canvas, and only available
for Backbuffers you create yourself, not for ones created via
HTMLCanvasElement.getBackBuffer.
One problem that I havn't attempted to solve here: when the
HTMLCanvasElement is resized in the UI thread, it results in changes to
drawingBufferWidth/drawingBufferHeight. This would expose asynchronous
behavior. Instead, it would probably need to apply the change (from the
thread's perspective) in a queued task, so you have to return to the event
loop for it to be applied.
If a thread is killed by the browser (eg. due to a CPU quota), the
backbuffers it owns are orphaned; you can no longer create contexts for
it. You need to create a new Canvas. This isn't great, but workers don't
really seem to try to make it possible to recover from this anyway.
interface CanvasBackbuffer {
object? getContext(DOMString contextId, any... args);
}
[Constructor(unsigned long width, unsigned long height)]
interface Backbuffer : CanvasBackbuffer {
void resize(unsigned long width, unsigned long height);
}
interface HTMLCanvasElement : HTMLElement {
CanvasBackbuffer getBackbuffer();
}
The Backbuffer ctor is available in workers.
Importantly, you can start by just implementing the Backbuffer
constructor. That would only allow the simpler case of offscreen rendering.
--
Glenn Maynard
Re: Shrinking existing libraries as a goal
In principle, I agree with this as a valid goal. It's one among many though, so the devil is in the details of each specific proposal to balance out this goal with others (e.g. keeping the platform consistent). I'd love to see your list of proposals of what it would take to considerably shrink jQuery. On Tue, May 15, 2012 at 9:32 PM, Yehuda Katz wyc...@gmail.com wrote: In the past year or so, I've participated in a number of threads that were implicitly about adding features to browsers that would shrink the size of existing libraries. Inevitably, those discussions end up litigating whether making it easier for jQuery (or some other library) to do the task is a good idea in the first place. While those discussions are extremely useful, I feel it would be useful for a group to focus on proposals that would shrink the size of existing libraries with the implicit assumption that it was a good idea. From some basic experimentation I've personally done with the jQuery codebase, I feel that such a group could rather quickly identify enough areas to make a much smaller version of jQuery that ran on modern browsers plausible. I also think that having data to support or refute that assertion would be useful, as it's often made casually in meta-discussions. If there is a strong reason that people feel that a focused effort to identify ways to shrink existing popular libraries in new browsers would be a bad idea, I'd be very interested to hear it. Thanks so much for your consideration, Yehuda Katz jQuery Foundation (ph) 718.877.1325
