[webkit-dev] Some thoughts about platform flags

[Darin Fisher]

On Wed, Sep 24, 2008 at 10:44 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Sep 24, 2008, at 10:10 PM, Amanda Walker wrote:
>
>  On Wed, Sep 24, 2008 at 7:25 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>>> On Sep 24, 2008, at 3:36 PM, Darin Fisher wrote:
>>>
>>>> I don't think anything about our port implies hosted in a rendering
>>>> subprocess.  Our port works perfectly well in a single process
>>>> traditional
>>>> browser model.  We build two embedding apps based on our port of WebKit:
>>>> test_shell and chrome.  The former is like a mash-up of DRT and
>>>> Spinneret.
>>>>
>>>
>>> OK; that appears to disagree with what Amanda said above.
>>>
>>
>> Not really--our architectural changes were made to support
>> multiprocess rendering, but they do not require it.  test_shell still
>> renders into a bitmap and then blits that to the OS window, it just
>> does it all within a single process.  But all of the drawing, event
>> handling, geometry management, etc. go through the same set of host &
>> delegate interfaces that the multiprocess app does, rather than
>> talking to the top level view(s) directly.  The implementations of
>> those interfaces in test_shell are just a lot simpler.
>>
>
> What do you think would be a more accurate (but succinct) way to describe
> the purpose of the changes or the feature they enable? Is "multi-process"
> close enough to accurate or is there a better way to put it? I ask because I
> am hoping we can pick some ifdef flags that are based on the features being
> added or the technologies being used, and not just a catchall based on the
> embedding product. As I mentioned before, our experience with catchall
> ifdefs like that has been poor, and once they get into the source they can
> be a lot of work to untangle.
>

A more succinct description for our rendering model might be something that
reflects the fact that we are rendering to a memory buffer.  We still use
elements of the native graphics engine to do so.  For example, even though
we use Skia, we still use GDI to render text.  On Mac, the balance between
Skia and CG is different for various reasons.  Amanda can speak to those
differences better than me.  We also reach out to the OS to access the
native theme rendering engine, again just to have it paint into our memory
buffer.

I think our port is potentially valuable to people who might want to use
WebKit in a server farm to render web pages, since in such an environment
the actual OS widgets just tend to get in the way.

(The big exception is still plugins, of course!  As I mentioned elsewhere,
we delegate those out to the embedder so that WebCore doesn't really deal
with them directly.  That is needed to support out-of-process plugins.)

-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080924/038a212d/attachment.html