Could you do some of this with a canvas (app/gfx/canvas.h)? It's supported on all platforms, though it's not heavily used. The "sad plugin" code is an example. Right now it only handles rects, images, and text, but adding path drawing to it shouldn't be difficult... --Amanda
On Wed, Sep 30, 2009 at 2:38 PM, Andrew Scherkus <[email protected]>wrote: > On Wed, Sep 30, 2009 at 1:07 AM, Darin Fisher <[email protected]> wrote: > >> Given that the video backend lives entirely outside of webkit, how would >> this work? (We don't have a webkit API for GraphicsContext.) > > > This is the video "frontend" where the default UI is part of the > RenderTheme. The <video> UI is a decent amount of custom drawing code > inside RenderThemeChromium[Skia/Mac] and maintaining both versions is > painful. > > >> Or, were you planning on moving portions of rendering >> into WebMediaPlayerClientImpl? >> >> -Darin >> >> On Wed, Sep 30, 2009 at 12:18 AM, Andrew Scherkus >> <[email protected]>wrote: >> >>> I'm doing some <video> UI refactoring to use GraphicsContext but noticed >>> drawPath() is unimplemented (causes linker error). >>> What's a good practice to implementing something no one has ever used >>> before? Do we strive to be pixel perfect to GraphicsContextCG's >>> implementation? I don't want to cause developer grief 6 months from now >>> when someone uses a broken drawPath() implementation :) >>> >>> Andrew >>> >>> >>> >> > > > > -- "Portability is generally the result of advance planning rather than trench warfare involving #ifdef" -- Henry Spencer (1992) --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
