On Tue, Nov 18, 2008 at 2:05 PM, Brett Wilson <[EMAIL PROTECTED]> wrote: > This is not platform-specific on any other architecture, and it > doesn't need to be. The difference is that font and form control > rendering have to be native for us to look correct. This is not the > case for images or any other part of GraphicsContext.
But font and form control drawing *use* GraphicsContext, which is what prompted turning on PLATFORM(CG) in the first place. We can turn off PLATFORM(CG), which resolves the type mismatches for images--but also means forking FontMac, FontMacATSUI, and so on (a total of a dozen or so files, last time I tried it) or upstream a patch that replaces a lot of code like "CGContextRef cgContext = context->platformContext()" with platform-specific macro (a type of patch that WebKit has been resistant to so far, from what I've seen). I'm happy to spend a day or so to perform that experiment if that'll be a useful reference point, but based on our initial porting effort, it doesn't actually remove any complexity in the port--it just pushes it around and forks more files. Allowing easy conversion between SkBitmaps and CGImages (a technique we already use, with good effect, since it can be done without copying the actual bits) seems a lot simpler to me over overall. For that matter, it might even be straightforward to write copy constructors that would let code pass them around interchangeably (as long as we make sure to keep track of who owns the pixel data). --Amanda --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
