Re: [whatwg] [2D Canvas] Proposal: Losing and restoring rendering contexts
On 2013/10/19 3:19, Justin Novosad wrote: Please share your thoughts. I think it these events are needed, unfortunately, as it doesn't look like GPU contexts will be virtualized any time soon. For the open issues, I say yes to the first. Note that this matches what is said about the specification - WebGL will inherit from the parent canvas specification. I say a weak no to the second. Testing can be done with shims and there are probably better ways for apps to do resource management. Regards -Mark -- 注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合 が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情 報の使用を固く禁じております。エラー、手違いでこのメールを受け取られまし たら削除を行い配信者にご連絡をお願いいたし ます. NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.
Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread
On Tue, Oct 22, 2013 at 12:39 AM, Glenn Maynard gl...@zewt.org wrote:
Using ImageBitmap for this has a lot of issues. It requires synchronizing
with scripts in the UI thread. It requires manualling resize your canvas
repeatedly to fit different destinations. It also may potentially create
lots of backbuffers. Here's an example of code using ImageBitmap
incorrectly, leading to excess memory allocation:
function render()
{
var canvas = myWorkerCanvas;
renderTo(canvas);
var buffer = canvas.transferToImageBitmap();
postMessage(buffer);
}
setTimeout(render, 1);
This code actually does something potentially useful which can't easily be
done with attachToCanvas: generating a series of images as fast as possible
which will be processed on another thread in some way other than just
rendering them on the screen. (E.g., be encoded into an animated image or
video file.)
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] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky bzbar...@mit.edu wrote: So it looks to me like in practice Element.getElementById could be quite a bit faster than the equivalent querySelector call, for both the in-tree case (where both can avoid walking the tree) and the out-of-tree case (where both need to walk the tree). Food for thought. So do you think we should add getElementById() to ParentNode in DOM? It seems the advantages are that we can optimize it better than querySelector() because there is no selector parsing. And because there is no selector parsing, you can simply pass the value of an element's id attribute rather than escaping said value using CSS escape rules. What it seems we lack is a clear need for either, but if the cost of implementing it is low, maybe it's worth it? -- http://annevankesteren.nl/
Re: [whatwg] [2D Canvas] Proposal: Losing and restoring rendering contexts
On Tue, Oct 22, 2013 at 3:07 AM, Mark Callow callow.m...@artspark.co.jpwrote: I say a weak no to the second. Testing can be done with shims and there are probably better ways for apps to do resource management. After doing some digging, I totally agree. I found that the webgl debug utilities use a shim for testing context losses and it seems to work just fine for testing web apps. See makeLostContextSimulatingCanvas defined here: https://www.khronos.org/registry/webgl/sdk/debug/webgl-debug.js That exact same pattern could be replicated for 2D canvas and requires no additional APIs from the browser. As far as testing the browser is concerned, implementers can easily add private APIs to test harnesses, so it is a non-issue. I think we can close that issue now. Thanks for the feedback. -Justin
Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread
I just noticed that Canvas already has a Canvas.setContext() method, which seems to do exactly what I'm proposing, even down to clearing the backbuffer on attach. The only difference is that it lives on Canvas instead of the context--the only reason I put it there in my proposal was because this only seemed useful for WebGL. Given that, I think this proposal can be simplified down to just: put setContext on WorkerCanvas too. On Mon, Oct 21, 2013 at 9:03 PM, Kenneth Russell k...@google.com wrote: There are some unexpected consequences of the attachToCanvas API style. For example, what if two contexts use attachToCanvas to target the same canvas? I left out these details in my initial post in order to see what people thought at a high level before delving into details. Attaching when already attached would replace the old attachment. It's not possible for two workers to attach to the same canvas, since only a single WorkerCanvas can exist for any given canvas; and the original Canvas can't be attached to if a WorkerCanvas was created (eg. it's in the proxied mode). What if one of those contexts is 2D and the other is WebGL? Currently it's illegal to try to fetch two different context types for a single Canvas. The current CanvasProxy spec contains several complex rules for these cases, and they're not easy to understand. This is handled by setContext: attaching a context detaches any previously-attached context. Will it be guaranteed that if you have a WebGL context, attachToCanvas to canvas1, do some rendering, and then attachToCanvas to canvas2, that the only remaining buffer in canvas1 is its color buffer? No depth buffers, multisample buffers, etc. will have to remain for some reason? If you reattach to canvas1 in the future, the buffers are cleared, which means you can discard or reuse those buffers as soon as you attach to a different canvas. How would WebGL's preserveDrawingBuffer attribute, which is a property of the context, interact with directing its output to multiple canvases? Since attaching the canvas clears it, that would override preserveDrawingBuffer. Fundamentally I think the behavior is easier to spec, and the implementation is easier to make correct, if the ultimate destination is an image rather than a canvas, and the color buffer is transferred out of the WorkerCanvas in an explicit step. Whether that's true or not, making things easy for the user takes priority over making things easy for spec writers and implementation. On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan rob...@ocallahan.orgwrote: This code actually does something potentially useful which can't easily be done with attachToCanvas: generating a series of images as fast as possible which will be processed on another thread in some way other than just rendering them on the screen. (E.g., be encoded into an animated image or video file.) (This is a proposal for attachToCanvas--now setContext--not against transferToImageBitmap, if there are use cases that transferToImageBitmap solves best in its own right. It seems like toBlob already handles this, though.) -- Glenn Maynard
Re: [whatwg] onclose events for MessagePort
On Oct 21, 2013 6:06 PM, Ehsan Akhgari eh...@mozilla.com wrote: We could further define that channeldropped is fired when the owner of the *other side* is navigated away from. This would mean that events can be received even after a channeldropped event has been fired since other windows could still hold a reference to the port and send messages through it. However it would allow us to release the strong reference that the channeldropped event listener implicitly creates as soon as either side is navigated away from. But what if the page is navigated back to? I think this implies that having fired a channeldropped event because of this reason means that the UA needs to make it impossible to navigate back to the same window, which means disabling optimizations such as Gecko's back-forward cache, which sucks. We could define that it is not automatically sent until the page is kicked out of the bfcache. But yeah, that maight make this behavior unreliable enough that it's not worth doing. / Jonas
Re: [whatwg] onclose events for MessagePort
On Oct 21, 2013 6:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
How does this work - imagine that I have a reference to a MessagePort,
but I'm not actively waiting for any response on the port so I don't have a
channeldropped event listener.
Now, the remote side of the port crashes. I send a message on the port
and add a channeldropped event handler - are you saying that adding a
channeldropped event handler should trigger a channeldropped event if the
other side has already crashed? If not, then how do I find out that the
channel has been dropped if I don't keep the event handler registered all
the time?
I think we may need to mandate that a channeldropped eventis fired when
you register a handler on a port with the other side having already crashed.
Or we expose a property which indicates if the other side has already
dropped.
Though this property+event pattern is actually exactly what a promise is.
And a promise automatically provides the nice feature that it automatically
calls you back if it has been resolved.
So we could expose have:
interface MessagePort {
...
Promise pin();
void unpin(optional any value);
};
Rather than firing channeldropped we reject any promise returned from
pin(). Once the caller receives an expected answer he/she calls unpin()
which resolves the promise using whatever value is passed in and so the
port becomes GCable again.
When pin() is called again after the unpin call we create a new promise
which again prevents the port from getting GCed.
We could even expose a failAndUnpin function which rejects the promise.
This could be useful to enable the page to implement timeouts etc.
/ Jonas
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 22, 2013 at 11:36 AM, Jonas Sicking jo...@sicking.cc wrote:
On Oct 21, 2013 6:08 PM, Ehsan Akhgari eh...@mozilla.com wrote:
How does this work - imagine that I have a reference to a MessagePort,
but I'm not actively waiting for any response on the port so I don't have a
channeldropped event listener.
Now, the remote side of the port crashes. I send a message on the port
and add a channeldropped event handler - are you saying that adding a
channeldropped event handler should trigger a channeldropped event if the
other side has already crashed? If not, then how do I find out that the
channel has been dropped if I don't keep the event handler registered all
the time?
I think we may need to mandate that a channeldropped eventis fired
when you register a handler on a port with the other side having already
crashed.
Or we expose a property which indicates if the other side has already
dropped.
Though this property+event pattern is actually exactly what a promise is.
And a promise automatically provides the nice feature that it automatically
calls you back if it has been resolved.
So we could expose have:
interface MessagePort {
...
Promise pin();
void unpin(optional any value);
};
Rather than firing channeldropped we reject any promise returned from
pin(). Once the caller receives an expected answer he/she calls unpin()
which resolves the promise using whatever value is passed in and so the
port becomes GCable again.
When pin() is called again after the unpin call we create a new promise
which again prevents the port from getting GCed.
This sounds good to me, if the usage of Promise is OK in HTML these days!
We could even expose a failAndUnpin function which rejects the promise.
This could be useful to enable the page to implement timeouts etc.
Hmm, I'm not sure if I understand this. Can you please elaborate?
--
Ehsan
http://ehsanakhgari.org/
Re: [whatwg] Synchronizing Canvas updates in a worker to DOM changes in the UI thread
On Tue, Oct 22, 2013 at 4:37 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan rob...@ocallahan.org wrote: This code actually does something potentially useful which can't easily be done with attachToCanvas: generating a series of images as fast as possible which will be processed on another thread in some way other than just rendering them on the screen. (E.g., be encoded into an animated image or video file.) (This is a proposal for attachToCanvas--now setContext--not against transferToImageBitmap, if there are use cases that transferToImageBitmap solves best in its own right. It seems like toBlob already handles this, though.) It doesn't, because toBlob encodes to an image format. 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] Synchronizing Canvas updates in a worker to DOM changes in the UI thread
On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard gl...@zewt.org wrote: I just noticed that Canvas already has a Canvas.setContext() method That's there in support of CanvasProxy, which is a flawed API and which this entire discussion is aiming to rectify. , which seems to do exactly what I'm proposing, even down to clearing the backbuffer on attach. The only difference is that it lives on Canvas instead of the context--the only reason I put it there in my proposal was because this only seemed useful for WebGL. Given that, I think this proposal can be simplified down to just: put setContext on WorkerCanvas too. Also, adding a present() method to Canvas. On Mon, Oct 21, 2013 at 9:03 PM, Kenneth Russell k...@google.com wrote: There are some unexpected consequences of the attachToCanvas API style. For example, what if two contexts use attachToCanvas to target the same canvas? I left out these details in my initial post in order to see what people thought at a high level before delving into details. At a high level I prefer the form of the WorkerCanvas API, including transferToImageBitmap and the ability to transfer an ImageBitmap into an HTMLImageElement for viewing, and removing the CanvasProxy concept and associated APIs. I'd like to focus my own efforts in writing a full draft for WorkerCanvas under http://wiki.whatwg.org/wiki/Category:Proposals . -Ken
Re: [whatwg] Canvas in workers
On Mon, Oct 21, 2013 at 8:03 AM, Glenn Maynard gl...@zewt.org wrote: On Sun, Oct 20, 2013 at 11:53 PM, Robert O'Callahan rob...@ocallahan.org wrote: Glenn, taking a step back for a bit, is there anything in https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal that you would actually object to? IOW, is there anything there that you would think is completely superfluous to the platform if all your proposals were to be adopted as well? I have no objection to the overall change from CanvasProxy to WorkerCanvas, eg. the stuff in Kyle's original mail to the thread. (Being able to settle on that is one of the reasons I've tried to detach discussion for the other use cases.) I'd only recommend leaving out transferToImageBitmap, srcObject and ImageBitmap.close() parts. I do think that would be redundant with with present proposal. They can always be added later, and leaving them out keeps the WorkerCanvas proposal itself focused. Robert, please don't remove those APIs from your proposal. They're needed in order to address known use cases, and splitting them off will make it difficult to understand how they interact with WorkerCanvas later. I would like to suggest changing the 'srcObject' property on HTMLImageElement into some sort of method taking ImageBitmap as argument. If an ImageBitmap had been previously set against the HTMLImageElement, the method would automatically call 'close()' against it. Fundamentally there should be some easy way to repeatedly update the HTMLImageElement without having to query its previous ImageBitmap and call close() against it before setting srcObject. Would you consider copying https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal to http://wiki.whatwg.org/wiki/Category:Proposals so that it's easier to collaborate on it?
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 22, 2013 at 9:31 AM, Ehsan Akhgari eh...@mozilla.com wrote:
interface MessagePort {
...
Promise pin();
void unpin(optional any value);
};
Rather than firing channeldropped we reject any promise returned from
pin(). Once the caller receives an expected answer he/she calls unpin()
which resolves the promise using whatever value is passed in and so the port
becomes GCable again.
When pin() is called again after the unpin call we create a new promise
which again prevents the port from getting GCed.
This sounds good to me, if the usage of Promise is OK in HTML these days!
We could even expose a failAndUnpin function which rejects the promise.
This could be useful to enable the page to implement timeouts etc.
Hmm, I'm not sure if I understand this. Can you please elaborate?
As the API stands in the proposal above you could write code like:
port.postMessage({ doStuff: using-this-data });
port.onmessage = e = { port.unpin(e.data); };
port.pin().then(d = doAsync(d)).then(...);
Which is great. However if you want to implement a timeout such that
it is treated as an error if data isn't returned within 5 seconds,
that is harder to do. How to do it is left as an exercise to the
reader :)
However it definitely could be done. So I think the above API is
certainly good enough. The failAndUnpin (or better named
unpinAndReject) method is just a convenience method.
/ Jonas
Re: [whatwg] onclose events for MessagePort
On Tue, Oct 22, 2013 at 1:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Oct 22, 2013 at 9:31 AM, Ehsan Akhgari eh...@mozilla.com wrote:
interface MessagePort {
...
Promise pin();
void unpin(optional any value);
};
Rather than firing channeldropped we reject any promise returned from
pin(). Once the caller receives an expected answer he/she calls unpin()
which resolves the promise using whatever value is passed in and so the
port
becomes GCable again.
When pin() is called again after the unpin call we create a new promise
which again prevents the port from getting GCed.
This sounds good to me, if the usage of Promise is OK in HTML these days!
We could even expose a failAndUnpin function which rejects the promise.
This could be useful to enable the page to implement timeouts etc.
Hmm, I'm not sure if I understand this. Can you please elaborate?
As the API stands in the proposal above you could write code like:
port.postMessage({ doStuff: using-this-data });
port.onmessage = e = { port.unpin(e.data); };
port.pin().then(d = doAsync(d)).then(...);
Which is great. However if you want to implement a timeout such that
it is treated as an error if data isn't returned within 5 seconds,
that is harder to do. How to do it is left as an exercise to the
reader :)
However it definitely could be done. So I think the above API is
certainly good enough. The failAndUnpin (or better named
unpinAndReject) method is just a convenience method.
I see. Adding such a function sounds good to me, but I don't feel strongly
either way.
Cheers,
Ehsan
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Oct 22, 2013, at 4:00 AM, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Oct 18, 2013 at 10:56 PM, Boris Zbarsky bzbar...@mit.edu wrote: So it looks to me like in practice Element.getElementById could be quite a bit faster than the equivalent querySelector call, for both the in-tree case (where both can avoid walking the tree) and the out-of-tree case (where both need to walk the tree). Food for thought. So do you think we should add getElementById() to ParentNode in DOM? Why not to Element? It seems the advantages are that we can optimize it better than querySelector() because there is no selector parsing. And because there is no selector parsing, you can simply pass the value of an element's id attribute rather than escaping said value using CSS escape rules. What it seems we lack is a clear need for either, but if the cost of implementing it is low, maybe it's worth it? Because of HTMLCollection's name getter, all major browsers must be capable of a id+name lookup at every element (since Element has getElementsByTagName that returns a HTMLCollection). - R. Niwa
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On Tue, Oct 22, 2013 at 7:42 PM, Ryosuke Niwa rn...@apple.com wrote: On Oct 22, 2013, at 4:00 AM, Anne van Kesteren ann...@annevk.nl wrote: So do you think we should add getElementById() to ParentNode in DOM? Why not to Element? ParentNode encompasses Document, DocumentFragment, and Element. See http://dom.spec.whatwg.org/#parentnode I think features that make sense on Document and Element should also be on DocumentFragment, unless they're really not applicable for some reason. -- http://annevankesteren.nl/
Re: [whatwg] Canvas in workers
On Tue, Oct 22, 2013 at 7:31 PM, Kenneth Russell k...@google.com wrote: Robert, please don't remove those APIs from your proposal. They're needed in order to address known use cases, and splitting them off will make it difficult to understand how they interact with WorkerCanvas later. Yes, I think it's a good idea to specify a complete set of APIs that fit together logically and if there are some we don't need, we can remove them or just delay implementing them until they're needed. I would like to suggest changing the 'srcObject' property on HTMLImageElement into some sort of method taking ImageBitmap as argument. If an ImageBitmap had been previously set against the HTMLImageElement, the method would automatically call 'close()' against it. Fundamentally there should be some easy way to repeatedly update the HTMLImageElement without having to query its previous ImageBitmap and call close() against it before setting srcObject. Hmm. I'm not sure how this should work. Maybe instead we should use canvas elements and define ImageBitmap.transferToCanvas(HTMLCanvasElement). That would mitigate Glenn's argument about having to change element types too. Would you consider copying https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal to http://wiki.whatwg.org/wiki/Category:Proposals so that it's easier to collaborate on it? No problem at all. Can you do it? I need to get a WHATWG account :-). 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] Canvas in workers
On Tue, Oct 22, 2013 at 1:44 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Oct 22, 2013 at 7:31 PM, Kenneth Russell k...@google.com wrote: Robert, please don't remove those APIs from your proposal. They're needed in order to address known use cases, and splitting them off will make it difficult to understand how they interact with WorkerCanvas later. Yes, I think it's a good idea to specify a complete set of APIs that fit together logically and if there are some we don't need, we can remove them or just delay implementing them until they're needed. I would like to suggest changing the 'srcObject' property on HTMLImageElement into some sort of method taking ImageBitmap as argument. If an ImageBitmap had been previously set against the HTMLImageElement, the method would automatically call 'close()' against it. Fundamentally there should be some easy way to repeatedly update the HTMLImageElement without having to query its previous ImageBitmap and call close() against it before setting srcObject. Hmm. I'm not sure how this should work. Maybe instead we should use canvas elements and define ImageBitmap.transferToCanvas(HTMLCanvasElement). That would mitigate Glenn's argument about having to change element types too. Using a Canvas as the target for displaying an ImageBitmap is fraught with problems. Because Canvases are rendering targets themselves, transferring in an ImageBitmap has to interoperate somehow with the canvas's rendering context as well as other APIs like toDataURL. The DrawingBuffer proposal in http://wiki.whatwg.org/wiki/CanvasInWorkers was admittedly complex, but did properly handle fully detaching a canvas's framebuffer and attaching it to another one. ImageBitmap, being semantically read-only, isn't well suited for this task. The idea to use an HTMLImageElement to display the ImageBitmaps is elegant and I would like to see it explored, including prototyping it behind an experimental flag and seeing how well it works. Would you consider copying https://wiki.mozilla.org/User:Roc/WorkerCanvasProposal to http://wiki.whatwg.org/wiki/Category:Proposals so that it's easier to collaborate on it? No problem at all. Can you do it? I need to get a WHATWG account :-). Yes, I'll take care of the initial draft. The whatwg was pretty responsive when I got my account though. -Ken 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] Canvas in workers
I got an account and I'm uploading the proposal now. 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] Canvas in workers
Great. On Tue, Oct 22, 2013 at 2:54 PM, Robert O'Callahan rob...@ocallahan.org wrote: I got an account and I'm uploading the proposal now. 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] Canvas in workers
On Tue, Oct 22, 2013 at 10:44 PM, Robert O'Callahan rob...@ocallahan.orgwrote: No problem at all. Can you do it? I need to get a WHATWG account :-). OK, I added the proposal here: http://wiki.whatwg.org/wiki/WorkerCanvas A couple of changes from the previous version: -- Added ImageBitmap.transferToImage. -- Removed HTMLImageElement.srcObject (though it may come back in other contexts) -- Made ImageBitmap Transferable. This makes it possible to ensure the worker that generated an ImageBitmap does not keep alive a reference to the buffer. -- Removed ImageBitmaps.close() since the use-cases driving this proposal probably don't need it anymore. 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] Synchronizing Canvas updates in a worker to DOM changes in the UI thread
On Tue, Oct 22, 2013 at 2:48 AM, Robert O'Callahan rob...@ocallahan.org wrote: This code actually does something potentially useful which can't easily be done with attachToCanvas: generating a series of images as fast as possible which will be processed on another thread in some way other than just rendering them on the screen. (E.g., be encoded into an animated image or video file.) (Err, wait. A few issues come to mind. 1: You can already say createImageBitmap(canvas) to create an ImageBitmap, which handles the store a snapshot of a frame use cases. 2: If the reason to have a transfer version for these use cases is just an optimization, then it's not obvious that it's a useful optimization. The use cases you mention suggest a GPU readback anyway. 3: If you're doing the encoding yourself in script, you want ImageData anyway, not ImageBitmap. I don't object as such to adding such a method if it's useful, and I don't think I have the energy right now to debate these in much depth, but this feels like taking a proposal and searching for uses for it.) On Tue, Oct 22, 2013 at 12:20 PM, Kenneth Russell k...@google.com wrote: On Tue, Oct 22, 2013 at 7:37 AM, Glenn Maynard gl...@zewt.org wrote: I just noticed that Canvas already has a Canvas.setContext() method That's there in support of CanvasProxy, which is a flawed API and which this entire discussion is aiming to rectify. I don't see flaws with the setContext() API, which appears to have already solved the problem of being able to make one context render to multiple canvases. Any relation to CanvasProxy isn't relevant to this. , which seems to do exactly what I'm proposing, even down to clearing the backbuffer on attach. The only difference is that it lives on Canvas instead of the context--the only reason I put it there in my proposal was because this only seemed useful for WebGL. Given that, I think this proposal can be simplified down to just: put setContext on WorkerCanvas too. Also, adding a present() method to Canvas. That's mixing up proposals, actually. Adding present() is for the explicitpresent proposal, which aims at solving the synchronizing rendering in a worker to DOM changes in the main thread use cases. Reusing setContext() replaces my attachToCanvas() proposal, which is for the one context rendering to multiple canvases) use cases. They're orthogonal, not mutually exclusive, and solve different problems. (We're mixing up proposals because we're trying to solve too many problems simultaneously, which is one reason I've tried to split this stuff into smaller chunks.) At a high level I prefer the form of the WorkerCanvas API, including transferToImageBitmap and the ability to transfer an ImageBitmap into an HTMLImageElement for viewing, and removing the CanvasProxy concept and associated APIs. I'd like to focus my own efforts in writing a full draft for WorkerCanvas under http://wiki.whatwg.org/wiki/Category:Proposals . Again, this is a supplement to WorkerCanvas, not a replacement for it. (It may be compatible with CanvasProxy too, but I haven't looked at it closely to see.) We're circling around: you keep saying we should use transferToImageBitmap, I keep pointing out the problems with it that my proposal solves, and you reply by saying we should use transferToImageBitmap, without addressing those problems. I don't think we have any more information to bring to the discussion right now, so I think we're at a good point to wait for Hixie to get around to these threads rather than going over the same stuff again (and giving him more reading material :). Here's a summary of my proposal: - The WorkerCanvas adjustments to CanvasProxy (minus the transferToImageBitmap stuff), to better address the rendering to a Canvas from a worker and creating off-screen Canvases in a worker-related use cases. - Include setContext() on WorkerCanvas, to support rendering from one context to multiple canvases when in a worker. - Add explicitpresent and present() to Canvas, to support synchronizing rendering in a worker to DOM changes in the main thread without forcing that synchronization on everybody. The second and third are independent and can be implemented separately, after WorkerCanvas itself has time to settle. -- Glenn Maynard
[whatwg] New social element (was: Various threads with feedback on HTML elements)
On 10/15/13 1:00 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 26 Jan 2013, Steve Faulkner wrote: Lists are appropriate for indicating nested tree structures. The use of lists to markup comments is a common mark up pattern used in blogging software such as wordpress. The code verbosity is not dissimilar to the use of article, less so even option end /li tags are omitted. Indeed, that's fine too. The useful information that is conveyed to users who actually consume and benefit from it is provided by using lists , but not by using article. It's the exact same structure, the exact same information can be conveyed. That's just a matter for implementors. Since ol is decades old and article is a pretty recent addition, it makes sense that ol would be more reliably implemented and exposed. On Sat, 26 Jan 2013, Bruce Lawson wrote: In short, why should the spec suggest any specific method of marking up comments? I haven't followed the discussion until now on this. But I think the initial rationale for the addition of a comment element as mean of replacement of article is the wrong way to look at it. article is fine for a comment as syndicate-able and self-contained. Even a LOL comment. People often publish full articles that are far less useful or intelligible comment that a LOL. I just wish it was art. I however propose a social element, to encompass the semantic of social interaction around the context of the main article, which could be tweets, comments, discussions, reviews, testimonials, forum feeds, rating etc. What we need is not marking up individual comments differently, but a semantic on the whole block. Consider the case of someone using a screen-reader wanting to jump to comments. The only way to do that right now, is to hope that a comment link is around. But because there are no standards in terms of where that would be he/she has to skip through links. I would think that jumping to comments right away is potentially a slightly painful thing to do atm. And there are no landmark roles for that either that I know of. Comments don't seem to quite fit as an aside or section, nor it is a very good fit for ARIA role:complementary because it's not separate enough. It's a social context discussing or reviewing the main article inside and attached to main though not quite a section of main... Just as we now have social sections in Analytics or Gmail, I think the semantic works and is broad enough, along with the accessibility reason. Search engine or bots would also have an easier job to discern comments or social context from everything else. Thoughts? Any objection? Discuss? Please love it!? :-) In theory, to put an end to the very conversation we're having here. :-) And that too. But unless I am mistaken, its worth noting that neither ARIA nor Microdata nor the Microformat rel attribute have any notion of social context or 'comments' whatsoever, which I always found lacking.
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/22/13 2:42 PM, Ryosuke Niwa wrote: Because of HTMLCollection's name getter, all major browsers must be capable of a id+name lookup at every element (since Element has getElementsByTagName that returns a HTMLCollection). While true, in practice pretty much no one uses the name getter on that object, so nothing right now forces browsers to implement it in a particularly efficient (as opposed to simple) way. -Boris
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10/22/13 7:00 AM, Anne van Kesteren wrote: So do you think we should add getElementById() to ParentNode in DOM? I actually do, yes. It seems the advantages are that we can optimize it better than querySelector() because there is no selector parsing. This, in my mind, is a somewhat minor advantage. And because there is no selector parsing, you can simply pass the value of an element's id attribute rather than escaping said value using CSS escape rules. Right. More importantly, you don't have to even understand that there are CSS escaping rules involved, which is a bigger hurdle than doing the escaping once you've understood that part What it seems we lack is a clear need for either Where by either you mean lack of a need for passing without escaping first? See above. but if the cost of implementing it is low, maybe it's worth it? The way I see it, UAs already have to implement SVGSVGElement.prototype.getElementById. I suspect that in practice the same implementation can be used for any Element or DocumentFragment, so the cost of implementing is in fact quite low. -Boris
