On Sep 24, 2008, at 10:10 PM, Amanda Walker wrote: > On Wed, Sep 24, 2008 at 7:25 PM, Maciej Stachowiak <[EMAIL PROTECTED]> > 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. Regards, Maciej _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev