<6E2DEA35-2EB3-48D6-B6A0-73215ADC38AD@apple.com>
Current votes: None.
--Apple-Mail-1-276516235 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 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) One other thing that I would consider would be requiring the frame# to be specified explicitly as that would make things like "chapter" previews (or whatever) work in a way that is perhaps cleaner. Otherwise you have to record the current location in the video stream, then scan to each location you want to blit, draw, and then return to the original position. Which could easily result in weird visual behaviour for the user (as the video element flickers a few random frames while you do your previews or whatever). Just my 2c. --Oliver On Aug 18, 2008, at 2:45 PM, Robert O'Callahan wrote: > Thanks to Anne for pointing this out... > > We've implemented using <video> elements as an image source in > canvas.drawImage: > https://bugzilla.mozilla.org/show_bug.cgi?id=448674 > The extension is very obvious. Unlike animated images, which always > draw the first or poster frame, we draw the current frame of the > video. This lets you do things like make a thumbnail timeline. > > It'd be nice to have this in the spec. > > Rob > -- > "He was pierced for our transgressions, he was crushed for our > iniquities; the punishment that brought us peace was upon him, and > by his wounds we are healed. We all, like sheep, have gone astray, > each of us has turned to his own way; and the LORD has laid on him > the iniquity of us all." [Isaiah 53:5-6] --Apple-Mail-1-276516235 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; ">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><br></div><div>One other thing that I would consider would = be requiring the frame# to be specified explicitly as that would make = things like "chapter" previews (or whatever) work in a way that is = perhaps cleaner. Otherwise you have to record the current location = in the video stream, then scan to each location you want to blit, draw, = and then return to the original position. Which could easily = result in weird visual behaviour for the user (as the video element = flickers a few random frames while you do your previews or = whatever).</div><div><br></div><div>Just my = 2c.</div><div><br></div><div>--Oliver</div><div><br></div><div><div><div>O= n Aug 18, 2008, at 2:45 PM, Robert O'Callahan wrote:</div><br = class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div = dir=3D"ltr">Thanks to Anne for pointing this out...<br><br>We've = implemented using <video> elements as an image source in = canvas.drawImage:<br><a = href=3D"https://bugzilla.mozilla.org/show_bug.cgi?id=3D448674">https://bug= zilla.mozilla.org/show_bug.cgi?id=3D448674</a><br> The extension is very = obvious. Unlike animated images, which always draw the first or poster = frame, we draw the current frame of the video. This lets you do things = like make a thumbnail timeline.<br><br>It'd be nice to have this in the = spec.<br> <br>Rob<br>-- <br>"He was pierced for our transgressions, he = was crushed for our iniquities; the punishment that brought us peace was = upon him, and by his wounds we are healed. We all, like sheep, have gone = astray, each of us has turned to his own way; and the LORD has laid on = him the iniquity of us all." [Isaiah 53:5-6]<br> = </div></blockquote></div><br></div></body></html>= --Apple-Mail-1-276516235--