[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
