On Sat, May 30, 2009 at 9:22 PM, Simon Fraser <[email protected]> wrote:
> > Something else you should consider here is ways that the video can be clipped > and transformed. Thanks Simon, I forgot that > > Any solution which naively puts a hardware surface over some rect where the > video is supposed to be will be broken in many cases. Thinking aloud; the only option seems to be is to convert the YUV output of the decoder to a RGB surface, which is mapped in to Cairo surface; this way Webkit is free to do those crazy CSS Transforms; YUV to RGB will kill the processor (unless done in HW) But for any embedded core running around 300~400MHz this will never work for even d...@25 fps (forget HD) Now. how can we accelerate this ? I assume clip will always translate to a paint / setSize function. So that can be handled in HW. Is that right ? Is there a way to decently accelerate all the video layer CSS transforms ? Is it possible to send the Transform down to RenderVideo and then to the MediaPlayer ? Some chips do provide HW transform functions; > > This is exactly what the ACCELERATED_COMPOSITING code path does. There is > currently a Core Animation backend for Mac (GraphicsLayerCA.mm); you'd have > to > write a backend for your compositing system if you wish to use this code > path. Does this handle the CSS transforms as well ? -- Sriram Neelakandan Author - Embedded Linux System Design And Development (http://tinyurl.com/2doosu) _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
