[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
Reviving old thread. So, I've looked at WebWidget::paint, and it gets its drawing canvas by doing chrome/renderer/render_widget.cc:440: RenderProcess::current()->GetDrawingCanvas(¤t_scroll_buf_, damaged_rect); I don't fully undestand the relation between GraphicsContext, PlatformContext, and PlatformCanvas. Does a PlatformContext contain a PlatformCanvas or vice versa? Is there only one "canvas" per process? If I found a way to do something similar to above (ask RenderProcess::current() to crate a drawing convas), would I be safe in passing that to the webmedia player paint function? Or am I completely not making sense here. Sorry for the basic questions...still trying to orient to the webkit codebase. Thanks, Albert On Thu, May 7, 2009 at 2:16 PM, Darin Fisher wrote: > We have exactly the same issue with WebWidget::paint. That uses WebCanvas. > I think that WebMediaPlayer::paint should be the same. > -Darin > > > On Thu, May 7, 2009 at 1:50 PM, Andrew Scherkus wrote: > >> On Wed, May 6, 2009 at 10:44 AM, Darin Fisher wrote: >> >>> We could either use skia/ext/platform_canvas_mac.h or we could define it >>> to be a CG type. I'm not sure I fully understand the hybridization of CG >>> and Skia in our Chromium Mac port. >> >> >> I am equally (or even more so) clueless on CG. Anyway with hclam >> upstreaming our code an #ifdef solution might be the easiest way to get it >> working for now. >> >> I talked to Eric Carlson about the MediaPlayer interface and he had an >> idea about exposing which painting methods a MediaPlayer prefers >> (GraphicsContext or exposing an RGB surface) and having WebKit decide. We >> sort of have this today with the media engine and mime type supports, so it >> might not be a big stretch. >> >> Andrew >> >> >>> -darin >>> >>> >>> On Wed, May 6, 2009 at 10:41 AM, Darin Fisher wrote: >>> We just need to figure out what the correct typedef is for the Mac platform. -Darin On Wed, May 6, 2009 at 10:40 AM, Darin Fisher wrote: > Please see WebCanvas in the WebKit API. It was designed for this. > -Darin > > > On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus > wrote: > >> WebKit's MediaPlayerPrivate interface is a bit backwards where they >> pass in a GraphicsContext: >> >> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup >> >> We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, >> const IntRect& r) call into Chrome, converting the GraphicsContext to >> a PlatformContextSkia in the process. We realized today this doesn't >> work >> on Mac since it's actually a CGContext. >> >> Without resorting to #ifdefs everywhere, what's the best way to pass >> a PlatformGraphicsContext back to Chrome? >> >> Andrew >> >> >> >> > >>> >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
We have exactly the same issue with WebWidget::paint. That uses WebCanvas. I think that WebMediaPlayer::paint should be the same. -Darin On Thu, May 7, 2009 at 1:50 PM, Andrew Scherkus wrote: > On Wed, May 6, 2009 at 10:44 AM, Darin Fisher wrote: > >> We could either use skia/ext/platform_canvas_mac.h or we could define it >> to be a CG type. I'm not sure I fully understand the hybridization of CG >> and Skia in our Chromium Mac port. > > > I am equally (or even more so) clueless on CG. Anyway with hclam > upstreaming our code an #ifdef solution might be the easiest way to get it > working for now. > > I talked to Eric Carlson about the MediaPlayer interface and he had an idea > about exposing which painting methods a MediaPlayer prefers (GraphicsContext > or exposing an RGB surface) and having WebKit decide. We sort of have this > today with the media engine and mime type supports, so it might not be a big > stretch. > > Andrew > > >> -darin >> >> >> On Wed, May 6, 2009 at 10:41 AM, Darin Fisher wrote: >> >>> We just need to figure out what the correct typedef is for the Mac >>> platform. >>> -Darin >>> >>> >>> On Wed, May 6, 2009 at 10:40 AM, Darin Fisher wrote: >>> Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus wrote: > WebKit's MediaPlayerPrivate interface is a bit backwards where they > pass in a GraphicsContext: > > http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup > > We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, > const IntRect& r) call into Chrome, converting the GraphicsContext to > a PlatformContextSkia in the process. We realized today this doesn't work > on Mac since it's actually a CGContext. > > Without resorting to #ifdefs everywhere, what's the best way to pass > a PlatformGraphicsContext back to Chrome? > > Andrew > > > > >>> >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Wed, May 6, 2009 at 10:44 AM, Darin Fisher wrote: > We could either use skia/ext/platform_canvas_mac.h or we could define it to > be a CG type. I'm not sure I fully understand the hybridization of CG and > Skia in our Chromium Mac port. I am equally (or even more so) clueless on CG. Anyway with hclam upstreaming our code an #ifdef solution might be the easiest way to get it working for now. I talked to Eric Carlson about the MediaPlayer interface and he had an idea about exposing which painting methods a MediaPlayer prefers (GraphicsContext or exposing an RGB surface) and having WebKit decide. We sort of have this today with the media engine and mime type supports, so it might not be a big stretch. Andrew > -darin > > > On Wed, May 6, 2009 at 10:41 AM, Darin Fisher wrote: > >> We just need to figure out what the correct typedef is for the Mac >> platform. >> -Darin >> >> >> On Wed, May 6, 2009 at 10:40 AM, Darin Fisher wrote: >> >>> Please see WebCanvas in the WebKit API. It was designed for this. >>> -Darin >>> >>> >>> On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus >>> wrote: >>> WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect& r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew >>> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
We could either use skia/ext/platform_canvas_mac.h or we could define it to be a CG type. I'm not sure I fully understand the hybridization of CG and Skia in our Chromium Mac port. -darin On Wed, May 6, 2009 at 10:41 AM, Darin Fisher wrote: > We just need to figure out what the correct typedef is for the Mac > platform. > -Darin > > > On Wed, May 6, 2009 at 10:40 AM, Darin Fisher wrote: > >> Please see WebCanvas in the WebKit API. It was designed for this. >> -Darin >> >> >> On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus wrote: >> >>> WebKit's MediaPlayerPrivate interface is a bit backwards where they pass >>> in a GraphicsContext: >>> >>> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup >>> >>> We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, >>> const IntRect& r) call into Chrome, converting the GraphicsContext to >>> a PlatformContextSkia in the process. We realized today this doesn't work >>> on Mac since it's actually a CGContext. >>> >>> Without resorting to #ifdefs everywhere, what's the best way to pass a >>> PlatformGraphicsContext >>> back to Chrome? >>> >>> Andrew >>> >>> >>> >>> >>> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
We just need to figure out what the correct typedef is for the Mac platform. -Darin On Wed, May 6, 2009 at 10:40 AM, Darin Fisher wrote: > Please see WebCanvas in the WebKit API. It was designed for this. > -Darin > > > On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus wrote: > >> WebKit's MediaPlayerPrivate interface is a bit backwards where they pass >> in a GraphicsContext: >> >> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup >> >> We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, >> const IntRect& r) call into Chrome, converting the GraphicsContext to >> a PlatformContextSkia in the process. We realized today this doesn't work >> on Mac since it's actually a CGContext. >> >> Without resorting to #ifdefs everywhere, what's the best way to pass a >> PlatformGraphicsContext >> back to Chrome? >> >> Andrew >> >> >> >> >> > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
Please see WebCanvas in the WebKit API. It was designed for this. -Darin On Tue, May 5, 2009 at 5:40 PM, Andrew Scherkus wrote: > WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in > a GraphicsContext: > > http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup > > We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, > const IntRect& r) call into Chrome, converting the GraphicsContext to > a PlatformContextSkia in the process. We realized today this doesn't work > on Mac since it's actually a CGContext. > > Without resorting to #ifdefs everywhere, what's the best way to pass a > PlatformGraphicsContext > back to Chrome? > > Andrew > > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
2009/5/6 Andrew Scherkus : > 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. Probably that and preserving any active transforms, as Brett noted. > 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). Sure--the difficulty only comes up because some things that are normally per-platform in WebKit, we push down a layer, which works well in general but leads to some rough edges when PLATFORM(CHROMIUM) meets PLATFORM(CG). This is where the "#ifdefs everywhere" that you were hoping to avoid come into play. How many #ifdefs would it really be? --Amanda --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
2009/5/6 Andrew Scherkus : > On Tue, May 5, 2009 at 9:49 PM, Albert J. Wong (王重傑) > wrote: >> >> On Tue, May 5, 2009 at 9:38 PM, Amanda Walker 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Tue, May 5, 2009 at 9:49 PM, Albert J. Wong (王重傑) wrote: > On Tue, May 5, 2009 at 9:38 PM, Amanda Walker 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 (王重傑) >> 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Tue, May 5, 2009 at 9:38 PM, Amanda Walker 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'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 (王重傑) > 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
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? --Amanda On Tue, May 5, 2009 at 11:38 PM, Albert J. Wong (王重傑) 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
If there was a nice way to get a PlatformCanvas out of a
PlatformGraphicsContext when PLATFORM(CG), that'd be awesome.
Brett, I'm not quite sure how you mean to do that. Do you mean that in the
glue code, we should instantiate a byte buffer that we ask the rendered to
fill in, then use webkit's GraphicsContext functions to write that buffer to
screen?
For reference, here's the entry point (plus termporary compilation fix)
that's causing us the headaches:
void MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect& r) {
if (m_data) {
#if PLATFORM(SKIA)
AsDelegate(m_data)->Paint(p->platformContext()->canvas(),
webkit_glue::IntRectToWebRect(r));
#else
// TODO(port): Mac builds use PLATFORM(CG) which does not expose a
// PlatformCanvas from the PlatformContext. Figure out how to render
the
// video on a mac.
notImplemented();
#endif
}
}
2 delegations later, this ends up in video_render_impl.cc which finds the
current video frame to draw, and then writes it to the passed in
PlatformCanvas.
-Albert
On Tue, May 5, 2009 at 7:57 PM, Amanda Walker wrote:
> That would be pretty clean--or perhaps wrap it in a PlatformCanvas
> instead of a bare PlatformGraphicsContext? I haven't looked at the
> media code yet, so I'm not familiar with what it's actually trying to
> do.
>
> --Amanda
>
> On Tue, May 5, 2009 at 10:08 PM, Brett Wilson wrote:
> >
> > On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus
> wrote:
> >> WebKit's MediaPlayerPrivate interface is a bit backwards where they pass
> in
> >> a GraphicsContext:
> >>
> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup
> >> We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p,
> const
> >> IntRect& r) call into Chrome, converting the GraphicsContext to
> >> a PlatformContextSkia in the process. We realized today this doesn't
> work
> >> on Mac since it's actually a CGContext.
> >> Without resorting to #ifdefs everywhere, what's the best way to pass
> >> a PlatformGraphicsContext back to Chrome?
> >
> > Can you just pass a pointer to the pixels and the size? I think the
> > pixel format should be well-defined on each platform, and it should be
> > easy to make a SkBitmap in the Chrome side that uses those pixels
> > directly.
> >
> > Brett
> >
> > > >
> >
>
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
That would be pretty clean--or perhaps wrap it in a PlatformCanvas instead of a bare PlatformGraphicsContext? I haven't looked at the media code yet, so I'm not familiar with what it's actually trying to do. --Amanda On Tue, May 5, 2009 at 10:08 PM, Brett Wilson wrote: > > On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus wrote: >> WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in >> a GraphicsContext: >> http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup >> We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const >> IntRect& r) call into Chrome, converting the GraphicsContext to >> a PlatformContextSkia in the process. We realized today this doesn't work >> on Mac since it's actually a CGContext. >> Without resorting to #ifdefs everywhere, what's the best way to pass >> a PlatformGraphicsContext back to Chrome? > > Can you just pass a pointer to the pixels and the size? I think the > pixel format should be well-defined on each platform, and it should be > easy to make a SkBitmap in the Chrome side that uses those pixels > directly. > > Brett > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus wrote: > WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in > a GraphicsContext: > http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup > We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const > IntRect& r) call into Chrome, converting the GraphicsContext to > a PlatformContextSkia in the process. We realized today this doesn't work > on Mac since it's actually a CGContext. > Without resorting to #ifdefs everywhere, what's the best way to pass > a PlatformGraphicsContext back to Chrome? Can you just pass a pointer to the pixels and the size? I think the pixel format should be well-defined on each platform, and it should be easy to make a SkBitmap in the Chrome side that uses those pixels directly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
