I think this is best discussed as individual patches. I would encourage Amanda (and others) to make patches as necessary and mark them for review.
I would also encourage the rest of WebKit to be rather lenient about getting these #ifdefs into our source. I think that the benefit of getting all of Chrome's WebKit source into our (WebKit's) source tree (and getting a bunch of Googler's hacking directly on WebKit.org) *far* outweighs any cost due to having to rename a few ifdefs later on. -eric On Wed, Sep 24, 2008 at 4:33 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: > [resent, doh... that's it, i'm registering my other email address] > > On Wed, Sep 24, 2008 at 4:32 PM, Darin Fisher <[EMAIL PROTECTED]> wrote: >> >> On Wed, Sep 24, 2008 at 4:22 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: >>> >>> On Sep 24, 2008, at 3:30 PM, Amanda Walker wrote: >>> >>> > >>> > The renderer process will be using CoreText, CG, some Cocoa, etc., but >>> > using the Apple WebView sitting inside an NSScrollView which is in >>> > turn inside an NSWindow--we must introduce a proxy, since remoting >>> > NSView or NSWindow over DO doesn't work terribly well. This is part >>> > of what gave us the idea of using a flag that denotes the >>> > architecture, since the code changes are there to support this >>> > difference in architecture, not platform per se. However, I agree >>> > that USE or ENABLE on specific architecture features is a much better >>> > way to do this. >>> >>> Do you guys have cross-process rendering working on Mac yet, even as a >>> prototype? I am wondering if these statements about what is required >>> to do it have been tested or are just assumptions. >>> >>> I ask because I suspect doing cross-process rendering efficiently on >>> Mac is nontrivial and I would be concerned that changes could be made >>> that go in the wrong direction, if there isn't a proof of concept done >>> first. >> >> >> We have only done some basic prototyping, but it is important to note that >> plugins aside, our multiprocess architecture has nothing to do with the >> native widget system. We just render everything to a memory buffer, and >> then there is a native widget in the main process that is responsible for >> blitting that memory buffer to the screen. You can think of it like a >> application that views an image. Sounds portable to me. (Plugins are where >> it gets nasty.) >> -Darin > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
