[chromium-dev] Re: Read me: When checking in patches for someone else
It seems like GCL should really have support for shepherding a contributed CL to make this less error prone. -Darin On Sun, May 3, 2009 at 7:47 AM, Peter Kasting pkast...@google.com wrote: If you check in patches for someone else, please do the following:* Mention the person who wrote the patch. * Since your gcl change is not the same Rietveld issue as the original review, put a link to the original review in your change description. * Put a BUG= or http://crbug.com/... line in so the bug gets updated correctly. * Either you or the original author should mark the original issue closed and the bug fixed. We've had a number of people not doing the last couple steps, which means that bugs have been patched, but the bug is open with no indication of fixes on it. This hinders testing, merging, triage, etc. Try not to be sloppy! 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: [extensions] content-type
On Thu, May 7, 2009 at 9:12 PM, Aaron Boodman a...@chromium.org wrote: Just to clarify, you understand we're talking about a binary package here, right? Not a text file. Oh, I didn't realize that, but I'm not sure it makes much of a difference. Chrome extensions are distributed in what are essentially zip files with some extra metadata tacked on. The first several bytes of that zip file is currently always Cr24. You're saying it should be CHROME EXTENSION instead. Is there any specific value in being closer to the way the appcache manifests work, other than having a longer signature? I don't think it matters that much. Cr24 is probably fine too. The risk in using something short and cryptic is that someone else might pick the same four byte sequence for another purpose. (Although, I don't know of any others that use Cr24.) Following the appcache precedent seems to have some benefit at a low cost. Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Severity Guidelines for Security Issues
Recently some folks have asked how we decide what severity to rate each security vulnerability. Thus far, we've mostly been using an informal process, but it seemed like a good idea to spell out our policy publicly. Below is a draft of some guidelines for assigning severities to security issues. Please let me know if you have any feedback. Once the draft stabilizes, we'll find a home for the guidelines on dev.chromium.org. http://docs.google.com/Doc?id=dd4p8wc4_11cxwzfqfm This document is heavily influenced by Mozilla's guidelines for rating security vulnerabilities, which you can find at https://wiki.mozilla.org/Security_Severity_Ratings. The main difference is that the above document explains how the severity of security issues interacts with the sandbox. Thanks! Adam --~--~-~--~~~---~--~~ 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: Linux splash page update
On Thu, May 7, 2009 at 9:30 PM, Evan Stade est...@chromium.org wrote: I think it's time to reword this, as users filing bugs has already proven helpful (to me anyway). Also, I don't think we're really treating it as a pre-alpha any more since user-requested features (such as hotkeys, ui elements, etc.) are getting priority. So I propose to update this page. I think instead of the please don't file bugs it should point users to crbug.com, but implore them to report crashers and other broken things rather than missing features, and tell them to use the search first and whatnot. I agree. I got our administrators to add a new bug template for Bug on Linux that sets the appropriate OS: flag so it'll be easier to triage them separately. How does http://codereview.chromium.org/113148 look? Of course if people completely ignore this splash page (which they seem to do) I guess it's a moot point. Generally, the solution to people not reading is to have less text. --~--~-~--~~~---~--~~ 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: webkit now building with gyp on Windows
FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { +'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on Windows has been converted to using gyp to generate the Visual Studio .vcproj and .sln files. You will still see some old .vcproj files checked in to the webkit directory. Ignore them. They will go away soon, after we've let this soak just a bit. As I type this, the build slaves are all green, modulo Mac (valgrind) which is in the process of running after some of the earlier, unsuccessful attempts along the way. Here are, in no particular order, known gotchas and other things to watch out for: - (Most painful) The bindings generation from the .idl files is no longer multi-threaded. Beng reported that this increased his build time from ~5 minutes to ~9 minutes. :-( Coming up with a way to restore this multi-threadedness will probably be the highest priority (barring more severe outright breakages). - There may be missing dependencies among specific targets that aren't part of the canonical set built by the buildbot slaves. We already had the first example, the WebInspector resources not getting installed for some targets: http://codereview.chromium.org/115122 - webkit.sln is generated, but chrome.sln is still checked-in. This means that when you *do* discover a missing dependency that needs to be restored, you not only have to add it to webkit.gyp, but you also *must* add it to chrome.sln in Visual Studio and using sort_sln.py. If you don't, the buildbots (which only use chrome.sln) won't know about the dependency. - The generated .vcproj files don't use build/internal/essentials.vsprops and some of its sibling .vsprops files. The new gyp place to look for these sorts of things is build\common.gypi. If you need a setting to affect webkit and its not there, please add it, or ask. - Official packaging hasn't been tested. The generated Debug\ and Release\ trees have all of the important files in the same locations, though, which should give us a fighting chance of having things like packaging and other scripts work reasonably well. Let me know when you discover something that doesn't, of course. - The sizes of most of the import built-target files (.exe, .dll, .lib) are nearly identical to the old build, within 1%. I've put up some tables here (sorry, Google internal): http://www.corp.google.com/~sgk/gyp-Release-sizes.txt http://www.corp.google.com/~sgk/gyp-Debug-sizes.txt These are just from the builds on my development system, so take them with a grain of salt. That said, the Release build is very consistent with the previous sizes, especially the .exe and .dll files. There are some discrepancies in the Debug build that I haven't accounted for (e.g. 20% reduction in npapi*dll and test_worker.dll, 17% reduction in wtf.lib). I suppose that means, despite the green buildbot slaves, that there could be some different potential behavior lurking. If anyone's bugged by the discrepancies and would like to help characterize those differences (if only for collective peace of mind), let me know. I'll check on progress as soon as I'm back among the living. --SK --~--~-~--~~~---~--~~ 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: Linux splash page update
Hello, maybe include No work has been done on performance yet, much of the UI is missing, plugins don't work, and many more bugs remain. as bulleted points, many people ask questions such as why flash doesn't work etc. It would be nice to place small bulleted points there since it grabs attention. -- Mohamed Mansour On Fri, May 8, 2009 at 11:26 AM, Evan Martin e...@chromium.org wrote: On Thu, May 7, 2009 at 9:30 PM, Evan Stade est...@chromium.org wrote: I think it's time to reword this, as users filing bugs has already proven helpful (to me anyway). Also, I don't think we're really treating it as a pre-alpha any more since user-requested features (such as hotkeys, ui elements, etc.) are getting priority. So I propose to update this page. I think instead of the please don't file bugs it should point users to crbug.com, but implore them to report crashers and other broken things rather than missing features, and tell them to use the search first and whatnot. I agree. I got our administrators to add a new bug template for Bug on Linux that sets the appropriate OS: flag so it'll be easier to triage them separately. How does http://codereview.chromium.org/113148 look? Of course if people completely ignore this splash page (which they seem to do) I guess it's a moot point. Generally, the solution to people not reading is to have less text. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [client-tools-dev] Re: [chromium-dev] webkit now building with gyp on Windows
Congrats steven! Excellent work! -bradn On May 8, 2009 8:51 AM, Darin Fisher da...@chromium.org wrote: FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { +'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on ... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: [client-tools-dev] Re: [chromium-dev] webkit now building with gyp on Windows
Stee-ven! Stee-ven! Stee-ven! :DG On Fri, May 8, 2009 at 9:36 AM, Bradley Nelson bradnel...@google.com wrote: Congrats steven! Excellent work! -bradn On May 8, 2009 8:51 AM, Darin Fisher da...@chromium.org wrote: FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { + 'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on ... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] No more local copy of WebCore and JavaScriptCore!
I just committed a change that deletes our local copy of WebCore and JavaScriptCore (we use the wtf/ directory from here). http://src.chromium.org/viewvc/chrome?view=revrevision=15644 This change should be fairly uneventful to you. You will just notice a bunch of files being deleted and re-checked out once you next sync. If you hack on WebCore, then you are already committing your changes upstream to svn.webkit.org, and this change shouldn't matter to you. If you are a WebKit merger, then this changes everything. Now, instead of running the merge script, you will just be responsible for rolling DEPS to the next good revision of WebKit (and making corresponding fixes to the chromium repository as usual). Dimitri will be sending out details about how this process will work. -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: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 9:49 AM, Darin Fisher da...@chromium.org wrote: I just committed a change that deletes our local copy of WebCore and JavaScriptCore (we use the wtf/ directory from here). http://src.chromium.org/viewvc/chrome?view=revrevision=15644 This change should be fairly uneventful to you. You will just notice a bunch of files being deleted and re-checked out once you next sync gclient sync now crashes for me: svn: '/home/dank/chromium/src/third_party/WebKit/WebCore' is not under version c ontrol Traceback (most recent call last): File /home/dank/chromium/depot_tools/release/gclient.py, line 1643, in modu le result = Main(sys.argv) File /home/dank/chromium/depot_tools/release/gclient.py, line 1638, in Main return DispatchCommand(command, options, args) File /home/dank/chromium/depot_tools/release/gclient.py, line 1569, in Dispa tchCommand return command_map[command](options, args) File /home/dank/chromium/depot_tools/release/gclient.py, line 1489, in DoUpd ate return client.RunOnDeps('update', args) File /home/dank/chromium/depot_tools/release/gclient.py, line 1221, in RunOn Deps scm.RunCommand(command, self._options, args, file_list) File /home/dank/chromium/depot_tools/release/gclient.py, line 668, in RunCom mand return commands[command](options, args, file_list) File /home/dank/chromium/depot_tools/release/gclient.py, line 725, in update '.') File /home/dank/chromium/depot_tools/release/gclient.py, line 561, in Captur eSVNInfo dom = xml.dom.minidom.parseString(info) File /usr/lib/python2.5/xml/dom/minidom.py, line 1925, in parseString return expatbuilder.parseString(string) File /usr/lib/python2.5/xml/dom/expatbuilder.py, line 940, in parseString return builder.parseString(string) File /usr/lib/python2.5/xml/dom/expatbuilder.py, line 223, in parseString parser.Parse(string, True) xml.parsers.expat.ExpatError: no element found: line 3, column 0 Deleting the WebCore lines from .gclient_entries didn't help :-( I guess I'll try to reinitialize... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Unexpected PDB error; ACCESS_DENIED (15) while building browser_tests_launcher
I am using Visual Studio 2005 SP1 with hotfix 935225 on Windows XP SP3. I checked out a chromium source tree from scrash, using http://build.chromium.org/buildbot/continuous/LATEST/REVISION as the safesync_url, and did a Release build. I got the following link error while building browser_tests_launcher. Does anyone know what's wrong? 172-- Build started: Project: browser_tests_launcher, Configuration: Releas e Win32 -- 172Compiling... 172browser_tests_launcher.cc 171 Creating library E:\chromium.latest\src\chrome\Release\lib\browser_tests. lib and object E:\chromium.latest\src\chrome\Release\lib\browser_tests.exp 172Linking... 172LINK : fatal error LNK1318: Unexpected PDB error; ACCESS_DENIED (15) 'e:\chr omium.latest\src\chrome\Release\browser_tests.pdb' 172Build log was saved at file://E:\chromium.latest\src\chrome\Release\obj\bro wser_tests_launcher\BuildLog.htm 172browser_tests_launcher - 1 error(s), 0 warning(s) Wan-Teh --~--~-~--~~~---~--~~ 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: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 10:06 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: On Fri, May 8, 2009 at 9:49 AM, Darin Fisher da...@chromium.org wrote: I just committed a change that deletes our local copy of WebCore and JavaScriptCore (we use the wtf/ directory from here). http://src.chromium.org/viewvc/chrome?view=revrevision=15644 This change should be fairly uneventful to you. You will just notice a bunch of files being deleted and re-checked out once you next sync gclient sync now crashes for me: svn: '/home/dank/chromium/src/third_party/WebKit/WebCore' is not under version c ontrol Traceback (most recent call last): File /home/dank/chromium/depot_tools/release/gclient.py, line 1643, in modu le result = Main(sys.argv) File /home/dank/chromium/depot_tools/release/gclient.py, line 1638, in Main return DispatchCommand(command, options, args) File /home/dank/chromium/depot_tools/release/gclient.py, line 1569, in Dispa tchCommand return command_map[command](options, args) File /home/dank/chromium/depot_tools/release/gclient.py, line 1489, in DoUpd ate return client.RunOnDeps('update', args) File /home/dank/chromium/depot_tools/release/gclient.py, line 1221, in RunOn Deps scm.RunCommand(command, self._options, args, file_list) File /home/dank/chromium/depot_tools/release/gclient.py, line 668, in RunCom mand return commands[command](options, args, file_list) File /home/dank/chromium/depot_tools/release/gclient.py, line 725, in update '.') File /home/dank/chromium/depot_tools/release/gclient.py, line 561, in Captur eSVNInfo dom = xml.dom.minidom.parseString(info) File /usr/lib/python2.5/xml/dom/minidom.py, line 1925, in parseString return expatbuilder.parseString(string) File /usr/lib/python2.5/xml/dom/expatbuilder.py, line 940, in parseString return builder.parseString(string) File /usr/lib/python2.5/xml/dom/expatbuilder.py, line 223, in parseString parser.Parse(string, True) xml.parsers.expat.ExpatError: no element found: line 3, column 0 Deleting the WebCore lines from .gclient_entries didn't help :-( I guess I'll try to reinitialize... That's unfortunate... I wonder what is different about your setup. The buildbots and trybots and my personal Linux box were all happy with the change. Maybe just try deleting all of third_party/WebKit, and then re-run gclient sync. -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: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 10:16 AM, Darin Fisher da...@chromium.org wrote: gclient sync now crashes for me: That's unfortunate... I wonder what is different about your setup. The buildbots and trybots and my personal Linux box were all happy with the change. Maybe just try deleting all of third_party/WebKit, and then re-run gclient sync. Yes, that worked. --~--~-~--~~~---~--~~ 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
On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai m...@chromium.org wrote: multisheet disables x and - (there is no +, but I assume it'd be disabled too). It shouldn't disable - and +. I don't think I have control over that. I don't think that Cocoa's support for child windows putting up sheets is quite complete. ab-modality in the face of a closing window seems like it needs some careful thought and planning. I added methods to the controller to get the views with tabs and am recommending that any users of the class disallow closing of the window while tabs are up. (Maybe the right thing to do, in this case and the window-close case, is to switch to the tab with the sheet? What if there are multiple sheets open?) If there are multiple sheets open, then it's the job of the app logic to decide what to do. In the simple case that I include, if the current tab has a sheet I leave it up, otherwise I switch to the first tab that has a sheet. The quit case is a little bit nastier. The problem is that when you have a hidden sheet up, -applicationShouldTerminate actually *doesn't get called!*I'm still trying to figure this one out. I think that the tab control should not be greyed out at all, since it is directly usable. That's a few hours of futzing with focus issues. For our use cases, is it worth it? After all, we're likely to be using it in cases where we control the drawing of the controls. Punting for now. Hit login, then play with Exposé. The show me my desktop function leaves the sheet hanging; the show me my app's windows and show me all windows functions send the sheet offscreen. You forgot to note that if the sheet is hidden and you do a show app windows or show all windows the fact that I hide the window off-screen wrecks everyone's position. I'm going to have to wrestle with Exposé for that. There's no API to make a window hide from Exposé in Leopard or below and the SPIs I've tried aren't working. I'm going to play with Sno... um, a beta OS to see what I find. Visually, Cocoa sheets have a bit of a shadow at the top, making it look like they've slid out from the parent window. The multisheet looks like it slides out of thin air and then just hangs there. I remember reading that it's a window that does that. I can't convince Cocoa to do that. Visual; punting. 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: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 10:20 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: On Fri, May 8, 2009 at 10:16 AM, Darin Fisher da...@chromium.org wrote: gclient sync now crashes for me: That's unfortunate... I wonder what is different about your setup. The buildbots and trybots and my personal Linux box were all happy with the change. Maybe just try deleting all of third_party/WebKit, and then re-run gclient sync. Yes, that worked. I also had to delete third_party/WebKit. Gclient sync was crashing in CaptureSVNInfo() because the svn info --xml output was a skeleton XML file. --~--~-~--~~~---~--~~ 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: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 10:31 AM, Lei Zhang thes...@chromium.org wrote: On Fri, May 8, 2009 at 10:20 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: On Fri, May 8, 2009 at 10:16 AM, Darin Fisher da...@chromium.org wrote: gclient sync now crashes for me: That's unfortunate... I wonder what is different about your setup. The buildbots and trybots and my personal Linux box were all happy with the change. Maybe just try deleting all of third_party/WebKit, and then re-run gclient sync. Yes, that worked. I also had to delete third_party/WebKit. Gclient sync was crashing in CaptureSVNInfo() because the svn info --xml output was a skeleton XML file. Interesting... sorry about the hassle! -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: Linux splash page update
On Fri, May 8, 2009 at 8:26 AM, Evan Martin e...@chromium.org wrote: How does http://codereview.chromium.org/113148 look? LGTM. 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: Unexpected PDB error; ACCESS_DENIED (15) while building browser_tests_launcher
/MP ? If so, that's normal. Make sure you also kill mspdbsrv.exe. On Fri, May 8, 2009 at 10:07 AM, Wan-Teh Chang w...@google.com wrote: I am using Visual Studio 2005 SP1 with hotfix 935225 on Windows XP SP3. I checked out a chromium source tree from scrash, using http://build.chromium.org/buildbot/continuous/LATEST/REVISION as the safesync_url, and did a Release build. I got the following link error while building browser_tests_launcher. Does anyone know what's wrong? 172-- Build started: Project: browser_tests_launcher, Configuration: Releas e Win32 -- 172Compiling... 172browser_tests_launcher.cc 171 Creating library E:\chromium.latest\src\chrome\Release\lib\browser_tests. lib and object E:\chromium.latest\src\chrome\Release\lib\browser_tests.exp 172Linking... 172LINK : fatal error LNK1318: Unexpected PDB error; ACCESS_DENIED (15) 'e:\chr omium.latest\src\chrome\Release\browser_tests.pdb' 172Build log was saved at file://E:\chromium.latest\src\chrome\Release\obj\bro wser_tests_launcher\BuildLog.htm 172browser_tests_launcher - 1 error(s), 0 warning(s) Wan-Teh --~--~-~--~~~---~--~~ 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: No more local copy of WebCore and JavaScriptCore!
Will take a look but won't be able to fix this in time. Sorry about that :( M-A On Fri, May 8, 2009 at 10:35 AM, Darin Fisher da...@chromium.org wrote: On Fri, May 8, 2009 at 10:31 AM, Lei Zhang thes...@chromium.org wrote: On Fri, May 8, 2009 at 10:20 AM, Dan Kegel daniel.r.ke...@gmail.com wrote: On Fri, May 8, 2009 at 10:16 AM, Darin Fisher da...@chromium.org wrote: gclient sync now crashes for me: That's unfortunate... I wonder what is different about your setup. The buildbots and trybots and my personal Linux box were all happy with the change. Maybe just try deleting all of third_party/WebKit, and then re-run gclient sync. Yes, that worked. I also had to delete third_party/WebKit. Gclient sync was crashing in CaptureSVNInfo() because the svn info --xml output was a skeleton XML file. Interesting... sorry about the hassle! -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: Unexpected PDB error; ACCESS_DENIED (15) while building browser_tests_launcher
On Fri, May 8, 2009 at 11:06 AM, Marc-Antoine Ruel mar...@chromium.org wrote: /MP ? If so, that's normal. Make sure you also kill mspdbsrv.exe. No, I didn't add /MP to essential.vsprops because I know it doesn't work well with Visual Studio 2005. I did a web search for the linker error message LINK : fatal error LNK1318: Unexpected PDB error; ACCESS_DENIED (15) and the only thing I found is your checkin to remove /MP from essential.vsprops :) http://src.chromium.org/viewvc/chrome?view=revrevision=7603 I don't have any mspdbsrv.exe process running (but I'm not doing a build right now). Wan-Teh --~--~-~--~~~---~--~~ 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: No more local copy of WebCore and JavaScriptCore!
On Fri, May 8, 2009 at 9:49 AM, Darin Fisher da...@chromium.org wrote: I just committed a change that deletes our local copy of WebCore and JavaScriptCore (we use the wtf/ directory from here). http://src.chromium.org/viewvc/chrome?view=revrevision=15644 This change should be fairly uneventful to you. You will just notice a bunch of files being deleted and re-checked out once you next sync. Worked fine on one checkout. On another I got: Error: Can't switch the checkout to http://svn.webkit.org/repository/webkit/trunk/webc...@43401; UUID don't match I suspect I have local modifications in that third_party/WebKit, so that's probably the cause. Too bad svn's error messages are SOO informative. PK P.S. UUID don't match? Grammar much, svn devs? --~--~-~--~~~---~--~~ 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
On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai m...@chromium.org wrote: Hit login, then play with Exposé. The show me my desktop function leaves the sheet hanging; the show me my app's windows and show me all windows functions send the sheet offscreen. These are all fixed by the system in SL. Unfortunately, everything else is broken in SL. Putting the sheet back leaves it ignoring all mouse input, and when it's hidden the blurring effect on the host window remains. Urgh. I've fiddled around with several approaches and gotten nowhere. I might end up having to use that DTS incident after all... 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: Severity Guidelines for Security Issues
Nit: under High, Additionally, we will usually rate issues that let an attacker execute arbitrary code in the sandbox as high because the sandbox limits the privileges of a compromised rendering engine. sandbox limits - sandbox is designed to limit. (Lawyers are rubbing off on me.) 2009/5/7 Adam Barth aba...@chromium.org Recently some folks have asked how we decide what severity to rate each security vulnerability. Thus far, we've mostly been using an informal process, but it seemed like a good idea to spell out our policy publicly. Below is a draft of some guidelines for assigning severities to security issues. Please let me know if you have any feedback. Once the draft stabilizes, we'll find a home for the guidelines on dev.chromium.org. http://docs.google.com/Doc?id=dd4p8wc4_11cxwzfqfm This document is heavily influenced by Mozilla's guidelines for rating security vulnerabilities, which you can find at https://wiki.mozilla.org/Security_Severity_Ratings. The main difference is that the above document explains how the severity of security issues interacts with the sandbox. Thanks! Adam --~--~-~--~~~---~--~~ 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: Severity Guidelines for Security Issues
Thanks. Fixed. Adam On Fri, May 8, 2009 at 11:42 AM, Ian Fette i...@chromium.org wrote: Nit: under High, Additionally, we will usually rate issues that let an attacker execute arbitrary code in the sandbox as high because the sandbox limits the privileges of a compromised rendering engine. sandbox limits - sandbox is designed to limit. (Lawyers are rubbing off on me.) 2009/5/7 Adam Barth aba...@chromium.org Recently some folks have asked how we decide what severity to rate each security vulnerability. Thus far, we've mostly been using an informal process, but it seemed like a good idea to spell out our policy publicly. Below is a draft of some guidelines for assigning severities to security issues. Please let me know if you have any feedback. Once the draft stabilizes, we'll find a home for the guidelines on dev.chromium.org. http://docs.google.com/Doc?id=dd4p8wc4_11cxwzfqfm This document is heavily influenced by Mozilla's guidelines for rating security vulnerabilities, which you can find at https://wiki.mozilla.org/Security_Severity_Ratings. The main difference is that the above document explains how the severity of security issues interacts with the sandbox. Thanks! Adam --~--~-~--~~~---~--~~ 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 problem with that approach is that you can't cleanly close a sheet in the general case. If it's our sheet then perhaps that'd work, but for something like the save file sheet, there's no good way to convince it to close that isn't more hacky than what I'm doing... Avi On Fri, May 8, 2009 at 12:44 PM, Scott Hess sh...@chromium.org wrote: I hate to suggest this, since it's sort of icky (*), but would it make sense to instead use regular old sheets, and save/restore state across tab switches? I mean so that if the tab is not visible, there is no OS-level sheet, there's a state container somewhere in the tab which will be restored with the tab. That should short-circuit a lot of funky interactions that are broken in places we cannot see them, at a cost of making some for free stuff not work (we'll have to manually manage those interactions). (*) I don't like icky, but icky where you own the code is preferable to icky where you're having to reverse-engineer someone else's code. -scott On Fri, May 8, 2009 at 11:20 AM, Avi Drissman a...@google.com wrote: On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai m...@chromium.org wrote: Hit login, then play with Exposé. The show me my desktop function leaves the sheet hanging; the show me my app's windows and show me all windows functions send the sheet offscreen. These are all fixed by the system in SL. Unfortunately, everything else is broken in SL. Putting the sheet back leaves it ignoring all mouse input, and when it's hidden the blurring effect on the host window remains. Urgh. I've fiddled around with several approaches and gotten nowhere. I might end up having to use that DTS incident after all... 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. And I have to say, the tab-modal file sheet is very, very cool. It would be a shame to lose that capability. --Amanda On Fri, May 8, 2009 at 3:58 PM, Avi Drissman a...@google.com wrote: The problem with that approach is that you can't cleanly close a sheet in the general case. If it's our sheet then perhaps that'd work, but for something like the save file sheet, there's no good way to convince it to close that isn't more hacky than what I'm doing... Avi On Fri, May 8, 2009 at 12:44 PM, Scott Hess sh...@chromium.org wrote: I hate to suggest this, since it's sort of icky (*), but would it make sense to instead use regular old sheets, and save/restore state across tab switches? I mean so that if the tab is not visible, there is no OS-level sheet, there's a state container somewhere in the tab which will be restored with the tab. That should short-circuit a lot of funky interactions that are broken in places we cannot see them, at a cost of making some for free stuff not work (we'll have to manually manage those interactions). (*) I don't like icky, but icky where you own the code is preferable to icky where you're having to reverse-engineer someone else's code. -scott On Fri, May 8, 2009 at 11:20 AM, Avi Drissman a...@google.com wrote: On Thu, May 7, 2009 at 9:49 AM, Mark Mentovai m...@chromium.org wrote: Hit login, then play with Exposé. The show me my desktop function leaves the sheet hanging; the show me my app's windows and show me all windows functions send the sheet offscreen. These are all fixed by the system in SL. Unfortunately, everything else is broken in SL. Putting the sheet back leaves it ignoring all mouse input, and when it's hidden the blurring effect on the host window remains. Urgh. I've fiddled around with several approaches and gotten nowhere. I might end up having to use that DTS incident after all... 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
Amanda Walker wrote: Yeah. And I have to say, the tab-modal file sheet is very, very cool. It would be a shame to lose that capability. I agree, I think it'd be worth seeing how polished we can get things with Avi's POC. It's a cool behavior that has the exact feel that sheet users would expect. --~--~-~--~~~---~--~~ 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
Thanks. So I fiddled with the hiding sheets part, and now leave the sheet in place but make it fully transparent. That helps a lot with some expose issues (and all the ones still left are fixed in SL). That leaves the fact that the shouldterminate delegate call is broken and that event handling and fuzzing issues are entirely broken on SL. Unless someone has any thoughts on that, I'm going to drop DTS a call later today. Code's in my experimental directory for anyone wanting to play with it. Avi On Fri, May 8, 2009 at 1:35 PM, Mark Mentovai m...@chromium.org wrote: Amanda Walker wrote: Yeah. And I have to say, the tab-modal file sheet is very, very cool. It would be a shame to lose that capability. I agree, I think it'd be worth seeing how polished we can get things with Avi's POC. It's a cool behavior that has the exact feel that sheet users would expect. --~--~-~--~~~---~--~~ 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: Try out --enable-omnibox2!
It looks really good, but brings a usability problem: the hovered entry's title has low contrast with it's bakcground color: http://img141.imageshack.us/img141/8058/omnibox2lowcontrast.png This is how it used to look: http://img142.imageshack.us/img142/1909/omniboxold.png sryo On May 7, 2:53 pm, Ben Goodger (Google) b...@chromium.org wrote: Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ 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: webkit now building with gyp on Windows
On Fri, May 8, 2009 at 1:36 PM, John Abd-El-Malek j...@chromium.org wrote: one small issue I see: the npapi_test_plugin vcproj has a bunch of .. folders in the file hierarchy. The attached image explains it better. With gyp the visual studio representation of the files matches the on-disk representation. This was a design choice. Eventually we might want to collapse them, since it's not pretty. Nicolas On Fri, May 8, 2009 at 10:05 AM, Darin Fisher da...@chromium.org wrote: I forgot to add... Thank You Steven!!1!1! On Fri, May 8, 2009 at 8:51 AM, Darin Fisher da...@chromium.org wrote: FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { +'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on Windows has been converted to using gyp to generate the Visual Studio .vcproj and .sln files. You will still see some old .vcproj files checked in to the webkit directory. Ignore them. They will go away soon, after we've let this soak just a bit. As I type this, the build slaves are all green, modulo Mac (valgrind) which is in the process of running after some of the earlier, unsuccessful attempts along the way. Here are, in no particular order, known gotchas and other things to watch out for: - (Most painful) The bindings generation from the .idl files is no longer multi-threaded. Beng reported that this increased his build time from ~5 minutes to ~9 minutes. :-( Coming up with a way to restore this multi-threadedness will probably be the highest priority (barring more severe outright breakages). - There may be missing dependencies among specific targets that aren't part of the canonical set built by the buildbot slaves. We already had the first example, the WebInspector resources not getting installed for some targets: http://codereview.chromium.org/115122 - webkit.sln is generated, but chrome.sln is still checked-in. This means that when you *do* discover a missing dependency that needs to be restored, you not only have to add it to webkit.gyp, but you also *must* add it to chrome.sln in Visual Studio and using sort_sln.py. If you don't, the buildbots (which only use chrome.sln) won't know about the dependency. - The generated .vcproj files don't use build/internal/essentials.vsprops and some of its sibling .vsprops files. The new gyp place to look for these sorts of things is build\common.gypi. If you need a setting to affect webkit and its not there, please add it, or ask. - Official packaging hasn't been tested. The generated Debug\ and Release\ trees have all of the important files in the same locations, though, which should give us a fighting chance of having things like packaging and other scripts work reasonably well. Let me know when you discover something that doesn't, of course. - The sizes of most of the import built-target files (.exe, .dll, .lib) are nearly identical to the old build, within 1%. I've put up some tables here (sorry, Google internal): http://www.corp.google.com/~sgk/gyp-Release-sizes.txt http://www.corp.google.com/~sgk/gyp-Debug-sizes.txt These are just from the builds on my development system, so take them with a grain of salt. That said, the Release build is very consistent with the previous sizes, especially the .exe and .dll files. There are some discrepancies in the Debug build that I haven't accounted for (e.g. 20% reduction in npapi*dll and test_worker.dll, 17% reduction in wtf.lib). I suppose that means, despite the green buildbot slaves, that there could be some different potential behavior lurking. If anyone's bugged by the discrepancies and would like to help characterize those differences (if only for collective peace of mind), let me know. I'll check on progress as soon as I'm back among the living. --SK --~--~-~--~~~---~--~~ 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: Try out --enable-omnibox2!
On Fri, May 8, 2009 at 2:12 PM, sryo teodal...@gmail.com wrote: It looks really good, but brings a usability problem: the hovered entry's title has low contrast with it's bakcground color: http://img141.imageshack.us/img141/8058/omnibox2lowcontrast.png That looks like something worthy of filing a bug. I agree that it's not readable. 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: Try out --enable-omnibox2!
On Thu, May 7, 2009 at 4:27 PM, Mohamed Mansour m0.interact...@gmail.comwrote: Great! adds a new fresh look. +1 One question though, is the transparency really needed? It distracts me for some reason from the actual results. I suggest lowering down the transparency a little, but that's just me. +1 - I don't like the transparency either. I'd prefer opaque. Mike On Thu, May 7, 2009 at 1:53 PM, Ben Goodger (Google) b...@chromium.orgwrote: Please try out the --enable-omnibox2 command line switch in Chrome and file bugs against me in the issue tracker. I'd like to get a better sense of what needs to be done with it so we can turn it on by default. The differences thus far are aesthetic, and in the popup. -Ben --~--~-~--~~~---~--~~ 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: Try out --enable-omnibox2!
On Fri, May 8, 2009 at 2:20 PM, Mike Belshe mbel...@google.com wrote: +1 - I don't like the transparency either. I'd prefer opaque. Me too 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: webkit now building with gyp on Windows
+1 to cloning disk layout for chrome source - it makes it much easier to find things! for third_party stuff where the build config lives in a different dir structure to the source, it might be possible to add a dir base or something to the target info which specifies the dirs to strip off the front perhaps? -Ben On Fri, May 8, 2009 at 2:14 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Fri, May 8, 2009 at 1:36 PM, John Abd-El-Malek j...@chromium.org wrote: one small issue I see: the npapi_test_plugin vcproj has a bunch of .. folders in the file hierarchy. The attached image explains it better. With gyp the visual studio representation of the files matches the on-disk representation. This was a design choice. Eventually we might want to collapse them, since it's not pretty. Nicolas On Fri, May 8, 2009 at 10:05 AM, Darin Fisher da...@chromium.org wrote: I forgot to add... Thank You Steven!!1!1! On Fri, May 8, 2009 at 8:51 AM, Darin Fisher da...@chromium.org wrote: FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { + 'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on Windows has been converted to using gyp to generate the Visual Studio .vcproj and .sln files. You will still see some old .vcproj files checked in to the webkit directory. Ignore them. They will go away soon, after we've let this soak just a bit. As I type this, the build slaves are all green, modulo Mac (valgrind) which is in the process of running after some of the earlier, unsuccessful attempts along the way. Here are, in no particular order, known gotchas and other things to watch out for: (Most painful) The bindings generation from the .idl files is no longer multi-threaded. Beng reported that this increased his build time from ~5 minutes to ~9 minutes. :-( Coming up with a way to restore this multi-threadedness will probably be the highest priority (barring more severe outright breakages). There may be missing dependencies among specific targets that aren't part of the canonical set built by the buildbot slaves. We already had the first example, the WebInspector resources not getting installed for some targets: http://codereview.chromium.org/115122 webkit.sln is generated, but chrome.sln is still checked-in. This means that when you *do* discover a missing dependency that needs to be restored, you not only have to add it to webkit.gyp, but you also *must* add it to chrome.sln in Visual Studio and using sort_sln.py. If you don't, the buildbots (which only use chrome.sln) won't know about the dependency. The generated .vcproj files don't use build/internal/essentials.vsprops and some of its sibling .vsprops files. The new gyp place to look for these sorts of things is build\common.gypi. If you need a setting to affect webkit and its not there, please add it, or ask. Official packaging hasn't been tested. The generated Debug\ and Release\ trees have all of the important files in the same locations, though, which should give us a fighting chance of having things like packaging and other scripts work reasonably well. Let me know when you discover something that doesn't, of course. The sizes of most of the import built-target files (.exe, .dll, .lib) are nearly identical to the old build, within 1%. I've put up some tables here (sorry, Google internal): http://www.corp.google.com/~sgk/gyp-Release-sizes.txt http://www.corp.google.com/~sgk/gyp-Debug-sizes.txt These are just from the builds on my development system, so take them with a grain of salt. That said, the Release build is very consistent with the previous sizes, especially the .exe and .dll files. There are some discrepancies in the Debug build that I haven't accounted for (e.g. 20% reduction in npapi*dll and test_worker.dll, 17% reduction in wtf.lib). I suppose that means, despite the green buildbot slaves, that there could be some different potential behavior lurking. If anyone's bugged by the discrepancies and would like to help characterize those differences (if only for collective peace of mind), let me know. I'll check on progress as soon as I'm back among the living. --SK --~--~-~--~~~---~--~~ 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: Linux splash page update
LG2M as well. On Fri, May 8, 2009 at 10:55 AM, Evan Martin e...@chromium.org wrote: I actually had tried that in my first version, but I felt it made it seem like the list was exhaustive. Once (if?) we start getting lots of the same bug report, it would be worth highlighting the common reports. Or hopefully I can just get Flash working before too many people notice. :) On Fri, May 8, 2009 at 9:01 AM, Mohamed Mansour m0.interact...@gmail.com wrote: Hello, maybe include No work has been done on performance yet, much of the UI is missing, plugins don't work, and many more bugs remain. as bulleted points, many people ask questions such as why flash doesn't work etc. It would be nice to place small bulleted points there since it grabs attention. -- Mohamed Mansour On Fri, May 8, 2009 at 11:26 AM, Evan Martin e...@chromium.org wrote: On Thu, May 7, 2009 at 9:30 PM, Evan Stade est...@chromium.org wrote: I think it's time to reword this, as users filing bugs has already proven helpful (to me anyway). Also, I don't think we're really treating it as a pre-alpha any more since user-requested features (such as hotkeys, ui elements, etc.) are getting priority. So I propose to update this page. I think instead of the please don't file bugs it should point users to crbug.com, but implore them to report crashers and other broken things rather than missing features, and tell them to use the search first and whatnot. I agree. I got our administrators to add a new bug template for Bug on Linux that sets the appropriate OS: flag so it'll be easier to triage them separately. How does http://codereview.chromium.org/113148 look? Of course if people completely ignore this splash page (which they seem to do) I guess it's a moot point. Generally, the solution to people not reading is to have less text. --~--~-~--~~~---~--~~ 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...
Salut, I've been trying to use a single bitmap, but it is much more work than I expected... And I couldn't get it to work flawlessly yet either... I get some refresh problems once in a while that I can't figure out... I solved many little bumps on the way, but now it works in most cases, except more complex pages like Google maps, which are giving me a lot of trouble... Here's what I'm doing: - In RenderWidget::DoDeferredPaint(), I create a drawing canvas the size of the union of all invalidated rects (I also tried creating one the size of the whole view rect, just to see... and it didn't help). - I translate the canvas based on the origin of the union rect, and then call webwidget_-Paint() for each invalidated rect individually, properly setting the clip rect on the canvas. (When I try with a bitmap the size of the whole view rect, I skip the translation, of course.) - I send that single bitmap with its rect and the list of sub-rects to paint. - In RenderWidgethost::PaintBackingStoreRects(), I now pass a vector of rects to paint, and the rect of the whole bitmap to paint from. I added a loop to call BackingStoreManager::PrepareBackingStore() for each rect to paint. - The BackingStore::PaintRect() method now receives the rect for the bitmap (as well as the rect to paint, since they are not necessarily the same anymore). I then use this to specify the source origin point in the bitmap where to point from. I still want to investigate a few things before I clean up the current version I have of this code and upload it to rietveld so that people can look at it and give me hints as to where I may have goofed... But if you already have hints as to what could not be working in the approach I described above, please send them my way... If you want more details about the approach and/or the problems that I'm having, let me know, and I will send them to you... Thanks! BYE MAD P.S.: I'm actually wondering if I'm wasting my time here... I tried to to some profiling anyway, even though the code doesn't work flawlessly... And I have not seen any dramatic improvements... Though as I said before, I don't think I can trust the numbers I get on my machine... So I keep digging... On Tue, May 5, 2009 at 6:26 PM, Marc-Andre Decoste m...@chromium.org wrote: 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: webkit now building with gyp on Windows
Very nice job Steven! I have a question (as always :)) Now the build takes tremendously a lot more time. It has been going on for over an hour (used build it from scratch in around 20 minutes). I have noticed in VS it is spitting too many WebKit warnings, (maybe that is why it is slowing it down), there is around 3+ warnings (32252 and still counting) If there is a way to minimze those warnings being printed to the screen, maybe that will help my build go quicker. Thanks! -- Mohamed Mansour On Fri, May 8, 2009 at 5:42 PM, Darin Fisher da...@chromium.org wrote: Eventually (soon, i hope), the webkit build files will move into svn.webkit.org, so this issue will go away. -Darin On Fri, May 8, 2009 at 2:29 PM, Ben Goodger (Google) b...@chromium.orgwrote: +1 to cloning disk layout for chrome source - it makes it much easier to find things! for third_party stuff where the build config lives in a different dir structure to the source, it might be possible to add a dir base or something to the target info which specifies the dirs to strip off the front perhaps? -Ben On Fri, May 8, 2009 at 2:14 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Fri, May 8, 2009 at 1:36 PM, John Abd-El-Malek j...@chromium.org wrote: one small issue I see: the npapi_test_plugin vcproj has a bunch of .. folders in the file hierarchy. The attached image explains it better. With gyp the visual studio representation of the files matches the on-disk representation. This was a design choice. Eventually we might want to collapse them, since it's not pretty. Nicolas On Fri, May 8, 2009 at 10:05 AM, Darin Fisher da...@chromium.org wrote: I forgot to add... Thank You Steven!!1!1! On Fri, May 8, 2009 at 8:51 AM, Darin Fisher da...@chromium.org wrote: FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { +'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on Windows has been converted to using gyp to generate the Visual Studio .vcproj and .sln files. You will still see some old .vcproj files checked in to the webkit directory. Ignore them. They will go away soon, after we've let this soak just a bit. As I type this, the build slaves are all green, modulo Mac (valgrind) which is in the process of running after some of the earlier, unsuccessful attempts along the way. Here are, in no particular order, known gotchas and other things to watch out for: (Most painful) The bindings generation from the .idl files is no longer multi-threaded. Beng reported that this increased his build time from ~5 minutes to ~9 minutes. :-( Coming up with a way to restore this multi-threadedness will probably be the highest priority (barring more severe outright breakages). There may be missing dependencies among specific targets that aren't part of the canonical set built by the buildbot slaves. We already had the first example, the WebInspector resources not getting installed for some targets: http://codereview.chromium.org/115122 webkit.sln is generated, but chrome.sln is still checked-in. This means that when you *do* discover a missing dependency that needs to be restored, you not only have to add it to webkit.gyp, but you also *must* add it to chrome.sln in Visual Studio and using sort_sln.py. If you don't, the buildbots (which only use chrome.sln) won't know about the dependency. The generated .vcproj files don't use build/internal/essentials.vsprops and some of its sibling .vsprops files. The new gyp place to look for these sorts of things is build\common.gypi. If you need a setting to affect webkit and its not there, please add it, or ask. Official packaging hasn't been tested. The generated Debug\ and Release\ trees have all of the important files in the same locations, though, which should give us a fighting chance of having things like packaging and other scripts work reasonably well. Let me know when you discover something that doesn't, of course. The sizes of most of the import built-target files (.exe, .dll, .lib) are nearly identical to the old build, within 1%. I've put up some tables here (sorry, Google internal): http://www.corp.google.com/~sgk/gyp-Release-sizes.txt http://www.corp.google.com/~sgk/gyp-Debug-sizes.txt These are just from the builds on my development system, so take them with a grain of salt. That said, the Release build is
[chromium-dev] Re: webkit now building with gyp on Windows
I have got the answer from IRC :) All good, thanks! [01:38:32] +maruel m0: yeah we'll look at fixing that next week [01:39:00] +maruel all the idl parsing is serialized now [01:43:59] +beng_home m0: the webkit gyp build is spinning up the cygwin init script for every autogen file [01:44:04] +beng_home m0: sgk has a fix for that [01:44:14] +beng_home it's also not generating files in parallel [01:44:20] +beng_home it's being worked on -- Mohamed Mansour On Sat, May 9, 2009 at 1:42 AM, Mohamed Mansour m0.interact...@gmail.comwrote: Very nice job Steven! I have a question (as always :)) Now the build takes tremendously a lot more time. It has been going on for over an hour (used build it from scratch in around 20 minutes). I have noticed in VS it is spitting too many WebKit warnings, (maybe that is why it is slowing it down), there is around 3+ warnings (32252 and still counting) If there is a way to minimze those warnings being printed to the screen, maybe that will help my build go quicker. Thanks! -- Mohamed Mansour On Fri, May 8, 2009 at 5:42 PM, Darin Fisher da...@chromium.org wrote: Eventually (soon, i hope), the webkit build files will move into svn.webkit.org, so this issue will go away. -Darin On Fri, May 8, 2009 at 2:29 PM, Ben Goodger (Google) b...@chromium.orgwrote: +1 to cloning disk layout for chrome source - it makes it much easier to find things! for third_party stuff where the build config lives in a different dir structure to the source, it might be possible to add a dir base or something to the target info which specifies the dirs to strip off the front perhaps? -Ben On Fri, May 8, 2009 at 2:14 PM, Nicolas Sylvain nsylv...@chromium.org wrote: On Fri, May 8, 2009 at 1:36 PM, John Abd-El-Malek j...@chromium.org wrote: one small issue I see: the npapi_test_plugin vcproj has a bunch of .. folders in the file hierarchy. The attached image explains it better. With gyp the visual studio representation of the files matches the on-disk representation. This was a design choice. Eventually we might want to collapse them, since it's not pretty. Nicolas On Fri, May 8, 2009 at 10:05 AM, Darin Fisher da...@chromium.org wrote: I forgot to add... Thank You Steven!!1!1! On Fri, May 8, 2009 at 8:51 AM, Darin Fisher da...@chromium.org wrote: FYI, here's the patch I applied to enable /MP: Index: common.gypi === --- common.gypi (revision 15636) +++ common.gypi (working copy) @@ -380,6 +380,7 @@ 'msvs_disabled_warnings': [4503, 4819], 'msvs_settings': { 'VCCLCompilerTool': { +'AdditionalOptions': '/MP', 'MinimalRebuild': 'false', 'ExceptionHandling': '0', 'BufferSecurityCheck': 'true', On Fri, May 8, 2009 at 3:27 AM, Steven Knight s...@chromium.org wrote: The webkit build on Windows has been converted to using gyp to generate the Visual Studio .vcproj and .sln files. You will still see some old .vcproj files checked in to the webkit directory. Ignore them. They will go away soon, after we've let this soak just a bit. As I type this, the build slaves are all green, modulo Mac (valgrind) which is in the process of running after some of the earlier, unsuccessful attempts along the way. Here are, in no particular order, known gotchas and other things to watch out for: (Most painful) The bindings generation from the .idl files is no longer multi-threaded. Beng reported that this increased his build time from ~5 minutes to ~9 minutes. :-( Coming up with a way to restore this multi-threadedness will probably be the highest priority (barring more severe outright breakages). There may be missing dependencies among specific targets that aren't part of the canonical set built by the buildbot slaves. We already had the first example, the WebInspector resources not getting installed for some targets: http://codereview.chromium.org/115122 webkit.sln is generated, but chrome.sln is still checked-in. This means that when you *do* discover a missing dependency that needs to be restored, you not only have to add it to webkit.gyp, but you also *must* add it to chrome.sln in Visual Studio and using sort_sln.py. If you don't, the buildbots (which only use chrome.sln) won't know about the dependency. The generated .vcproj files don't use build/internal/essentials.vsprops and some of its sibling .vsprops files. The new gyp place to look for these sorts of things is build\common.gypi. If you need a setting to affect webkit and its not there, please add it, or ask. Official packaging hasn't been tested. The generated Debug\ and Release\ trees have all of the important files in the same locations, though, which should give us a fighting chance of having things