[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
I'm sorry for the late response, I've been quite busy last week. 2009/4/27 Amanda Walker ama...@chromium.org: Hacky is fairly subjective: are there particular things about the existing implementation that bother you? Currently they are different for each OS because each OS has its own issues surrounding launching multiple instances of the browser, different mechanisms for handling incoming requests from the OS to open web pages, and so on. 2009/4/28 stoyan sto...@chromium.org: Well, on Windows code looks racy, does not work well across multiple desktops, and probably will create troubles accessing userdata when same instance is running in different terminal sessions (with same user account). The problem with quick, baroque source code is that usually there are lots of corner cases. I have rethought the idea after your comments, and there are several problems with current Windows implementation: 1. As Stoyan mentioned, window messaging does not work across multiple desktops. Therefore it doesn't work across multiple terminal sessions. Consider the following use case: A user has a version of Windows that allows multiple consequent terminal sessions on his PC, and leaves Chrome opened. Then he opens a session from his laptop and launches Chrome. Preferred result is opening a new window in the second session, but AFAIK it's impossible for the Chrome master process to open a window in a different window station. Hence quite a lot of changes are required for this to function, like delegating handling of a widget to the newly created process, and these fall out of the scope of this idea. But current ProcessSingleton will just fail to detect another Chrome instance and crash or show weird behavior. If it worked, we could at least show some message telling user that running Chrome from different terminal sessions is not yet implemented. So IMHO ProcessSingleton should not rely on window messages, that are by definition bound to one window station. 2. Another problem with Windows implementation (maybe not really a problem) is that it guards Chrome against being launched with the same (luckily, case-insensitive) user data dir path. This is a fundamental problem, because ProcessSingleton should protect not only against being launched with the same path, but against actually using the same dir twice (one directory can be addressed with different paths, because of links and mounting, even on Windows NTFS partitions). Well, I think that without user intervention a situation that exploits this cannot be created, so it may be considered as ok, but it's still a problem that IMHO should be fixed. Because of that, I suggest two ideas: 1. Do almost as I suggested before, but instead of Chrome PID use a GUID, and write it only once, on the first run. This GUID will let us distinguish data dirs without need to rely on their path. So at normal launch it will be one additional disk read (just several bytes) and some IPC. If you think that we can't afford even one extra disk read, then think about my second idea: 2. If problem #2 is not really a problem, then instead of GUID or PID we can just use some hash from user data dir path as channel_id, and make no disk operations at all. This is by no means worse than current implementation and solves the first problem. However, this is only a partial solution. As an additional benefit, ProcessSingleton becomes what it was meant to be - a facility to ensure that only one instance with given data dir is running. Opening new URLs and getting browser PID will be just IPC messages, without custom protocol parsing or some extra quirks in ProcessSingleton code. 2009/4/27 Amanda Walker ama...@chromium.org: Simply eliminating differences between per-platform implementations is not necessarily a large benefit by itself, since the amount of code is small and concerns an area where the three platforms behave quite differently. I do agree with this, but it's not only for eliminating differences between implementations, but also to improve them. There is already quite a lot of platform-specific code in IPC, and it can handle differences quite well. The only remaining thing is disabling this functionality completely on Mac when not running tests, and this can be handled by one 'if'. As for racyness, this can also be improved. Current implementation was racy because singleton was created with some delay after checking that no Chrome process existed. That was a bug, and that was fixed by adding singleton creation in constructor. It isn't actually atomic, but should work well. Creating named pipe is atomic operation now (FILE_FLAG_FIRST_PIPE_INSTANCE), however, creating UNIX domain socket is not. So this may also be improved in order to avoid race conditions. Nikita Ofitserov --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe:
[chromium-dev] Re: Setting Default Search Engine
On Fri, May 1, 2009 at 11:41 PM, stylo~ scootrs@gmail.com wrote: Also, the name it defaults to for the added search engine is wrong. It uses the url, not the name in the xml file. That is by design. tab-to-search keys off url. Also, doesn't seem a very good system even if it does work. How do you actually find/select the search engine you want to use? Yahoo is installed; I haven't a clue how to select it without setting it as the default. I JUST found out you have to type the base url with .com to kick in the search system because of the default keyword being the url. If you continue to use the keyword you should get autocompleted to it and tab-to-search should kick in immediately. There was a bug such that if you only used tab-to-search on urls the url would not get autocompleted. See http://code.google.com/p/chromium/issues/detail?id=3633 for details. This was only recently fixed and is not in the stable channel. Hmmm. First thought is it is a bit awkward and limiting, with excess typing, just to avoid a search box when you've got oodles of space to add one on the right. Have to try for awhile, I guess. Perhaps better to use the search engine name and have them all (if more than one) appear for selection when typing in anything to do with that name. Shouldn't need the base url with .com to invoke it, and shouldn't block more than one. If you let the OSDD pick the name, then it doesn't necessarily align with the url. Consider you are browsing to some random sight and we add a search provider. If we didn't use the url, how would you know what name the search provider was added under? The current system was designed around the user not having to do anything. If we know the site supports search, we'll show tab-to-search. Additionally we'll auto discover whether the site supports tab-to-search for you. There is a bug on making this easier for sites that don't support OSDD. See http://crbug.com/9732 for details. Also remember that you can always change the name of the search provider. Right click on the omnibox and choose 'Edit search engines...'. -Scott --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
Thanks for elaborating. So if we look at it another way, there are several different problems that ProcessSingleton is currently used to solve: - Prevent multiple instances of Chromium from referring to the same profile/user data directory. In the general sense, what we need here is a way to acquire and test locks on data directories. This is a cross-platform requirement: all platforms should be able to launch instances of Chromium in different user sessions with different user data / profiles (in order to support fast user switching on Mac Windows, single Linux boxes with multiple people logged in, etc. Currently, ProcessSingleton really only solves this by accident. It seems cleaner to me to meet this requirement with an explicit mechanism: Something like a ProfileLock or DirectoryLock, for example. This also gives a way to ease this requirement if someone fixes the concurrent-access problem, without affecting other uses of ProcessSingleton. - Testing, since a number of tests are not multiple-instance safe. I would describe this as a defect in those tests or the test framework, which again ProcessSingleton only mitigates by accident. I would prefer we address this by fixing the tests and/or test scripts so that we can indeed run tests in parallel without worrying about them stepping on each other. We have a strong desire to reduce our build cycle time, of which having to run tests serially instead of in parallel is a large component. - Within a user session, ensuring that requests to open URLs get processed by a currently running instance of Chromium instead of launching a new one. This is where platform differences are strongest, and is ProcessSingleton's main function. Registering properties on windows or the like for Windows and X11 seems cleaner to me than putting breadcrumbs into the file system, since window properties are inherently tied to the user session and to an active instance of the application (and thus do not need to be cleaned up on a crash, etc.). On the Mac, this function is provided by the OS, so there's no need for Chromium to duplicate it. --Amanda On Tue, May 5, 2009 at 12:27 PM, Никита Офицеров himi...@gmail.com wrote: I'm sorry for the late response, I've been quite busy last week. 2009/4/27 Amanda Walker ama...@chromium.org: Hacky is fairly subjective: are there particular things about the existing implementation that bother you? Currently they are different for each OS because each OS has its own issues surrounding launching multiple instances of the browser, different mechanisms for handling incoming requests from the OS to open web pages, and so on. 2009/4/28 stoyan sto...@chromium.org: Well, on Windows code looks racy, does not work well across multiple desktops, and probably will create troubles accessing userdata when same instance is running in different terminal sessions (with same user account). The problem with quick, baroque source code is that usually there are lots of corner cases. I have rethought the idea after your comments, and there are several problems with current Windows implementation: 1. As Stoyan mentioned, window messaging does not work across multiple desktops. Therefore it doesn't work across multiple terminal sessions. Consider the following use case: A user has a version of Windows that allows multiple consequent terminal sessions on his PC, and leaves Chrome opened. Then he opens a session from his laptop and launches Chrome. Preferred result is opening a new window in the second session, but AFAIK it's impossible for the Chrome master process to open a window in a different window station. Hence quite a lot of changes are required for this to function, like delegating handling of a widget to the newly created process, and these fall out of the scope of this idea. But current ProcessSingleton will just fail to detect another Chrome instance and crash or show weird behavior. If it worked, we could at least show some message telling user that running Chrome from different terminal sessions is not yet implemented. So IMHO ProcessSingleton should not rely on window messages, that are by definition bound to one window station. 2. Another problem with Windows implementation (maybe not really a problem) is that it guards Chrome against being launched with the same (luckily, case-insensitive) user data dir path. This is a fundamental problem, because ProcessSingleton should protect not only against being launched with the same path, but against actually using the same dir twice (one directory can be addressed with different paths, because of links and mounting, even on Windows NTFS partitions). Well, I think that without user intervention a situation that exploits this cannot be created, so it may be considered as ok, but it's still a problem that IMHO should be fixed. Because of that, I suggest two ideas: 1. Do almost as I suggested before, but instead of Chrome PID
[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
I agree with the earlier argument about not larding startup with things like writing new files to id the coming-up Chrome to late-coming instances. An alternative might be to acquire a lock to protect the profile, and write an id asynchronously after startup. The late-coming instance would see the lock and wait for the id to appear (or the lock to evaporate). This does mean the late-coming instance will have to wait sometimes, but in those cases the coming-up instance presumably is not ready to respond to requests anyhow. On Mac and Linux, all we need for the lock is an agreed-upon open file descriptor, which should be easy to find. We could acquire the lock in parallel with other startup activity which doesn't modify system state. -scott On Tue, May 5, 2009 at 10:16 AM, Amanda Walker ama...@chromium.org wrote: Thanks for elaborating. So if we look at it another way, there are several different problems that ProcessSingleton is currently used to solve: - Prevent multiple instances of Chromium from referring to the same profile/user data directory. In the general sense, what we need here is a way to acquire and test locks on data directories. This is a cross-platform requirement: all platforms should be able to launch instances of Chromium in different user sessions with different user data / profiles (in order to support fast user switching on Mac Windows, single Linux boxes with multiple people logged in, etc. Currently, ProcessSingleton really only solves this by accident. It seems cleaner to me to meet this requirement with an explicit mechanism: Something like a ProfileLock or DirectoryLock, for example. This also gives a way to ease this requirement if someone fixes the concurrent-access problem, without affecting other uses of ProcessSingleton. - Testing, since a number of tests are not multiple-instance safe. I would describe this as a defect in those tests or the test framework, which again ProcessSingleton only mitigates by accident. I would prefer we address this by fixing the tests and/or test scripts so that we can indeed run tests in parallel without worrying about them stepping on each other. We have a strong desire to reduce our build cycle time, of which having to run tests serially instead of in parallel is a large component. - Within a user session, ensuring that requests to open URLs get processed by a currently running instance of Chromium instead of launching a new one. This is where platform differences are strongest, and is ProcessSingleton's main function. Registering properties on windows or the like for Windows and X11 seems cleaner to me than putting breadcrumbs into the file system, since window properties are inherently tied to the user session and to an active instance of the application (and thus do not need to be cleaned up on a crash, etc.). On the Mac, this function is provided by the OS, so there's no need for Chromium to duplicate it. --Amanda On Tue, May 5, 2009 at 12:27 PM, Никита Офицеров himi...@gmail.com wrote: I'm sorry for the late response, I've been quite busy last week. 2009/4/27 Amanda Walker ama...@chromium.org: Hacky is fairly subjective: are there particular things about the existing implementation that bother you? Currently they are different for each OS because each OS has its own issues surrounding launching multiple instances of the browser, different mechanisms for handling incoming requests from the OS to open web pages, and so on. 2009/4/28 stoyan sto...@chromium.org: Well, on Windows code looks racy, does not work well across multiple desktops, and probably will create troubles accessing userdata when same instance is running in different terminal sessions (with same user account). The problem with quick, baroque source code is that usually there are lots of corner cases. I have rethought the idea after your comments, and there are several problems with current Windows implementation: 1. As Stoyan mentioned, window messaging does not work across multiple desktops. Therefore it doesn't work across multiple terminal sessions. Consider the following use case: A user has a version of Windows that allows multiple consequent terminal sessions on his PC, and leaves Chrome opened. Then he opens a session from his laptop and launches Chrome. Preferred result is opening a new window in the second session, but AFAIK it's impossible for the Chrome master process to open a window in a different window station. Hence quite a lot of changes are required for this to function, like delegating handling of a widget to the newly created process, and these fall out of the scope of this idea. But current ProcessSingleton will just fail to detect another Chrome instance and crash or show weird behavior. If it worked, we could at least show some message telling user that running Chrome from different terminal sessions is not yet implemented. So IMHO
[chromium-dev] Re: Need help in finding a performance problem...
Salut, I've been trying to locally collect performance data to confirm whether this was a good enough improvement or not and I can't seem to get consistent enough results on my machine to draw a conclusion... Some things look faster, and others look slower, but I sometimes get faster results with the resize corner enabled, compare to disabled (which doesn't really make sense)... So I don't think I can rely on these numbers... So I decided that I will go through with the code review of the changes, and if Adam and Darin are happy with it, I will commit and monitor the performance dashboard to see how it goes there... If it goes bad, I'll revert... And if it goes well... I'll scream my happiness as loud as I can (and those who know me a bit, know that I CAN be pretty LOUD!!! ;-)... BYE MAD On Fri, May 1, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Fri, May 1, 2009 at 9:06 AM, Marc-Andre Decoste m...@chromium.org wrote: Salut Evan, thanks, I will do that... And the results seems better than I initially thought... If you get performance improvements, please do commit :) Evan is correct that Darin needs to check this over, but I'll happy code review everything where I can. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need help in finding a performance problem...
I was able to get very consistent results before with just TestShell on Mac running the mozilla page-cycler test locally. Would using TestShell instead of Chromium help, or do you want me to try your patch on Mac? Let me know. On Tue, May 5, 2009 at 2:08 PM, Marc-Andre Decoste m...@chromium.org wrote: Salut, I've been trying to locally collect performance data to confirm whether this was a good enough improvement or not and I can't seem to get consistent enough results on my machine to draw a conclusion... Some things look faster, and others look slower, but I sometimes get faster results with the resize corner enabled, compare to disabled (which doesn't really make sense)... So I don't think I can rely on these numbers... So I decided that I will go through with the code review of the changes, and if Adam and Darin are happy with it, I will commit and monitor the performance dashboard to see how it goes there... If it goes bad, I'll revert... And if it goes well... I'll scream my happiness as loud as I can (and those who know me a bit, know that I CAN be pretty LOUD!!! ;-)... BYE MAD On Fri, May 1, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Fri, May 1, 2009 at 9:06 AM, Marc-Andre Decoste m...@chromium.org wrote: Salut Evan, thanks, I will do that... And the results seems better than I initially thought... If you get performance improvements, please do commit :) Evan is correct that Darin needs to check this over, but I'll happy code review everything where I can. AGL -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Tab-modal dialogs on the Mac
Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
I'd be worried about flashing/jankiness using a real sheet, but a child window pinned to the top edge of the tab with the right transitions might work nicely. There's also some stuff Jeremy was doing in Gears that involved doing interesting things with login prompts that may (or may not) be relevant. It would certainly be nice to keep things tab-modal, even though Cocoa doesn't really grok that idea. --Amanda On Tue, May 5, 2009 at 5:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
One question that's been on my mind is how important it is for the dialog to be draggable. We can't simultaneously do (normal window title bar) and (constrained to a tab) on Linux. A Mac-style sheet would be consistent with other tab-related UI like the find bar. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
I don't think it's important. It actually feels a little weird that it is. On Tue, May 5, 2009 at 2:46 PM, Evan Martin e...@chromium.org wrote: One question that's been on my mind is how important it is for the dialog to be draggable. We can't simultaneously do (normal window title bar) and (constrained to a tab) on Linux. A Mac-style sheet would be consistent with other tab-related UI like the find bar. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
I don't think that's important. Avi On Tue, May 5, 2009 at 2:46 PM, Evan Martin e...@chromium.org wrote: One question that's been on my mind is how important it is for the dialog to be draggable. We can't simultaneously do (normal window title bar) and (constrained to a tab) on Linux. A Mac-style sheet would be consistent with other tab-related UI like the find bar. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
I need to play with this. It's pretty obvious how this would have been done in Carbon (where you can attach/detach sheets with abandon) but it's less obvious how to do this in Cocoa, where -[NSWindow attachedSheet] implies just one sheet per window, and it's not obvious how to attach a sheet to a window without also running an event loop. The alternative is to create a window in sheet style but attach it ourselves. Then the question is faking the reveal effect. Once again, it's obvious how to do it in Carbon (WindowTransitionEffect) but less so in Cocoa. If anyone has immediate answers let me know. Otherwise I'll see what I can wrestle up. Avi On Tue, May 5, 2009 at 2:43 PM, Amanda Walker ama...@chromium.org wrote: I'd be worried about flashing/jankiness using a real sheet, but a child window pinned to the top edge of the tab with the right transitions might work nicely. There's also some stuff Jeremy was doing in Gears that involved doing interesting things with login prompts that may (or may not) be relevant. It would certainly be nice to keep things tab-modal, even though Cocoa doesn't really grok that idea. --Amanda On Tue, May 5, 2009 at 5:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need help in finding a performance problem...
That would be awsome... I just uploaded the patch here: http://codereview.chromium.org/108040 BYE MAD On Tue, May 5, 2009 at 5:14 PM, Mike Pinkerton pinker...@chromium.orgwrote: I was able to get very consistent results before with just TestShell on Mac running the mozilla page-cycler test locally. Would using TestShell instead of Chromium help, or do you want me to try your patch on Mac? Let me know. On Tue, May 5, 2009 at 2:08 PM, Marc-Andre Decoste m...@chromium.org wrote: Salut, I've been trying to locally collect performance data to confirm whether this was a good enough improvement or not and I can't seem to get consistent enough results on my machine to draw a conclusion... Some things look faster, and others look slower, but I sometimes get faster results with the resize corner enabled, compare to disabled (which doesn't really make sense)... So I don't think I can rely on these numbers... So I decided that I will go through with the code review of the changes, and if Adam and Darin are happy with it, I will commit and monitor the performance dashboard to see how it goes there... If it goes bad, I'll revert... And if it goes well... I'll scream my happiness as loud as I can (and those who know me a bit, know that I CAN be pretty LOUD!!! ;-)... BYE MAD On Fri, May 1, 2009 at 1:00 PM, Adam Langley a...@chromium.org wrote: On Fri, May 1, 2009 at 9:06 AM, Marc-Andre Decoste m...@chromium.org wrote: Salut Evan, thanks, I will do that... And the results seems better than I initially thought... If you get performance improvements, please do commit :) Evan is correct that Darin needs to check this over, but I'll happy code review everything where I can. AGL -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need help in finding a performance problem...
On Tue, May 5, 2009 at 3:00 PM, Marc-Andre Decoste m...@chromium.org wrote: That would be awsome... I just uploaded the patch here: http://codereview.chromium.org/108040 At a high level, you're using one TransportDIB per rectangle, but it should be one per message (with multiple rects worth of image data inside). You can't really use any benchmarking results while this is the case. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
The sheet approach sounds fine to me for Mac dialogs. Note also that anything you do should not become app-modal when the tab is selected. -Ben On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
The sheet approach or the sheet-look approach? I like the sheet-look approach, but Cocoa sheets are window-modal, which I don't think is all that cool given how we use tabs (or want to use tabs). Mark Ben Goodger (Google) wrote: The sheet approach sounds fine to me for Mac dialogs. Note also that anything you do should not become app-modal when the tab is selected. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need help in finding a performance problem...
OK, I'll make the change... Interestingly, this was my original idea, but I misunderstood your initial suggestions thinking you preferred an array of bitmaps too... I'll send a notice once I uploaded a new patch... Thanks! BYE MAD On Tue, May 5, 2009 at 6:08 PM, Adam Langley a...@chromium.org wrote: On Tue, May 5, 2009 at 3:00 PM, Marc-Andre Decoste m...@chromium.org wrote: That would be awsome... I just uploaded the patch here: http://codereview.chromium.org/108040 At a high level, you're using one TransportDIB per rectangle, but it should be one per message (with multiple rects worth of image data inside). You can't really use any benchmarking results while this is the case. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
I remember Nicholas saying he thought it'd be possible to fabricate a non-modal sheet like thing. -Ben On Tue, May 5, 2009 at 3:25 PM, Mark Mentovai m...@chromium.org wrote: The sheet approach or the sheet-look approach? I like the sheet-look approach, but Cocoa sheets are window-modal, which I don't think is all that cool given how we use tabs (or want to use tabs). Mark Ben Goodger (Google) wrote: The sheet approach sounds fine to me for Mac dialogs. Note also that anything you do should not become app-modal when the tab is selected. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab-modal dialogs on the Mac
Yeah, that'd be awesome. Ben Goodger wrote: I remember Nicholas saying he thought it'd be possible to fabricate a non-modal sheet like thing. -Ben On Tue, May 5, 2009 at 3:25 PM, Mark Mentovai m...@chromium.org wrote: The sheet approach or the sheet-look approach? I like the sheet-look approach, but Cocoa sheets are window-modal, which I don't think is all that cool given how we use tabs (or want to use tabs). Mark Ben Goodger (Google) wrote: The sheet approach sounds fine to me for Mac dialogs. Note also that anything you do should not become app-modal when the tab is selected. On Tue, May 5, 2009 at 2:40 PM, Avi Drissman a...@google.com wrote: Having signed up for the login dialog, I'm seeing that it's a pretty interesting subject. If you try out a page with HTTP auth, you'll see that you get what looks like a dialog for the username and password. But if you click around, you find that you can switch tabs, and that the dialog is tab-modal. In fact, the UI test has a test (LoginPromptTest.TestTwoAuths) to make sure that you can have two auths going on at once. I was thinking about doing this as a sheet, but that's window-modal and of less functionality. I can play games with dialogs (making them child windows and/or hiding/showing along with the tab) but that gets to be less Mac/like. As I type this I wonder if we can get a sheet to come down under the tab bar and hide/show it with the tab. Would that be good UI-wise? And of course, I'd probably retrofit the file picker to do that too. Thoughts? Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] custom_deps [src/webkit/data/layout_tests/LayoutTests: None] has no effort
Hi all,
I trid to get the chrome source code via the gclient tools.
Due to low-bandwidth, i did not want to sync the layout_tests
code and added the filter line
src/webkit/data/layout_tests: None,
into the .gclient file.
But it seems does not work, it still sync the layout_tests code
from the depot after issuing gclient sync command.
the steps i synced code as following:
1. issuing command : gclient config http://src.chromium.org/svn/trunk/src;
2. modify the .gclient file as following:
# An element of this array (a solution) describes a repository
directory
# that will be checked out into your working copy. Each solution may
# optionally define additional dependencies (via its DEPS file) to be
# checked out alongside the solution's directory. A solution may also
# specify custom dependencies (via the custom_deps property) that
# override or augment the dependencies specified by the DEPS file.
# If a safesync_url is specified, it is assumed to reference the
location of
# a text file which contains nothing but the last known good SCM
revision to
# sync against. It is fetched if specified and used unless --head is
passed
solutions = [
{ name: src,
url : http://src.chromium.org/svn/trunk/src;,
custom_deps : {
src/webkit/data/layout_tests: None,
# To use the trunk of a component instead of what's in DEPS:
#component: https://svnserver/component/trunk/;,
# To exclude a component from your working copy:
#data/really_large_component: None,
},
safesync_url:
}
]
3. issuing the command gclient sync.
i am very puzzled of why, can any one help me out?
Thanks
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] what class should I derive from if i want to create an invisible proxy windows?
what class should I derive from if i want to create an invisible proxy windows? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: custom_deps [src/webkit/data/layout_tests/LayoutTests: None] has no effort
On Mon, May 4, 2009 at 1:45 AM, chrome chromeorfire...@gmail.com wrote: Hi all, I trid to get the chrome source code via the gclient tools. Due to low-bandwidth, i did not want to sync the layout_tests code and added the filter line src/webkit/data/layout_tests: None, into the .gclient file. http://dev.chromium.org/developers/how-tos/get-the-code has a different path in its instructions. Is it incorrect? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Windows 7 thumbnail previews for tabs (+ other new features)
On Mon, May 4, 2009 at 5:25 PM, Leith le...@leithalweapon.geek.nz wrote: Has anyone started work on integrating Chrome with the new thumbnail previews in Windows 7? You should probably search the bug tracker for relevant bugs for this. Any information would presumably be there. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
On Mon, May 4, 2009 at 11:08 AM, jack js2...@gmail.com wrote: Dear experts, I am recently playing around Chrome extension development Sweet! does chrome has an add-on preference system? I think a preference system is an essential component for an add-on ecosystem. What I mean is something like Firefox's Components.interfaces.nsIPrefBranch: https://developer.mozilla.org/En/Code_snippets/Preferences e.g., for a gmail addon, a user should be able to save his/her user/ pswd info. WRT to add-on development, how/where to support this? Our idea is that in most cases developers will use HTML5 LocalStorage for this, which will be available to all web pages (including extensions) by default. However, HTML5 LocalStorage is not yet implemented for Chrome, so it doesn't show up for extensions either. There are people working on this, though, and we hope to have it available Real Soon Now. Note that using cookies, as Peter suggests, won't work either. We have purposely decided to not enable cookies for extensions since the concept doesn't really make sense (cookies are really designed for live web pages that interact with servers). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
On May 5, 10:44 am, Scott Hess sh...@chromium.org wrote: I agree with the earlier argument about not larding startup with things like writing new files to id the coming-up Chrome to late-coming instances. An alternative might be to acquire a lock to protect the profile, and write an id asynchronously after startup. The late-coming instance would see the lock and wait for the id to appear (or the lock to evaporate). This does mean the late-coming instance will have to wait sometimes, but in those cases the coming-up instance presumably is not ready to respond to requests anyhow. On Mac and Linux, all we need for the lock is an agreed-upon open file descriptor, which should be easy to find. We could acquire the lock in parallel with other startup activity which doesn't modify system state. -scott On Tue, May 5, 2009 at 10:16 AM, Amanda Walker ama...@chromium.org wrote: Thanks for elaborating. So if we look at it another way, there are several different problems that ProcessSingleton is currently used to solve: - Prevent multiple instances of Chromium from referring to the same profile/user data directory. In the general sense, what we need here is a way to acquire and test locks on data directories. This is a cross-platform requirement: all platforms should be able to launch instances of Chromium in different user sessions with different user data / profiles (in order to support fast user switching on Mac Windows, single Linux boxes with multiple people logged in, etc. Currently, ProcessSingleton really only solves this by accident. It seems cleaner to me to meet this requirement with an explicit mechanism: Something like a ProfileLock or DirectoryLock, for example. This also gives a way to ease this requirement if someone fixes the concurrent-access problem, without affecting other uses of ProcessSingleton. - Testing, since a number of tests are not multiple-instance safe. I would describe this as a defect in those tests or the test framework, which again ProcessSingleton only mitigates by accident. I would prefer we address this by fixing the tests and/or test scripts so that we can indeed run tests in parallel without worrying about them stepping on each other. We have a strong desire to reduce our build cycle time, of which having to run tests serially instead of in parallel is a large component. - Within a user session, ensuring that requests to open URLs get processed by a currently running instance of Chromium instead of launching a new one. This is where platform differences are strongest, and is ProcessSingleton's main function. Registering properties on windows or the like for Windows and X11 seems cleaner to me than putting breadcrumbs into the file system, since window properties are inherently tied to the user session and to an active instance of the application (and thus do not need to be cleaned up on a crash, etc.). On the Mac, this function is provided by the OS, so there's no need for Chromium to duplicate it. --Amanda On Tue, May 5, 2009 at 12:27 PM, Никита Офицеров himi...@gmail.com wrote: I'm sorry for the late response, I've been quite busy last week. 2009/4/27 Amanda Walker ama...@chromium.org: Hacky is fairly subjective: are there particular things about the existing implementation that bother you? Currently they are different for each OS because each OS has its own issues surrounding launching multiple instances of the browser, different mechanisms for handling incoming requests from the OS to open web pages, and so on. 2009/4/28 stoyan sto...@chromium.org: Well, on Windows code looks racy, does not work well across multiple desktops, and probably will create troubles accessing userdata when same instance is running in different terminal sessions (with same user account). The problem with quick, baroque source code is that usually there are lots of corner cases. I have rethought the idea after your comments, and there are several problems with current Windows implementation: 1. As Stoyan mentioned, window messaging does not work across multiple desktops. Therefore it doesn't work across multiple terminal sessions. Consider the following use case: A user has a version of Windows that allows multiple consequent terminal sessions on his PC, and leaves Chrome opened. Then he opens a session from his laptop and launches Chrome. Preferred result is opening a new window in the second session, but AFAIK it's impossible for the Chrome master process to open a window in a different window station. I know of no browser that would create tabs/windows across sessions backed by the same process. Come to think of it I know of no product that does this. Maybe some service that interacts with the user. Hence quite a lot of changes are required for this to function, like delegating handling of a widget to the newly
[chromium-dev] Passing PlatformGraphicsContext from WebKit to Chrome code
WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Andrew --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: custom_deps [src/webkit/data/layout_tests/LayoutTests: None] has no effort
Be aware that it's not possible to just pick any directory and have it not synced. It only works on directories that are pulled from a different repository like src/webkit/data/layout_tests/LayoutTests. Our main repository in src/ has a lot of layout test result files in src/webkit/data/layout_tests/platform that will always get synced. On Tue, May 5, 2009 at 3:59 PM, Evan Martin e...@chromium.org wrote: On Mon, May 4, 2009 at 1:45 AM, chrome chromeorfire...@gmail.com wrote: Hi all, I trid to get the chrome source code via the gclient tools. Due to low-bandwidth, i did not want to sync the layout_tests code and added the filter line src/webkit/data/layout_tests: None, into the .gclient file. http://dev.chromium.org/developers/how-tos/get-the-code has a different path in its instructions. Is it incorrect? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome have an add-on preference system?
Thanks for all of your inputs. My previous example (gmail addon) might be misleading. Let's say the popular ad block. Ad block should be working on all web sites, and a user should be able to add/edit/delete any specified ad sources. Such information need to be stored locally, and accessible from any web pages by the add-on. So talking about cookie, IMHO I don't think it is a good candidate for user preferences due to its tight restriction on domains and server interaction. I didn't' follow the latest progress of HTML 5, but I remember it had some security issues due to its widely opened door (especially the globalStorage ). On the other hand a user preference system should be working regardless of a user's security setting. But users might prohibit local storage (especially in the public/topmost domain level) like they do to cookies. I am not an expert in this and my thinking might be wrong. Any of your comments are welcome. In any case looking forward to checking the new Chrome release and trying it out (Real Soon Now, right? :)). Thanks, -Jack On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: On Mon, May 4, 2009 at 11:08 AM, jack js2...@gmail.com wrote: Dear experts, I am recently playing around Chrome extension development Sweet! does chrome have an add-on preference system? I think a preference system is an essential component for an add-on ecosystem. What I mean is something like Firefox's Components.interfaces.nsIPrefBranch: https://developer.mozilla.org/En/Code_snippets/Preferences e.g., for a gmail addon, a user should be able to save his/her user/ pswd info. WRT to add-on development, how/where to support this? Our idea is that in most cases developers will use HTML5 LocalStorage for this, which will be available to all web pages (including extensions) by default. However, HTML5 LocalStorage is not yet implemented for Chrome, so it doesn't show up for extensions either. There are people working on this, though, and we hope to have it available Real Soon Now. Note that using cookies, as Peter suggests, won't work either. We have purposely decided to not enable cookies for extensions since the concept doesn't really make sense (cookies are really designed for live web pages that interact with servers). - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Speed up linking
Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Speed up linking
15 minutes on a clean build is pretty good ... For testing 1 -2 line change it needs to link, so expect a 3-6 minute linkage (depending if it depends another module) You can read the section Building Chromium http://dev.chromium.org/developers/how-tos/build-instructions-windows there is a subsection called Accellerating build if that fits. On Tue, May 5, 2009 at 9:37 PM, Leith Bade le...@leithalweapon.geek.nzwrote: Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus scher...@chromium.org wrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Can you just pass a pointer to the pixels and the size? I think the pixel format should be well-defined on each platform, and it should be easy to make a SkBitmap in the Chrome side that uses those pixels directly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: custom_deps [src/webkit/data/layout_tests/LayoutTests: None] has no effort
check src/DEPS to see the directories you can ignore. On Tue, May 5, 2009 at 5:41 PM, Tony Chang t...@chromium.org wrote: Be aware that it's not possible to just pick any directory and have it not synced. It only works on directories that are pulled from a different repository like src/webkit/data/layout_tests/LayoutTests. Our main repository in src/ has a lot of layout test result files in src/webkit/data/layout_tests/platform that will always get synced. On Tue, May 5, 2009 at 3:59 PM, Evan Martin e...@chromium.org wrote: On Mon, May 4, 2009 at 1:45 AM, chrome chromeorfire...@gmail.com wrote: Hi all, I trid to get the chrome source code via the gclient tools. Due to low-bandwidth, i did not want to sync the layout_tests code and added the filter line src/webkit/data/layout_tests: None, into the .gclient file. http://dev.chromium.org/developers/how-tos/get-the-code has a different path in its instructions. Is it incorrect? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Speed up linking
Those are what, 10K systems :) /me jealous On Tue, May 5, 2009 at 10:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: Better hardware really helps. Sadly the Core 2 systems just don't cut it. A Nehalem based system will build chrome_exe from scratch in 4 minutes and 50 seconds (I have reproduced this on a dual quad-nehalem Xeon, and a Core i7-920 I have at home OC'ed to 3.8GHz (both systems building off an Intel X-25M SSD and 12GB RAM). On these systems links take 30 seconds. -Ben On Tue, May 5, 2009 at 6:49 PM, Mohamed Mansour m0.interact...@gmail.com wrote: 15 minutes on a clean build is pretty good ... For testing 1 -2 line change it needs to link, so expect a 3-6 minute linkage (depending if it depends another module) You can read the section Building Chromium http://dev.chromium.org/developers/how-tos/build-instructions-windows there is a subsection called Accellerating build if that fits. On Tue, May 5, 2009 at 9:37 PM, Leith Bade le...@leithalweapon.geek.nz wrote: Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: custom_deps [src/webkit/data/layout_tests/LayoutTests: None] has no effort
I had this problem last week, see the svn-ignore stuff on:
http://groups.google.com/group/chromium-dev/browse_thread/thread/1fa32f170aa749af
Your client will still take ages to sync (I believe the list of
200,000 files still gets passed around), however.
On Mon, May 4, 2009 at 1:45 AM, chrome chromeorfire...@gmail.com wrote:
Hi all,
I trid to get the chrome source code via the gclient tools.
Due to low-bandwidth, i did not want to sync the layout_tests
code and added the filter line
src/webkit/data/layout_tests: None,
into the .gclient file.
But it seems does not work, it still sync the layout_tests code
from the depot after issuing gclient sync command.
the steps i synced code as following:
1. issuing command : gclient config http://src.chromium.org/svn/trunk/src;
2. modify the .gclient file as following:
# An element of this array (a solution) describes a repository
directory
# that will be checked out into your working copy. Each solution may
# optionally define additional dependencies (via its DEPS file) to be
# checked out alongside the solution's directory. A solution may also
# specify custom dependencies (via the custom_deps property) that
# override or augment the dependencies specified by the DEPS file.
# If a safesync_url is specified, it is assumed to reference the
location of
# a text file which contains nothing but the last known good SCM
revision to
# sync against. It is fetched if specified and used unless --head is
passed
solutions = [
{ name : src,
url : http://src.chromium.org/svn/trunk/src;,
custom_deps : {
src/webkit/data/layout_tests: None,
# To use the trunk of a component instead of what's in DEPS:
#component: https://svnserver/component/trunk/;,
# To exclude a component from your working copy:
#data/really_large_component: None,
},
safesync_url:
}
]
3. issuing the command gclient sync.
i am very puzzled of why, can any one help me out?
Thanks
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Speed up linking
The i7-920 system that Glen and I built can be built for ~$1800 by using newegg.com :-) -Ben On Tue, May 5, 2009 at 7:28 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Those are what, 10K systems :) /me jealous On Tue, May 5, 2009 at 10:11 PM, Ben Goodger (Google) b...@chromium.org wrote: Better hardware really helps. Sadly the Core 2 systems just don't cut it. A Nehalem based system will build chrome_exe from scratch in 4 minutes and 50 seconds (I have reproduced this on a dual quad-nehalem Xeon, and a Core i7-920 I have at home OC'ed to 3.8GHz (both systems building off an Intel X-25M SSD and 12GB RAM). On these systems links take 30 seconds. -Ben On Tue, May 5, 2009 at 6:49 PM, Mohamed Mansour m0.interact...@gmail.com wrote: 15 minutes on a clean build is pretty good ... For testing 1 -2 line change it needs to link, so expect a 3-6 minute linkage (depending if it depends another module) You can read the section Building Chromium http://dev.chromium.org/developers/how-tos/build-instructions-windows there is a subsection called Accellerating build if that fits. On Tue, May 5, 2009 at 9:37 PM, Leith Bade le...@leithalweapon.geek.nz wrote: Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Speed up linking
You can build an i7 machine (OC4Ghz/12GB/SSD) that will build Chrome in that time for $1500 (box only). It is what Ben and I use. On Tue, May 5, 2009 at 7:28 PM, Mohamed Mansour m0.interact...@gmail.com wrote: Those are what, 10K systems :) /me jealous On Tue, May 5, 2009 at 10:11 PM, Ben Goodger (Google) b...@chromium.org wrote: Better hardware really helps. Sadly the Core 2 systems just don't cut it. A Nehalem based system will build chrome_exe from scratch in 4 minutes and 50 seconds (I have reproduced this on a dual quad-nehalem Xeon, and a Core i7-920 I have at home OC'ed to 3.8GHz (both systems building off an Intel X-25M SSD and 12GB RAM). On these systems links take 30 seconds. -Ben On Tue, May 5, 2009 at 6:49 PM, Mohamed Mansour m0.interact...@gmail.com wrote: 15 minutes on a clean build is pretty good ... For testing 1 -2 line change it needs to link, so expect a 3-6 minute linkage (depending if it depends another module) You can read the section Building Chromium http://dev.chromium.org/developers/how-tos/build-instructions-windows there is a subsection called Accellerating build if that fits. On Tue, May 5, 2009 at 9:37 PM, Leith Bade le...@leithalweapon.geek.nz wrote: Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
That would be pretty clean--or perhaps wrap it in a PlatformCanvas instead of a bare PlatformGraphicsContext? I haven't looked at the media code yet, so I'm not familiar with what it's actually trying to do. --Amanda On Tue, May 5, 2009 at 10:08 PM, Brett Wilson bre...@chromium.org wrote: On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus scher...@chromium.org wrote: WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in a GraphicsContext: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) call into Chrome, converting the GraphicsContext to a PlatformContextSkia in the process. We realized today this doesn't work on Mac since it's actually a CGContext. Without resorting to #ifdefs everywhere, what's the best way to pass a PlatformGraphicsContext back to Chrome? Can you just pass a pointer to the pixels and the size? I think the pixel format should be well-defined on each platform, and it should be easy to make a SkBitmap in the Chrome side that uses those pixels directly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
If there was a nice way to get a PlatformCanvas out of a
PlatformGraphicsContext when PLATFORM(CG), that'd be awesome.
Brett, I'm not quite sure how you mean to do that. Do you mean that in the
glue code, we should instantiate a byte buffer that we ask the rendered to
fill in, then use webkit's GraphicsContext functions to write that buffer to
screen?
For reference, here's the entry point (plus termporary compilation fix)
that's causing us the headaches:
void MediaPlayerPrivate::paint(GraphicsContext* p, const IntRect r) {
if (m_data) {
#if PLATFORM(SKIA)
AsDelegate(m_data)-Paint(p-platformContext()-canvas(),
webkit_glue::IntRectToWebRect(r));
#else
// TODO(port): Mac builds use PLATFORM(CG) which does not expose a
// PlatformCanvas from the PlatformContext. Figure out how to render
the
// video on a mac.
notImplemented();
#endif
}
}
2 delegations later, this ends up in video_render_impl.cc which finds the
current video frame to draw, and then writes it to the passed in
PlatformCanvas.
-Albert
On Tue, May 5, 2009 at 7:57 PM, Amanda Walker ama...@chromium.org wrote:
That would be pretty clean--or perhaps wrap it in a PlatformCanvas
instead of a bare PlatformGraphicsContext? I haven't looked at the
media code yet, so I'm not familiar with what it's actually trying to
do.
--Amanda
On Tue, May 5, 2009 at 10:08 PM, Brett Wilson bre...@chromium.org wrote:
On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus scher...@chromium.org
wrote:
WebKit's MediaPlayerPrivate interface is a bit backwards where they pass
in
a GraphicsContext:
http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup
We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p,
const
IntRect r) call into Chrome, converting the GraphicsContext to
a PlatformContextSkia in the process. We realized today this doesn't
work
on Mac since it's actually a CGContext.
Without resorting to #ifdefs everywhere, what's the best way to pass
a PlatformGraphicsContext back to Chrome?
Can you just pass a pointer to the pixels and the size? I think the
pixel format should be well-defined on each platform, and it should be
easy to make a SkBitmap in the Chrome side that uses those pixels
directly.
Brett
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: depot_tools is moving!
[Sorry, I should have replied earlier.] For both steps, you need to svn up depot_tools first or gclient help since I just cheked in the changes. *Forcing the installation of depot_tools version of svn and python* Run depot_tools\bootstrap\win_tools.bat force to force the installation of python and svn. This will install svn 1.6 and python 2.4 * * *Backporting to svn 1.5* $ python /depot_tools/change-svn-wc-format.py checkoutpath 1.5 Run on both depot_tools checkout and chromium checkout. I tried it out and it works even with gclient style checkout. Don't run it in the src/directory, run it in the directory containing the .gclient file. So w.r.t to the idea of *not* overriding the currently installed tools; it's more about the consistency wrt the other platforms. You are just free to do whatever you prefer now. For the cygwin svn client interop issues, in theory, we don't use svn:eol-style:native so it shouldn't be a problem in theory. In practice, it probably is. And that's mostly my fault (because of try server issues). Feel free to force the installation of depot_tools. The main issue atm is that I upgraded svn client to 1.6 on Windows. That was an error. So people that converted and had svn 1.5 installed in their PATH had their svn checkout unaccessible. svn 1.6 is required for tortoisesvn users. svn 1.5 is required for mergers. Do as you prefer, I won't get in the way anymore. M-A On Sun, May 3, 2009 at 3:20 PM, Darin Fisher da...@chromium.org wrote: On Fri, May 1, 2009 at 1:34 PM, Marc-Antoine Ruel mar...@chromium.orgwrote: gcl, gclient and friends are moving from http://src.chromium.org/svn/trunk/depot_tools/ to http://src.chromium.org/svn/trunk/tools/depot_tools/ To help you with the switch, there is now a little script to switch automatically. Just run ** *convert_depot_tools* to convert the depot_tools to the new checkout. Warning: the output of this tool isn't nice. If anything fails, just checkout manually: *svn co **http://src.chromium.org/svn/**trunk/tools/depot_tools*http://src.chromium.org/svn/trunk/tools/depot_tools The end result is the same. The far biggest advantage is that there is only one place for all the scripts (no more platform specific) and you can now send patches directly from your depot_tools; e.g. no need to do a separate checkout and run scons anymore. The old depot_tools is scheduled to be removed on May 12, 2009 and you will be upgraded *automatically* next time you run gclient after that date. Windows-only side-effects: - It won't install svn client nor python if they are found in %PATH%. - If you used svn lately, the old depot_tools version was upgraded to 1.6. If you have svn 1.5 in your %PATH%, you may have trouble working with your checkout. Just removing your old client from the path and run gclient help again. I'm confused by these last bullet points. It is quite common for people to have /usr/bin/svn on their $PATH when running under cygwin. It was a goal of depot_tools to provide the right version of svn regardless of what version of svn might exist on $PATH already. This is important because /usr/bin/svn might be the wrong version or might be compiled for unix (LF line endings instead of CRLF). How do you avoid all of these problems? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Then... no way for now? :( I built a little instant messaging notifier with the extensions. :) ☆PhistucK On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote: On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
No good way. If you were feeling especially hacky, you could use the Bookmark system (http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/bookmarks-api) as a temporary data store until LocalStorage is implemented. Not recommended, but it works, we've done it for testing :). - a 2009/5/5 PhistucK phist...@gmail.com: Then... no way for now? :( I built a little instant messaging notifier with the extensions. :) ☆PhistucK On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote: On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
Ah, I see. Hmm, going in that direction (from a GraphicsContext back up to the PlatformCanvas that wraps it) is an interesting question (the rest of our rendering code goes in the other direction). And as Brett can attest, this isn't the first time that PLATFORM(CG) has caused a headache--we just (so far) haven't been willing to duplicate/fork all of the Mac rendering code that currently lives in PLATFORM(CG), since there's a lot of it (especially text handling) that would end up the same. Brett's idea (change your paint routine to take a raw pixmap (an RGBA32Buffer), which we can easily draw into a GraphicsContext on any platform, is basically what the ImageDecoder subclasses do (including rudimentary multi-frame support for things like animated GIFs). If that will work, it's probably the easiest to integrate into all 3 platforms, since the dirty work has already been done. If that's too many frame copies for video, we can write a function that can create, say, an SkBitmap* pointing at the destination bits given a GraphicsContext and a rectangle. Would either of those approaches work? --Amanda On Tue, May 5, 2009 at 11:38 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If there was a nice way to get a PlatformCanvas out of a PlatformGraphicsContext when PLATFORM(CG), that'd be awesome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Tue, May 5, 2009 at 9:38 PM, Amanda Walker ama...@chromium.org wrote: Ah, I see. Hmm, going in that direction (from a GraphicsContext back up to the PlatformCanvas that wraps it) is an interesting question (the rest of our rendering code goes in the other direction). And as Brett can attest, this isn't the first time that PLATFORM(CG) has caused a headache--we just (so far) haven't been willing to duplicate/fork all of the Mac rendering code that currently lives in PLATFORM(CG), since there's a lot of it (especially text handling) that would end up the same. Brett's idea (change your paint routine to take a raw pixmap (an RGBA32Buffer), which we can easily draw into a GraphicsContext on any platform, is basically what the ImageDecoder subclasses do (including rudimentary multi-frame support for things like animated GIFs). If that will work, it's probably the easiest to integrate into all 3 platforms, since the dirty work has already been done. If that's too many frame copies for video, we can write a function that can create, say, an SkBitmap* pointing at the destination bits given a GraphicsContext and a rectangle. Would either of those approaches work? They both sound workable, and might be the best option at this point. We'd actually considered something similar, but didn't really like the idea of having the GraphicsContext draw call happen inside the webkit glue code; all our other glue code just delegates, so this would suddenly add behavior into the glue class. Another suggestion that Alpha brought up was to write some sort of simple wrapper for GraphicsContext that could allow us to call the draw lower down in the call chain without violating the typing abstraction. -Albert --Amanda On Tue, May 5, 2009 at 11:38 PM, Albert J. Wong (王重傑) ajw...@chromium.org wrote: If there was a nice way to get a PlatformCanvas out of a PlatformGraphicsContext when PLATFORM(CG), that'd be awesome. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Does chrome has an add-on preference system?
Yeah, I actually thought about it but never got into implementing it, since my project is kind of secret (to the surroundings) and I am afraid to create a slightly comprehensible bookmark entry with identifiable details. (Too much details, hehe. Forget it. :)) ☆PhistucK 2009/5/6 Aaron Boodman a...@chromium.org No good way. If you were feeling especially hacky, you could use the Bookmark system ( http://sites.google.com/a/chromium.org/dev/developers/design-documents/extensions/bookmarks-api ) as a temporary data store until LocalStorage is implemented. Not recommended, but it works, we've done it for testing :). - a 2009/5/5 PhistucK phist...@gmail.com: Then... no way for now? :( I built a little instant messaging notifier with the extensions. :) ☆PhistucK On Wed, May 6, 2009 at 02:45, Peter Kasting pkast...@google.com wrote: On Tue, May 5, 2009 at 4:43 PM, Aaron Boodman a...@chromium.org wrote: Note that using cookies, as Peter suggests, won't work either. The lesson is, never listen to me. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Speed up linking
I apologize for flogging this horse, but echo 'int extra_variable_to_cause_ccache_miss = 3;' chrome/browser/browser.cc followed by rebuilding chrome just took about 10 seconds on my old laptop, which is a 1.8ghz core duo with 2gb. The secret is linking using shared libraries, which means my rebuilt libbrowser.so is only 6.8mb and my relinked chrome executable 29kb. We've already paid some of the pain on Linux getting shared linking working (in the no more missing symbols sense), so someone who understands Windows/Mac just needs to pay the fix the build to match cost. I call not it. :P PS: just out of curiosity, I instrumented that build to print timing info. Cost breakdown: - 4.3s deciding what needs to be built (had a warm disk cache) - 4.6s rebuilding that one object (release build means -O2 is on) - 0.5s relinking libbrowser.so - 0.2s relinking chrome On Tue, May 5, 2009 at 6:49 PM, Mohamed Mansour m0.interact...@gmail.com wrote: 15 minutes on a clean build is pretty good ... For testing 1 -2 line change it needs to link, so expect a 3-6 minute linkage (depending if it depends another module) You can read the section Building Chromium http://dev.chromium.org/developers/how-tos/build-instructions-windows there is a subsection called Accellerating build if that fits. On Tue, May 5, 2009 at 9:37 PM, Leith Bade le...@leithalweapon.geek.nz wrote: Does anyone have any tips on how to speed up the linking of chrome.dll? It takes 15min on my 2GB Core 2 1.83GHz laptop, and gets anoying when I want to test a 1-2 line change in some file. Thanks, Leith Bade le...@leithalweapon.geek.nz --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
