On Oct 28, 2009, at 7:21 AM, Mark Mentovai wrote:
> When I benchmarked this a few months ago on a fairly ordinary Mac, it > took nearly 100ms from the time that the browser started a renderer to > the time that the renderer was ready to service requests. A decent > chunk of that is load time and pre-main initialization in system > libraries. It's beyond our control, but there's no reason we can't > make it happen sooner. Unfortunately, it's nearly impossible to continue a forked process on OS X if it uses any higher-level (above POSIX) APIs. The main problem is that Mach ports can't be replicated across the fork, so if any ports were already open, they'll all be bogus in the new process. And all kinds of stuff in the OS is done via IPC across Mach ports, most significantly to the window server. It might be possible to create a forkable renderer by doing as much setup as possible without actually invoking any OS X-specific APIs, then initializing the rest after the fork. I don't know if this has ever been tried, or if it would provide sufficient improvement to be worth the effort. I would expect that rendering speed would suffer somewhat due to the extra layer of pixel buffering incurred by Chrome's renderers. Has anyone experimented with giving the renderer access to a child window of the browser to allow it to draw more directly? —Jens --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
