<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 18, 2008, at 5:58 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com">oliver@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div style="word-wrap: break-word;">Cool -- I wonder though if it would be better if it were placed in a different method, drawFrame or something (very much an up in the air sort of question)</div></blockquote><div><br>drawImage is already overloaded, so why not carry on with that, unless we change the API as you suggest below.</div></div></div></blockquote><div>I'm not sure that drawImage overloading was a good idea in the first place *but* canvas and image are fairly similar in both image-like, whereas video is quite clearly different. I was also thinking it would work better given the additional frame argument, however...</div><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div><br>AFAIK we'd basically have to implement that by creating a second video stream, seeking it and then capturing the frame, and you really don't want to do that synchronously! Then we'd want to cache that stream so that another drawFrame with a nearby frame index was efficient ... ick. So I suggest not offering that API. Authors can always use a second, hidden video element to achieve the same effect.</div></div></div></blockquote><div>... I had failed to consider streaming content (where random seeking may not be possible) :-/</div><div><br></div><div>I still think it would be useful to be able to specify an exact frame, but as you say it may not be really feasible</div><div><br></div><div>--Oliver</div><div><br></div></div></body></html>