[webkit-dev] Some thoughts about platform flags

[Eric Seidel]

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 <darin at chromium.org> wrote:
> [resent, doh... that's it, i'm registering my other email address]
>
> On Wed, Sep 24, 2008 at 4:32 PM, Darin Fisher <darin at google.com> wrote:
>>
>> On Wed, Sep 24, 2008 at 4:22 PM, Maciej Stachowiak <mjs at apple.com> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>