[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Mon, Nov 17, 2008 at 11:37 PM, Brett Wilson [EMAIL PROTECTED] wrote: Native_theme is a little more tricky since there is some desire to eventually unify theme drawing with the rest of WebKit. If we did that, it would probably be undesirable from WebKit's perspective to have this file in our directory with our funny rules. We can choose to duplicate the code in this case (I think only a fraction of it is actually needed by the app layer, since it uses actual native controls for most thing), so this wouldn't be as bad as it may sound. That seems reasonable; I agree with Ojan that theming web content and theming the app UI should be completely separable (even if they end up calling the same system libraries). There are other options: (1) Move the files in question to Skia. This would be bad, presuming we want to unfork Skia at some point (rather than maintaining our own snapshot). (2) Duplicate the files in both places. I don't like this just on general principles :-). (3) Move the files to port but include headers in base/gfx that include those files, so chrome code doesn't have to directly include files from webkit, which looks a little odd. This doesn't strike me as being as bad as a dependency in the other direction, but I think it's better to completely separate the two even if there's a bit of overlap. Another alternative would be a standalone theme utils library that both sets of code could use, but it would raise the same question about where it should live. --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
I just broke the build again with more NativeImagePtr problems. Right now, this is making me feel much less like tolerating significant differences between our Mac Windows ports. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 10:44 AM, Amanda Walker [EMAIL PROTECTED] wrote: NativeImagePtr is a WebKit type, and is designed to be the platform's native representation. We're all still fighting hidden assumptions about what PLATFORM(XXX) flags mean. Skia and CG are graphics APIs, but webkit (and chromium currently) presume that they are 1:1 with platforms, which they aren't (so, as a result, NativeImagePtr gets typedefed to CGImageRef instead of SkBitmap* by an accident of #ifdef ordering). In the short term, I have a patch in flight that should fix the NativeImagePtr compatibility, but fonts will no doubt present the same problem, and will be much harder to solve (a no significant differences between platforms approach will require a major overhaul on all 3 platforms (well, maybe not Linux, since they don't have much rendering code yet) to use something like Pango + FreeType + Cairo for rendering instead of GDI, CG, or Gtk). No matter what we do each platform should have its own font and form control rendering. I don't think unifying these has ever been on the table. When I talk about unifying I mean the overall architecture. Each platform will have some of its own code to render fonts and form controls into the underlying buffer. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 1:54 PM, Brett Wilson [EMAIL PROTECTED] wrote: No matter what we do each platform should have its own font and form control rendering. I don't think unifying these has ever been on the table. When I talk about unifying I mean the overall architecture. Each platform will have some of its own code to render fonts and form controls into the underlying buffer. Hmm, OK. Why are images different, then? I'm missing something--the architecture's already unified--NativeImagePtr is just a WebKit platform-specific type that's typedefed inconveniently at the moment. --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 11:02 AM, Amanda Walker [EMAIL PROTECTED] wrote: On Tue, Nov 18, 2008 at 1:54 PM, Brett Wilson [EMAIL PROTECTED] wrote: No matter what we do each platform should have its own font and form control rendering. I don't think unifying these has ever been on the table. When I talk about unifying I mean the overall architecture. Each platform will have some of its own code to render fonts and form controls into the underlying buffer. Hmm, OK. Why are images different, then? I'm missing something--the architecture's already unified--NativeImagePtr is just a WebKit platform-specific type that's typedefed inconveniently at the moment. 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. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
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 chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
On Tue, Nov 18, 2008 at 3:16 PM, Brett Wilson [EMAIL PROTECTED] wrote: That's what I was saying may or may not be worth it, and what the decision really comes down to. OK. The change that I'm currently finishing up is, in essence, a more generalized form of the SkBitmap/CGImage converter we're already using in glue/image_decoder. I have a few loose ends to tie up, but it should remove the current sources of pain around images (and simplify things like cursor handling that also depend on them). I'll send it to you for review as soon as it's happy :-). --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving PlatformCanvas to webkit/
I can't comment on the other bits, but I'm all for breaking out the bits of native_theme we need for web compatibility and for our UI into separate pieces. I think trying to share the code is a bit weird actually. In practice, the web has all sorts of strange requirement on how native controls ought to be rendered that have no similar restriction on Chrome's chrome. Merging them together into a base library makes both of them more complicated. Ojan On Mon, Nov 17, 2008 at 8:37 PM, Brett Wilson [EMAIL PROTECTED] wrote: I've made changes to remove almost all of the base dependencies in the graphics layer. With a few exceptions, the only parts left are the uses of platform_canvas*, platform_device*, native_theme, and image_operations. There are tricky because they are extensively used in both webkit/port and chrome. The solution I'm leaning toward now is to make a new directory like webkit/port/platform/graphics/skia/public (or something, any better naming suggestions?) and move these files to there. This directory would have the requirement that it depend on nothing outside of Skia, and we allow files inside the browser to include from here (normally you're not allowed to include things in the browser from webkit/ other than glue). We include the above-mentioned very seldom in Chrome since we use PlatformCanvas' derived class ChromeCanvas in almost all places, so this would not have a big impact on browser code. ChromeCanvas would stay the same, but it's base class would get moved. Native_theme is a little more tricky since there is some desire to eventually unify theme drawing with the rest of WebKit. If we did that, it would probably be undesirable from WebKit's perspective to have this file in our directory with our funny rules. We can choose to duplicate the code in this case (I think only a fraction of it is actually needed by the app layer, since it uses actual native controls for most thing), so this wouldn't be as bad as it may sound. There are other options: (1) Move the files in question to Skia. I don't like this too much because image_operations seems out-of-place, and native_theme seems really out of place. If we pull Skia from an external repository someday, we wouldn't be able to have that stuff live in the Skia repository. (2) Duplicate the files in both places. (3) Move the files to port but include headers in base/gfx that include those files, so chrome code doesn't have to directly include files from webkit, which looks a little odd. Comments or suggestions? Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com 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 -~--~~~~--~~--~--~---
