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.
Thanks for the replies,
Andrew
We'd actually considered something similar, but didn't really like the idea
> of having the GraphicsContext draw call happen inside the webkit glue code;
> all our other glue code just delegates, so this would suddenly add behavior
> into the glue class.
>
> Another suggestion that Alpha brought up was to write some sort of simple
> wrapper for GraphicsContext that could allow us to call the draw lower down
> in the call chain without violating the typing abstraction.
>
> -Albert
>
>
>>
>>
>> --Amanda
>>
>>
>> On Tue, May 5, 2009 at 11:38 PM, Albert J. Wong (王重傑)
>> <ajw...@chromium.org> wrote:
>> > If there was a nice way to get a PlatformCanvas out of a
>> > PlatformGraphicsContext when PLATFORM(CG), that'd be awesome.
>>
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
