[webkit-dev] Some thoughts about platform flags

[Maciej Stachowiak]

On Sep 24, 2008, at 5:03 PM, Eric Seidel wrote:

> 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 think it's worth discussing the plan a bit up front. Not endlessly,  
but enough so that reviewers will be able to give review against  
consistent guidelines.

> 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.

#ifdefs are a cost for the whole project. And while renaming ifdefs is  
no big deal, having a single ifdef cover multiple things that should  
be separate issues is. Before the PLATFORM macro days, we had that  
same problem in much worse form with #ifdef APPLE_CHANGES.

I don't want to hold up work but in this case brief discussion and an  
understanding of the bigger picture can save us time down the line. I  
would even argue that it will expedite review, since reviewers won't  
be in doubt about the right approach, as was the case in the bug that  
started the thread.

Also, I'm glad we are actually using the list for substantive  
technical discussion more these days, and not just for "help me build  
on my mystery platform" messages.

Regards,
Maciej

>
>
> -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
>>
>>