<meta charset="utf-8"><meta charset="utf-8">On Mon, Feb 22, 2010 at 11:57 AM, Drew Wilson <span dir="ltr"><<a href="mailto:atwilson@google.com" target="_blank">atwilson@google.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="gmail_quote"><div>Do we feel that text APIs are, in general, difficult to implement in a multi-thread safe manner? </div></div></blockquote><div><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 11:51 AM, Michael Nordman <span dir="ltr"><<a href="mailto:michaeln@google.com" target="_blank">michaeln@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div>The lack of support for text drawing in the worker context seems like a short sighted mistake.</div></blockquote><div> </div><div>On Mon, Feb 22, 2010 at 2:35 PM, Jeremy Orlow <span dir="ltr"><<a href="mailto:jorlow@chromium.org" target="_blank">jorlow@chromium.org</a>></span> wrote:</div>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
It does indeed seem pretty short sighted.</blockquote></div></div><div><br></div><div>On Mon, Feb 22, 2010 at 2:48 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:</div>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div style="word-wrap: break-word; "><div><div>1) Like others, I would recommend not omitting the text APIs. I can see why they are a bit trickier to implement than the others, but I don't see a fundamental barrier.</div>
</div></div></blockquote><div><br></div><div>I did want to add the text apis but it does add implementation difficulties for WebKit (and as I understand Firefox). However, they are part of what people want and it does simplify the interfaces, so done.</div>
<div><br></div><div><br></div><div>On Mon, Feb 22, 2010 at 2:48 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote: </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div style="word-wrap: break-word; "><div><div></div><div>2) I would propose adding createPattern and drawImage overloads that take an OffscreenCanvas. The other overloads would in practice not be usefully callable in the worker case since you couldn't get an image, canvas or video element.</div>
<div><br></div><div>3) This would leave the only difference between the two interfaces as the drawFocusRing method. This would not be usefully callable in a worker, since there would be no way to get an Element. But it doesn't seem worth it to add an interface just for one method's worth of difference.</div>
</div></div></blockquote></div><div class="gmail_quote"><div> </div><div>Sounds good.</div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<div class="im">What is the use case for this? It seems like in most cases you'll want</div>to display something on screen to the user, and so the difference<br>comes down to shipping drawing commands across the pipe, vs. shipping<br>
the pixel data.</blockquote></div></div><div><br></div><div>Apologies for not including this at the start. As now mentioned in several places in the thread, the simplest use case is resize/rotate of images. </div><div><br>
</div><div>However, more complex use cases may involve heavy users of canvas who would like to either prerender the canvas and/or move the time taken to generate the canvas off of the main thread. While it is true that simple uses of canvas would not get a performance win out of this, if you are doing many canvas operations, (like many complex operations) it is faster to copy a result than it is to generate it.</div>
<div><br></div><div>Ideally canvas will get some form of toBlob which will allow the image to be appropriately compressed as well which will also reduce the number of bits that need to be copied from the worker to the main thread (as well as make for a smaller upload than the raw bits).</div>
<div><br></div><div><div>Lastly, in the future, one can see other uses for the OffscreenCanvas including WebGL for workers which several folks (Maciej and Jonas) have expressed interest about on this thread.</div></div><div>
<br></div><div>dave</div><div><br></div></div>