2009/5/6 Andrew Scherkus <scher...@chromium.org>:
> On Tue, May 5, 2009 at 9:49 PM, Albert J. Wong (王重傑) <ajw...@chromium.org>
> wrote:
>>
>> On Tue, May 5, 2009 at 9:38 PM, Amanda Walker <ama...@chromium.org> wrote:
>>>
>>> Ah, I see. Hmm, going in that direction (from a GraphicsContext back
>>> up to the PlatformCanvas that wraps it) is an interesting question
>>> (the rest of our rendering code goes in the other direction). And as
>>> Brett can attest, this isn't the first time that PLATFORM(CG) has
>>> caused a headache--we just (so far) haven't been willing to
>>> duplicate/fork all of the Mac rendering code that currently lives in
>>> PLATFORM(CG), since there's a lot of it (especially text handling)
>>> that would end up the same.
>>>
>>> Brett's idea (change your paint routine to take a raw pixmap (an
>>> RGBA32Buffer), which we can easily draw into a GraphicsContext on any
>>> platform, is basically what the ImageDecoder subclasses do (including
>>> rudimentary multi-frame support for things like animated GIFs). If
>>> that will work, it's probably the easiest to integrate into all 3
>>> platforms, since the dirty work has already been done. If that's too
>>> many frame copies for video, we can write a function that can create,
>>> say, an SkBitmap* pointing at the destination bits given a
>>> GraphicsContext and a rectangle.
>>>
>>> Would either of those approaches work?
>>
>> They both sound workable, and might be the best option at this point.
>
> We'll ping WebKit to find out the reasoning behind passing in a
> GraphicsContext. Probably for performance reasons and reducing extra
> blits/copies, but still worth investigating. For some background
> information... each platform implementation of MediaPlayerPrivate either
> stores video frames on a platform-dependent surface (cairo_surface_t,
> SkBitmap) or uses a platform-dependent context (HDC, NSGraphicsContext) to
> interact with an external library (QTKit on mac, QuickTime on Windows).
>
> I'm a bit confused at how the SkBitmap* creation would work (mostly how to
> deal with scaled elements, but I'm no Skia expert). The RGBA32Buffer sounds
> like a pretty reasonable first attempt. Upstreaming our media glue code
> might clean up some things as well.
Any transforms will be lost when you do this, of course. But the only
cross-platform way of representing that with the surface is through a
GraphicsContext object.
Brett
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
