[chromium-dev] Re: Fwd: [chromium-dev] Re: OS X IPC Design doc
To my knowledge, we don't have specific speed requirements, so no, there's no simple test that could show whether or not a given mechanism is fast enough. However, as I noted yesterday, it should be fairly straightforward to extract some performance data from the windows build, which would at least give us information on the distribution of sizes and latencies to use as a point of comparison. --Amanda On Thu, Nov 13, 2008 at 9:54 AM, Dan Kegel [EMAIL PROTECTED] wrote: But without knowing what is fast enough, it's hard to make intelligent tradeoffs. It could well be that pipes are fast enough. It shouldn't be too hard to prove or disprove that, should it? -- --Amanda I'll say it again for the logic impaired. --Larry Wall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: [chromium-dev] Re: OS X IPC Design doc
Right on... We can definitely support custom implementations for each platform, and we should do that if it significantly lowers barriers and helps us get to a better product. I think it was reasonable to talk about sharing code here between Linux and OSX because this code, while small and contained, is something, much like the MessageLoop, that will invariably get a lot of attention due to very subtle issues (given our experience on Windows). It would be nice to share that kind of effort whenever it makes sense. -Darin On Thu, Nov 13, 2008 at 8:18 AM, Amanda Walker [EMAIL PROTECTED] wrote: Sure. But lets also put this into perspective. This is a small bit of code that is already wrapped by an API to hide the implementation details (which themselves already differ between platforms). It should be difficult neither to implement nor to re-implement as conditions or requirements change (or in this case, simply become clearer). Both the costs and the benefits of either sharing or not sharing the implementation between Mac OS X and Linux are low. So we're approaching a bikeshed discussion, where the people with a lot of Mac experience see one clear answer, and the people with a lot of Linux experience see another. A couple people raised questions about the performance differential that some of us asserted in favor of mach IPC, so we went at generated some objective data (which was quite worthwhile). The other factors you mention also point to using mach IPC on the Mac--the ease of exchanging shared memory objects is in fact where its speed advantage comes from for larger messages. For waitable events, there's no direct equivalent to a Windows waitable object, so some other mechanism (semaphores, condition variables, etc.) will be necessary on both the Mac and Linux, regardless. I'd like to not get into a long, drawn-out design by parade discussion on such a small module. If there are known requirements that haven't made it into the Windows code or design docs that someone could summarize, that would be great and will help all of us. In the absence of that, I think that going on general principles and prior experience, and doing an implementation bake-off , is a reasonable course of action. --Amanda On Thu, Nov 13, 2008 at 1:12 AM, Darin Fisher [EMAIL PROTECTED] wrote: Keep in mind that pipes are not really the fastest IPC mechanism for windows. Mike had a much faster shared memory based solution. However, we found that the pipe based solution was easiest to integrate with the sandbox, and it was also fast enough such that other factors outweigh the performance differential between the two mechanisms. I guess what I'm saying is that we should probably not get too caught up in the performance differences here unless we think that is the dominant factor. Other things might be more important such as how easy it is to exchange shared memory and waitable events (the equivalent of a windows event object). -Darin On Wed, Nov 12, 2008 at 7:07 PM, Jeremy Moskovich [EMAIL PROTECTED] wrote: Hi Dan, Looking at the current IPC behavior is definitely on my list of things to do. I don't think that should change the interpretation of the data though. According to our measurements, Mach messages are always faster *. So the question becomes, not is it faster, but by how many orders of magnitude. Best regards, Jeremy * Using inline messages there's a break even at some point as the cost of copying data takes over, but as discussed we can use OOL messages to get really fast (~30uSec) constant time sends for messages 5K. On Wed, Nov 12, 2008 at 5:08 PM, Dan Kegel [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 4:46 PM, Jeremy Moskovich [EMAIL PROTECTED] wrote: We ran some benchmarks of Mach ports vs FIFOs on OSX, you can find the results in the Performance Considerations section of the Design doc. I don't see any measurements showing what typical Chrome IPC traffic looks like. Without that, it's hard to interpret your results. If I missed it, please point me to it. -- --Amanda I have never seen anything fill up a vacuum so fast and still suck. --Rob Pike on the X Win... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: [chromium-dev] Re: OS X IPC Design doc
On Thu, Nov 13, 2008 at 12:46 PM, Darin Fisher [EMAIL PROTECTED] wrote: Right on... We can definitely support custom implementations for each platform, and we should do that if it significantly lowers barriers and helps us get to a better product. I think it was reasonable to talk about sharing code here between Linux and OSX because this code, while small and contained, is something, much like the MessageLoop, that will invariably get a lot of attention due to very subtle issues (given our experience on Windows). It would be nice to share that kind of effort whenever it makes sense. Oh, very much agreed. And it never hurts to confirm assumptions. Jeremy's benchmark did turn up some very interesting desktop/laptop differences, which point up areas we may want to keep an eye on: effects of multiple CPU cores, memory bandwidth, etc. --Amanda --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] building optimized on linux
Build optimized binaries: hammer --mode=opt Hammer/test_shell See what flags are available: hammer --help I expect this to break occasionally, since we tend to fall afoul of the strict aliasing rule in various places. I added some TODO(port)s about it. Also, previous caveats about looking at test_shell performance still apply (e.g. scrolling performance hasn't been optimized). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedding Chromium
If anyone is interested in helping me, I would like to venture to start one then. On Nov 13, 7:14 pm, Darin Fisher [EMAIL PROTECTED] wrote: There is no existing COM-style Chrome component that can be easily embedded for web rendering. -Darin On Thu, Nov 13, 2008 at 4:05 PM, thetrueaplus [EMAIL PROTECTED]wrote: Is there a way to embed Chromium as a component in a Win32 or MFC application? I would like to build it into my application so that I could use it as a help browser. If there is no component for embeding Chromium into applications, I believe we should start building one. I would like to help so I can learn how WebKit and other things work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Consolidating our platform-specific layout test results
Thanks for cleaning this up, Pam!!! On Thu, Nov 13, 2008 at 4:57 PM, Pam Greene [EMAIL PROTECTED] wrote: Today I got our custom (platform-specific) layout test results mostly straightened out. (Apologies for the large-ish sync that will cause.) If you re-baseline tests, please keep reading. We no longer keep kjs or common results. The layout_test_results directory will be gone within the hour. All platform baselines, whether they're text, images, or checksums, are now in webkit/layout_tests/platform/chromium-win/. (We can create chromium-mac/ and others as needed.) Eventually I, or someone else, will adjust run_webkit_tests.py so its --new-baseline option puts files into the platform-specific directory by default, but for now, please remember to specify the new path. - Pam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Consolidating our platform-specific layout test results
Pam++! :DG On Thu, Nov 13, 2008 at 6:02 PM, Darin Fisher [EMAIL PROTECTED] wrote: Thanks for cleaning this up, Pam!!! On Thu, Nov 13, 2008 at 4:57 PM, Pam Greene [EMAIL PROTECTED] wrote: Today I got our custom (platform-specific) layout test results mostly straightened out. (Apologies for the large-ish sync that will cause.) If you re-baseline tests, please keep reading. We no longer keep kjs or common results. The layout_test_results directory will be gone within the hour. All platform baselines, whether they're text, images, or checksums, are now in webkit/layout_tests/platform/chromium-win/. (We can create chromium-mac/ and others as needed.) Eventually I, or someone else, will adjust run_webkit_tests.py so its --new-baseline option puts files into the platform-specific directory by default, but for now, please remember to specify the new path. - Pam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedding Chromium
Hi Darin, On Thu, Nov 13, 2008 at 7:14 PM, Darin Fisher [EMAIL PROTECTED] wrote: There is no existing COM-style Chrome component that can be easily embedded for web rendering. -Darin Do you (or Google, or Chromium) have a preference when it comes to COM frameworks? It would be nice to have an ActiveX control eventually accepted as part of the Chromium code base. Would something implemented using pure COM C++ and MIDL have a better chance of acceptance than something implemented using ATL, for instance? Regards, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedding Chromium
On Thu, Nov 13, 2008 at 11:42 PM, Darin Fisher [EMAIL PROTECTED] wrote: I'm familiar with straight COM C++ and MIDL and can imagine how that might look, but I don't know enough about the issues with ATL. I've heard some objections to ATL in the past. At any rate, it'd be good to see a more detailed proposal before committing to anything. In general, I think it could be reasonable for the chromium repository to be home to other projects derived from the chromium source. Ok, let's talk about possible designs :-) I think it would be nice to leverage chromium's multi-process architecture in a COM context. The chromium browser process would be hosted in a local COM server executable. Each browser window requested by the container application (and created by the COM server) would be a separate webcore process managed by the browser process, similar to how tabs are handled in Chrome. The COM runtime could transparently handle LRPC marshaling between the container application and the COM browser process, and the browser process could communicate with the webcore process using IPC per the usual methods. If a webcore process crashes then neither the container application nor the browser process is taken down as a result. We could even use the same sad tab graphics (if that's not IP infringement) and allow the webcore process to be reloaded without necessarily requiring intervention from the container application. -Darin Regards, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: sent from test shell on Linux!
wow 2008/11/14 AJS [EMAIL PROTECTED] Excellent news! Looks about time for me to start playing with that Linux build. On Nov 11, 4:02 pm, Dan Kegel [EMAIL PROTECTED] wrote: Dude, gmail works in the test shell on Linux! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Embedding Chromium
Marshall Greenblatt [EMAIL PROTECTED] wrote: I think it would be nice to leverage chromium's multi-process architecture in a COM context. The chromium browser process would be hosted in a local COM server executable. Each browser window requested by the container application (and created by the COM server) would be a separate webcore process managed by the browser process... The COM runtime could transparently handle LRPC marshaling between the container application and the COM browser process, and the browser process could communicate with the webcore process using IPC per the usual methods. Sounds good-ish to me. Go forth and code a demo...? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
