<div dir="ltr"><div class="gmail_quote">On Wed, Sep 24, 2008 at 10:44 PM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="Wj3C7c"><br>
On Sep 24, 2008, at 10:10 PM, Amanda Walker wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Sep 24, 2008 at 7:25 PM, Maciej Stachowiak &lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sep 24, 2008, at 3:36 PM, Darin Fisher wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don&#39;t think anything about our port implies hosted in a rendering<br>
subprocess. &nbsp;Our port works perfectly well in a single process traditional<br>
browser model. &nbsp;We build two embedding apps based on our port of WebKit:<br>
test_shell and chrome. &nbsp;The former is like a mash-up of DRT and Spinneret.<br>
</blockquote>
<br>
OK; that appears to disagree with what Amanda said above.<br>
</blockquote>
<br>
Not really--our architectural changes were made to support<br>
multiprocess rendering, but they do not require it. &nbsp;test_shell still<br>
renders into a bitmap and then blits that to the OS window, it just<br>
does it all within a single process. &nbsp;But all of the drawing, event<br>
handling, geometry management, etc. go through the same set of host &amp;<br>
delegate interfaces that the multiprocess app does, rather than<br>
talking to the top level view(s) directly. &nbsp;The implementations of<br>
those interfaces in test_shell are just a lot simpler.<br>
</blockquote>
<br></div></div>
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 &quot;multi-process&quot; 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.<br>
</blockquote></div><br><div>A more succinct description for our rendering model might be something that reflects the fact that we are rendering to a memory buffer. &nbsp;We still use elements of the native graphics engine to do so. &nbsp;For example, even though we use Skia, we still use GDI to render text. &nbsp;On Mac, the balance between Skia and CG is different for various reasons. &nbsp;Amanda can speak to those differences better than me. &nbsp;We also reach out to the OS to access the native theme rendering engine, again just to have it paint into our memory buffer.</div>
<div><br></div><div>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.</div>
<div><br></div><div>(The big exception is still plugins, of course! &nbsp;As I mentioned elsewhere, we delegate those out to the embedder so that WebCore doesn&#39;t really deal with them directly. &nbsp;That is needed to support out-of-process plugins.)</div>
<div><br></div><div>-Darin</div></div>