[chromium-dev] Re: yet another browser benchmark
2009/6/24 Evan Martin e...@chromium.org http://www.codexon.com/posts/a-real-benchmark-real-websites-with-chrome-firefox-opera-safari-ie Brief summary: - measures warm-disk-based snapshots of real websites - hand-injected script src into pages that uses addEventListener(load) / attachEvent(onload) to tell when load is done (I wonder if parallel script loading plays into it?) - statistical methodology isn't the greatest - concludes with a three-way tie between Chrome, Safari, and Opera Both Chrome and Safari are similarly significantly slower (around 200ms over IE/FF/Opera) for their Baidu test. WebKit bug or measuring bug? There's a remote chance that Chrome 2.0.x is on par with IE/FF/Opera if it's due to a webkit unforking we did that I have yet to make it again in the webkit trunk. However, an order of magnitude difference seems way too much (we certainly only saw a small spike, if any, in intl1 page cycler test IIRC). If that's indeed the cause (although not very likely), I may have an easier time with the upstream :-) More likely is that the tester's machine does not have any Chinese font or only one (e.g. Arial Unicode MS) and webkit win is slower in that scenario. Hmm, but his OS is Vista which I think is preloaded with Chinese fonts (it may depend on the 'flavor'??). Jungshik This makes me wonder if it'd be helpful for us to publish a blog post on how to do a benchmark. Would mention stuff like whether DOMContentReady includes image loads completion on all browsers (I certainly don't know), geometric mean vs arithmetic mean, whether we expect networking stacks to have an impact on real perf, etc. --~--~-~--~~~---~--~~ 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: Using custom builds of chromium in a commercial setting
Excellent, clearly a far superior approach to my current overwriting of image files and re-compiling the default.dll ! :) Will read and absorb. - cj. On Wed, Jun 24, 2009 at 7:32 PM, Glen Murphy g...@chromium.org wrote: Not sure about the theme part, Glen is the right person to answer that (cc-ed). There's some basic documentation here: http://dev.chromium.org/developers/design-documents/themes More soon. As for keeping track of the work, your best best is to star issue 19 to get notified about when something related to that bug is checked in. We try to always include BUG=n in our checkins and then bug n will be updated automatically. You could also subscribe to the chromium-checkins group to monitor each checkin that get submitted, but that seems like overkill for what you want to do. -F On Tue, Jun 23, 2009 at 13:36, Ciaran ciar...@gmail.com wrote: As a follow up, thanks for the help. This approach works perfectly, I've found where in the code I could 'subvert' the app mechanism to allow the executable to automatically open a url on startup without passing it in the on the command line. To modify the 'theme' of the executable, I've been replacing the resources in the theme package, but this seems a little un-clean, is there a better/recommended approach than just replacing the existing files? Also as part of this wrk I stumbled upon the no-doubt infamous Issue 19 (http://code.google.com/p/chromium/issues/detail?id=19) which I see has been chosen as a GSoC project, is there anywhere I can subscribe to in order to ascertain how far through the implementation of that piece of work peeps are, or is the GSoC process a bit of a black-box affair ? -cj On Sat, Jun 20, 2009 at 5:54 PM, Ciaran ciar...@gmail.com wrote: This sounds perfect, ideally I'd bundle a chrome exe which is pretty much locked into a particular url (or set of urls) Thanks folks I'll take a closer look :) -cj. On Sat, Jun 20, 2009 at 5:22 PM, Finnur Thorarinsson fin...@chromium.org wrote: There might be a wiki page somewhere, but to start with, the Page menu has a Create application shortcuts menu item, which helps you create shortcuts for running web sites as applications. You can also use a command line flag, such as chrome.exe --app=http://your_url/ You can use that as a starting point for digging into this feature. On Sat, Jun 20, 2009 at 02:37, Ciaran ciar...@gmail.com wrote: On Fri, Jun 19, 2009 at 6:47 PM, Evan Martin e...@chromium.org wrote: I am not a lawyer, but that is the intent. (In some sense Google Chrome is just a commercial consumer of the code base as well. As I understand it, contributors retain copyright on their contributions, so it's not even the case that Google owns all the code that mentions Google in the copyright. See http://code.google.com/legal/individual-cla-v1.0.html ) BTW, Chromium in the App Mode is more or less an SSB. Thanks for your response :) Can you elaborate further on how I would put chromium into 'App mode' ? Is there a page on the wiki or anything ? -Cj On Thu, Jun 18, 2009 at 3:45 AM, JavaJunkyciar...@gmail.com wrote: Hi folks, I'm currently investigating the possibility of using SSBs (Site Specific Browsers, another example is mozilla's Prism) to ship alongside a commercial web application, the application does not depend on the SSB in any way just makes it more acceptable to corporations who are opposed to updating to more recent web browsers. I've spent some time perusing the mailing list, and looking at the T's and C's that I can locate on the chromium website ( http://code.google.com/chromium/terms.html ). As far as I can tell the primary license and all 3rd party licenses are 'commecially friendly' and as long as the build of chromium doesn't mention Google or any of the associated trademarks then there should be no problem shipping a customised build of chromium on a cd alongside a commercial product. Can anyone confirm whether or not this is the case ? Many thanks - cj. --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
Hi, Thanks for review. 2009/6/25 Jeremy Orlow jor...@chromium.org I only skimmed, but it looks well thought out. One question though: is this going to be functional for non-Chromium browsers? Given that your design doc mentions v8 and hooks into Chromium's network stack, but no mention of JavaScriptCore or WebKit's resource loading code, I'm worried that the answer is no. I strongly recommend that your design doc include details for full integration into normal WebKit and that you offer to write the necessary code. If it's Chromium only, you'll definitely get more push back on the design and people will be less willing to review. Probably to the extent that it would have been easier to just write the code to begin with. v8 and hooks into chromium's network stack was written in chromium part only. I planed to send webkit part to webkit-dev. I've mentioned what platform code is required in WebSocketHandle in webkit part design doc. I just added JavaScript binding section. Do we need more detailed information for these part? Thanks, ukai J On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Thanks, ukai --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any code
you want to be shared code shouldn't be slated for that class. To the extent
the 'web socket protocol framing' can be done indepedent of the 'platform'
socket handle (which it looks like it can be), it would be a good thing to
put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.orgwrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and write
design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc
Hi,
2009/6/25 Drew Wilson atwil...@google.com
BTW, I checked in with IanH - it sounds like WebSockets are also on the
Worker roadmap, so that's something to keep in mind while you iterate on
your design.
Ok, I see.
+1 to avoiding WebCore/loader, but also +1 to refactoring to enable as much
common code as possible cross-platform - I'm looking at the Chromium worker
code now, and there's a chunk of duplicated logic from the WebKit worker
implementation, which is a bit of a maintenance headache.
Sure.
--
ukai
-atw
2009/6/24 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc
2009/6/25 Chris Evans cev...@google.com On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.orgwrote: Hi, yuzo, tyoshino and I start working to implement HTML5 Web Socket and write design docs WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm We'll send WebKit part to webkit-dev, if it looks ok. We'd welcome if you could give us feedback on our design docs. Interesting feature :) It's hard to tell at first glance, because the security section is empty -- but it appears like security has been considered at least in http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17. It might be worth being more explicit about security in our WebKit doc (i.e. creating a new security section). Ok, I added the security section. Anyway, the websocket protocol doc has security considerations section, but no information there yet.. Possible tests we'll want include: - Connect a web socket to some ordinary HTTP server and confirm that the connect fails. - Connect a web socket to a real web socket server that fails to return a websocket-origin header, and validate that the connect fails (if it didn't, a simple server bug could open up responses to all origins) - Check we respect the origin sent from the server. - What about redirectors? Assuming unsupported, verify that connecting to a redirector does not cause any redirection. - URL integration: what happens if a ws:// or wss:// URL is entered into the URL bar, or any other place an URL is accepted? (img tags, script tags etc). - What about embedded newline characters in the various strings the client gets to specify (URL, resource name, protocol etc). Ensure that no lines sent to the server can be caused to be split by doing this. - Length encoding: ensure we handle excessively long length encodings, e.g. 0xff 0xff 0xff... ad infinitum. Test we can handle decoded lengths that happen to be negative (or very large) when assigned to int32, int64, uint32, uint64. - Cookies: ensure we _never_ transmit any HTTP cookies over the unencrypted ws:// channel, if that cookie was marked Secure. Similar test for Authorization headers. Thanks for valuable test cases! We'll test these case. Thanks, ukai Cheers Chris Thanks, ukai --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
Hi Ukai-san,
ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
ViewHostMsg_WebSocketOpen: open a new Web Socket. called by
WebSocketHandle::connect().
int request_id // idenfity WebSocket object {GURL url, std::wstring
protocol, std::wstring origin, bool secure, [...]}
ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web
Socket connection. called by WebSocketHandle::send().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection. called
by WebSocketHandle destructor.
int request_id // Identify WebSocket object
ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
ViewMsg_WebSocketConnect: New Web Socket connection is established. will call
WebSocketHandle::client()-didConnect().
int request_id // Identify WebSocket object
ViewMsg_WebSocketRecv: a frame containing data is received on the Web Socket
connection. will add data into WebSocketHandle::bufferedData(). Process
all complete Web Socket frames, call WebSocketHandle::client()-didReceive().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other
side). will call WebSocketHandle::client()-didClose().
int request_id // Identify WebSocket object
I'm a little wondering whether these messages are async messages or
sync ones. Is it possible to add notes about their message types?
Regards,
Hironori Bono
E-mail: hb...@chromium.org
--~--~-~--~~~---~--~~
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: HTML5 Web Socket design doc
Hi,
2009/6/25 Hironori Bono (坊野 博典) hb...@chromium.org
Hi Ukai-san,
ViewHostMsg_WebSocket*: IPC messages sent from renderer to browser.
ViewHostMsg_WebSocketOpen: open a new Web Socket. called by
WebSocketHandle::connect().
int request_id // idenfity WebSocket object {GURL url, std::wstring
protocol, std::wstring origin, bool secure, [...]}
ViewHostMsg_WebSocketSend: trasmit a frame containing data over the Web
Socket connection. called by WebSocketHandle::send().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewHostMsg_WebSocketDisconnect: disconnect the Web Socket connection.
called by WebSocketHandle destructor.
int request_id // Identify WebSocket object
ViewMsg_WebSocket*: IPC messages sent from browser to renderer.
ViewMsg_WebSocketConnect: New Web Socket connection is established. will
call WebSocketHandle::client()-didConnect().
int request_id // Identify WebSocket object
ViewMsg_WebSocketRecv: a frame containing data is received on the Web
Socket connection. will add data into WebSocketHandle::bufferedData().
Process all complete Web Socket frames, call
WebSocketHandle::client()-didReceive().
int request_id // Identify WebSocket object
std::vectorunsigned char data
ViewMsg_WebSocketClose: the Web Socket connection is closed (on the other
side). will call WebSocketHandle::client()-didClose().
int request_id // Identify WebSocket object
I'm a little wondering whether these messages are async messages or
sync ones. Is it possible to add notes about their message types?
Yes. I think all of these messages are routed and async messages.
Thanks for pointing it out.
--
ukai
Regards,
Hironori Bono
E-mail: hb...@chromium.org
--~--~-~--~~~---~--~~
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: How do I deploy an NPAPI plugin over the internet from HTML ?
OK. Thanks for that Matt. At least now I know I was using the wrong mechanism. So what is the recommended way to download and install an NPAPI Plugin over the internet under Chrome ? There are 4 files that I need to download (the plugin dll plus 3 helper files): npmyplugin.dll mylibrary.dll myprogA.exe myprogB.exe --~--~-~--~~~---~--~~ 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: question about helpwanted items (how it works)
It means that it is a good bug to send patches for, that will not be fixed soon by a Chromium developer. If you want to start handling it, you should post a message to chromium-dev, after you briefly thought about how to implement it and show some kind of a brief design document, if needed, or just write briefly about the way you are going to implement it. If it is a small code change and nothing big, you can simply send a patch, but it is always good to announce here or in the bug itself (or both?) that you are starting to work on it, so it will be marked as Started and so that the work will not be duplicated (even among contributors). ☆PhistucK On Thu, Jun 25, 2009 at 13:37, nakro yoav.zilberb...@gmail.com wrote: when you mark an itemm as helpWanted, how is it supposed to work from there ? for example, i replied to http://code.google.com/p/chromium/issues/detail?id=6383 a week ago, saying i want to do it and got to response or do you expect one to submit code for review and link it to the help wanted item ? (btw, if you will respond to this, i prefer Ctrl+Shift for text only zoom) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux buildbots, which locale?
http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio I just committed a change that converted our sys_string_conversion_linux from using ICU UTF-8 (assuming that the system locale was always UTF-8) to calling the system APIs that will vary depending on the locale. I believe this is technically what we want, we want these APIs to do the conversion to whatever locale your system is set to. On my machine these all pass fine. I don't know what locale we have set on the buildbots, but it all seems to fail. It is also kind of curious that some of our net/file tests depend on locale, but I suppose that makes sense. For now I'll pull out my changes until we can get the buildbots on a utf-8 locale (like en_US.UTF-8). -- dean --~--~-~--~~~---~--~~ 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 buildbots, which locale?
I just took a look at what was happening on one of the Linux buildbots. It looks like we completely clear the env and just explicitly set a few things. We need to add LANG=en_US.UTF-8 to that list of things. Any takers? Thanks On Thu, Jun 25, 2009 at 2:12 PM, Dean McNameede...@chromium.org wrote: http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/base_unittests/logs/stdio http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/9486/steps/net_unittests/logs/stdio I just committed a change that converted our sys_string_conversion_linux from using ICU UTF-8 (assuming that the system locale was always UTF-8) to calling the system APIs that will vary depending on the locale. I believe this is technically what we want, we want these APIs to do the conversion to whatever locale your system is set to. On my machine these all pass fine. I don't know what locale we have set on the buildbots, but it all seems to fail. It is also kind of curious that some of our net/file tests depend on locale, but I suppose that makes sense. For now I'll pull out my changes until we can get the buildbots on a utf-8 locale (like en_US.UTF-8). -- dean --~--~-~--~~~---~--~~ 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: question about helpwanted items (how it works)
On Thu, Jun 25, 2009 at 3:37 AM, nakroyoav.zilberb...@gmail.com wrote: when you mark an itemm as helpWanted, how is it supposed to work from there ? If it's an obvious bug, like page fails to scroll if screen is in 16 bit color mode, then you can just comment on the bug that you're looking into it and then submit a patch. If it's a larger design issue, or feature request that changes the UI, it's good to bring it up on chromium-dev for discussion. Which you've done. :) for example, i replied to http://code.google.com/p/chromium/issues/detail?id=6383 a week ago, saying i want to do it and got to response If someone else was thinking about working on that bug, they would now look at it and see that you had mentioned you were working on it. They would then likely ask you if you were still working on it, or if you had given up and forgotten to update the bug. So it's effectively yours to work on, now. (btw, if you will respond to this, i prefer Ctrl+Shift for text only zoom) The options, from the bug, are Ctrl+Alt or Ctrl+Shift. I don't know how we'd choose, so I'd just pick one for your patch, implement it, and if there's a reason to change it it'd be pretty easy to switch. --~--~-~--~~~---~--~~ 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 buildbots, which locale?
On Thu, Jun 25, 2009 at 6:27 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Thu, Jun 25, 2009 at 5:27 AM, Dean McNamee de...@chromium.org wrote: I just took a look at what was happening on one of the Linux buildbots. It looks like we completely clear the env and just explicitly set a few things. We need to add LANG=en_US.UTF-8 to that list of things. Any takers? I can add LANG to the list of whitelisted env var to keep. Would that work? If any of our tests depend on a particular locale, we should have them set that locale first. man setlocale (and man 7 locale) Be sure to reset the locale in the tear-down. --~--~-~--~~~---~--~~ 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 buildbots, which locale?
On Thu, Jun 25, 2009 at 7:03 AM, Evan Martin e...@chromium.org wrote: On Thu, Jun 25, 2009 at 6:27 AM, Nicolas Sylvainnsylv...@chromium.org wrote: On Thu, Jun 25, 2009 at 5:27 AM, Dean McNamee de...@chromium.org wrote: I just took a look at what was happening on one of the Linux buildbots. It looks like we completely clear the env and just explicitly set a few things. We need to add LANG=en_US.UTF-8 to that list of things. Any takers? I can add LANG to the list of whitelisted env var to keep. Would that work? If any of our tests depend on a particular locale, we should have them set that locale first. man setlocale (and man 7 locale) Be sure to reset the locale in the tear-down. I made the bot at least keep the current lang, but I agree that it should be set by the test if it needs to be something specific. Nicolas --~--~-~--~~~---~--~~ 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: question about helpwanted items (how it works)
I agree, but no browser has a keyboard shortcut for this what FF and Safari have is a menu option to change the behavior of Zoom (via a check box) and IE only does full page zoom since chrome is so religious about minimal UI, i thought to have these options with no UI at all but i can easily add this feature to windows if needed but i think it makes more sense to have both options available via the keyboard as some pages are better for Full page zoom, while others look better with text only zoom but whatever you chose is fine by me, --~--~-~--~~~---~--~~ 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: question about helpwanted items (how it works)
I wasn't suggesting we should add a UI in addition/instead of a keyboard modifier. Since there is no standard modifier you should do as Evan suggested an just pick one. We can always change it. On Thu, Jun 25, 2009 at 08:14, nakro yoav.zilberb...@gmail.com wrote: I agree, but no browser has a keyboard shortcut for this what FF and Safari have is a menu option to change the behavior of Zoom (via a check box) and IE only does full page zoom since chrome is so religious about minimal UI, i thought to have these options with no UI at all but i can easily add this feature to windows if needed but i think it makes more sense to have both options available via the keyboard as some pages are better for Full page zoom, while others look better with text only zoom but whatever you chose is fine by me, --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
The WebKit API classes still derive from WebCore, which isn't possible. The
WebKit API is an abstraction around WebCore classes, so it can't use any
WebCore types in it.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
hmm, I actually find WebWeb very unwieldy. I vote for
WebKit::WebSocketHandle.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
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: Memory usage in chrome
On Thu, Jun 25, 2009 at 9:40 AM, Mike Beltzner beltz...@mozilla.com wrote: On 22-Jun-09, at 12:57 PM, Mike Belshe wrote: Yes, that accurately represents the private memory for a process, but it doesn't reflect the user's experience. Windows generally tracks working set. Why? Because the working set is the amount of memory *not available to other apps*. If other apps can have the memory, then using the bytes is inconsequential. Figuring out how to track this is a bit of a terminology mess ;) Referring to the following document: http://msdn.microsoft.com/en-us/library/aa965225(VS.85).aspx Yeah, the APIs all have constraints. We end up walking the pages and adding them up. See process_util_win.cc in the chromium tree. Be sure to check about:memory and hover over the little ? icons to see what we measure. http://msdn.microsoft.com/en-us/library/aa965225(VS.85).aspx If someone measures the Private Bytes counter, which uses the PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map to the Task Manager Commit Size which isn't the thing I believe we want to measure. Right. The Working Set - Private counter doesn't seem to have a structure according to the MSDN document; that's what maps to the Memory (Private Working Set) column in the TaskManager. Right, I think you have to use QueryWorkingSet, walk the pages and categorize them yourself. The closest thing I can find is the Working Set counter, which uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up in the Vista Task Manager as Working Set (Memory) For multi-proc browsers like chrome, this will way overstate RAM; there is a good 5-6MB of shared working set in each process. So for 10 tabs, you'd could an extra 50MB for Chrome if you do it this way. I wish it were easier too. In Vista's task manager, the primary metric is Memory (Private Working Set), and I believe the only way to get this number is to call QueryWorkingSet, walk the pages, and add up the ones which are marked as private. If you come up with a better way, please let me know! Mike Would you agree that summating the data from the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure would give a fair indication of memory usage? cheers, mike --~--~-~--~~~---~--~~ 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: HTML5 Web Socket design doc
2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in the
webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know ResourceHandle
is a refcounted object and this design looks modeled off of that (which may
be why you've spec'd it this way). Unless your design actually needs
refcounting on this class, you may be able to simplify things without it.
From the looks of it, WebSocketChannel 'owns' the WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
I was suggesting that perhaps the WebSocketHandle does not need to be
refcounted.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made a
good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
I haven't read the web sockets spec, so I don't know what the 'handshaking'
entails?
OS level socket creation/destruction and tcp connection opening/closing
needs to be per-platform. Once you have a full-duplex connection and are
sending application 'protocol' data back and forth (message framing), that
probably wants to be common code. Which camp does the 'handshaking' fall
into?
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Chromium-reviews is down
The chromium-reviews emailing list has been blacklisted (for spam apparently). No review email is going out. We're working to get the list restored, but don't have an ETA at this point. In the meantime, you'll need to ping people directly to let them know about pending reviews and comments. --Mark --~--~-~--~~~---~--~~ 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: Chromium-reviews is down
You can also point a feed reader at http://codereview.chromium.org/rss/all I think. On Thu, Jun 25, 2009 at 11:05 AM, Mark Larson (Google)m...@chromium.org wrote: The chromium-reviews emailing list has been blacklisted (for spam apparently). No review email is going out. We're working to get the list restored, but don't have an ETA at this point. In the meantime, you'll need to ping people directly to let them know about pending reviews and comments. --Mark --~--~-~--~~~---~--~~ 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: Chromium-reviews is down
And chromium-bugs has also been blacklisted for the same reason. On Jun 25, 11:10 am, Evan Martin e...@chromium.org wrote: You can also point a feed reader at http://codereview.chromium.org/rss/all I think. On Thu, Jun 25, 2009 at 11:05 AM, Mark Larson (Google)m...@chromium.org wrote: The chromium-reviews emailing list has been blacklisted (for spam apparently). No review email is going out. We're working to get the list restored, but don't have an ETA at this point. In the meantime, you'll need to ping people directly to let them know about pending reviews and comments. --Mark --~--~-~--~~~---~--~~ 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: Is it possible to do a gclient sync without running hooks?
Send patches to gclient.py to 'disable automatic runhooks on sync' to me. You can hack directly inside your depot_tools and use 'gcl change bleh' and 'gcl upload bleh --send-mail -r mar...@chromium.org'. You'll need to update the unit tests. M-A On Tue, Jun 23, 2009 at 9:01 PM, Nicolas Sylvainnsylv...@chromium.org wrote: On Tue, Jun 23, 2009 at 5:53 PM, Daniel Cowx daniel.c...@gmail.com wrote: When I run gclient sync, it automatically runs the hooks; which causes various non-versioned files to get generated within my tree (most notably *.vcproj and *.sln files, but there may be others). I'd like to be able to do a sync *without* generating any files (i.e. so that if I do a svn status immediately after a gclient sync, I see a pristine unmodified tree). Short of going into src/DEPS and commenting out the hooks section, can this be done? I don't think we have this capability at this time. But in theory if you gclient sync ; svn status you should not see anything, since all the generated files should be in the svn:ignore. If they are not, then someone forgot to add them, and we should fix that. Nicolas --~--~-~--~~~---~--~~ 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: about gtest's main in chromium
It's set through .sln dependencies; src\chromepython tools\build\win\sln_deps.py chrome.sln printing_unittests printing_unittests base gtest gtestmain icui18n icuuc printing M-A 2009/6/25 Jickae Davis jick...@gmail.com: ah, in fact, I don't really understand what the .gyp files do. Could the gtestmain be found in printing_unittests' project properties under VS2005? I have check that, and didn't find a gtestmain.lib in Configuration Properties--Linker--Input. 2009/6/25 William Chan (陈智昌) willc...@chromium.org printing_unittests depends on gtestmain.lib. See src/printing/printing.gyp. On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davisjick...@gmail.com wrote: yep, for base_unittests, that's true. But what I want to know is how chromium uses GTest. An important problem is how it runs all the GTest projects. Take the simplest GTest project printing_unittests as an example, I know it's run via GTest's main in run_all_unittests.cc. But I don't know how it invokes the main. I checked the project properties of printing_unittests, and didn't find a link to gtestmain.lib as I always do while writing GTest tests. 2009/6/23 Adam Langley a...@chromium.org On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. 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: question about helpwanted items (how it works)
In any case, make sure to ping the @chromium.org person that added the HelpWanted flag! M-A On Thu, Jun 25, 2009 at 11:29 AM, Finnur Thorarinssonfin...@chromium.org wrote: I wasn't suggesting we should add a UI in addition/instead of a keyboard modifier. Since there is no standard modifier you should do as Evan suggested an just pick one. We can always change it. On Thu, Jun 25, 2009 at 08:14, nakro yoav.zilberb...@gmail.com wrote: I agree, but no browser has a keyboard shortcut for this what FF and Safari have is a menu option to change the behavior of Zoom (via a check box) and IE only does full page zoom since chrome is so religious about minimal UI, i thought to have these options with no UI at all but i can easily add this feature to windows if needed but i think it makes more sense to have both options available via the keyboard as some pages are better for Full page zoom, while others look better with text only zoom but whatever you chose is fine by me, --~--~-~--~~~---~--~~ 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: Gmock compilation errors on VS2008SP1
I haven't heard back about any more VS2008 issues. I'm going to remove boost tuple from the chromium tree next week, which will break the workaround nakro posted earlier. If there any more VS2008 issues, please let me know soon so I don't break you. :) Thanks, Albert On Tue, Jun 23, 2009 at 9:49 PM, Albert J. Wong (王重傑) ajw...@chromium.orgwrote: Hi Thiago, Did you sync pas revision 19049? And did you do a clean build? Thanks, Albert On Tue, Jun 23, 2009 at 9:37 AM, Thiago Farina thiago.far...@gmail.comwrote: I have the same problem with tuple. On Jun 15, 1:24 pm, Marc-Antoine Ruel mar...@chromium.org wrote: I'm fine with that if necessary. On Mon, Jun 15, 2009 at 12:11 PM, Albert J. Wong(王重傑) ajw...@chromium.org wrote: On Mon, Jun 15, 2009 at 9:03 AM, nakro yoav.zilberb...@gmail.com wrote: Hi albret, projects that fail : gmockj gmockmain here is an example out from gmockmain C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(498) : error C2065: '_Is_swap_move' : undeclared identifier 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple (504) : see reference to class template instantiation 'std::_Move_operation_categorystd::tr1::tuple_Arg0,_Arg1,_Arg2,_Arg3,_Arg 4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9' being compiled 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(499) : error C2226: syntax error : unexpected type 'std::_Move_operation_category_Value::_Move_cat' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2947: expecting '' to terminate template-argument-list, found '' 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include\tuple(503) : error C2976: 'std::_If' : too few template arguments 1C:\Program Files\Microsoft Visual Studio 9.0\VC\include \xutility(1018) : see declaration of 'std::_If' the solution on my machine is this to do HAS_TR1=0 (you have 1 by default) and to change gmock_port.h to include the boost version even on 2008, which initially your code goes to the tuple path That's a good workaround. Switching to the boost implementation would almost certainly work for now. I'll attempt to reproduce and figure out a long term fix (including just whacking the tr1 dependency out of gmock...started a discussion with zhanyong about this last week). If it gets bad enough, we could consider changing over the VS2008 builds to use boost as well, and then disable _HAS_TR1 as you described above, but that'll require a full clobber from everyone due to precompiled header issues. -Albert but i must have something wrong with my machine if i am the only one who is having this --~--~-~--~~~---~--~~ 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: How do I deploy an NPAPI plugin over the internet from HTML ?
On Thu, Jun 25, 2009 at 1:54 AM, Non-Stick kevin.ra...@ntlworld.com wrote: OK. Thanks for that Matt. At least now I know I was using the wrong mechanism. So what is the recommended way to download and install an NPAPI Plugin over the internet under Chrome ? There's no way to make Chrome download your plugin automatically. You're going to have to build an installer for your plugin and point your users to it if it's not available. There are 4 files that I need to download (the plugin dll plus 3 helper files): npmyplugin.dll mylibrary.dll myprogA.exe myprogB.exe --~--~-~--~~~---~--~~ 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: Chromium-reviews is down
And the chromium-bugs list has also been blacklisted for the same reason. On Jun 25, 11:05 am, Mark Larson (Google) m...@chromium.org wrote: The chromium-reviews emailing list has been blacklisted (for spam apparently). No review email is going out. We're working to get the list restored, but don't have an ETA at this point. In the meantime, you'll need to ping people directly to let them know about pending reviews and comments. --Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Purify/Valgrind FIXIT
For people looking for FIXIT items next week, these are lists of Purify/Valgrind FIXIT bugs without owner assigned. http://code.google.com/p/chromium/issues/list?can=2q=purify+label:fixit+-has:ownersort=pricolspec=ID+Stars+Pri+Area+Type+Status+Summary+Modified+Owner+Mstonex=mstoney=areacells=tiles http://code.google.com/p/chromium/issues/list?can=2q=valgrind+label:fixit+-has:ownersort=pricolspec=ID+Stars+Pri+Area+Type+Status+Summary+Modified+Owner+Mstonex=mstoney=areacells=tiles Huan --~--~-~--~~~---~--~~ 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: Memory usage in chrome
On 25-Jun-09, at 12:52 PM, Mike Belshe wrote: Yeah, the APIs all have constraints. We end up walking the pages and adding them up. See process_util_win.cc in the chromium tree. Be sure to check about:memory and hover over the little ? icons to see what we measure. This screen actually confuses me a little, as the Summary statistics don't match the summation of the process based statistics. Do you mean to say your summary statistics take into account the memory that's being shared across the various processes? If so, is there any command-line switch that will output those summary stats to console on a regular basis? If someone measures the Private Bytes counter, which uses the PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map to the Task Manager Commit Size which isn't the thing I believe we want to measure. Right. Interestingly, as I watched this value change while webpages were loading, it tracked the same pattern of growth/decline as Memory (Private Working Set) in the Task Manager, though the values were usually about 2x or so more. I suppose this is due to the heap sharing you were speaking of earlier? The Working Set - Private counter doesn't seem to have a structure according to the MSDN document; that's what maps to the Memory (Private Working Set) column in the TaskManager. Right, I think you have to use QueryWorkingSet, walk the pages and categorize them yourself. OK, I can look into trying that. Though I'm wondering if it's worth the bother, as the meta-pattern, to me, is more interesting than the precise megabyte count. The closest thing I can find is the Working Set counter, which uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up in the Vista Task Manager as Working Set (Memory) For multi-proc browsers like chrome, this will way overstate RAM; there is a good 5-6MB of shared working set in each process. So for 10 tabs, you'd could an extra 50MB for Chrome if you do it this way. Looking both in Task Manager and about:memory, when I have 30 tabs open I'm not seeing 30 processes. Are you sure you're right about this point? If you come up with a better way, please let me know! Well, I can tell you what we've done and what we're doing, just trying to get confidence on various metrics. We've replicated the membuster test we used around the release of Firefox 3 (see http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ ) as a way of measuring Firefox's ability to hold a steady state of memory across a browsing session (ie: not leak) and then release that memory when the session ends (ie: not bogart system resources). The test: - runs on Windows 7, using Python and our Standalone Talos code to make measurements - uses a local web proxy to ensure we're always viewing the same web content - uses the JS at view-source:http://random.pavlov.net/membuster/index.html to: --- open 30 pages using window.open() calls --- load ~300 pages, opening and closing windows with each load (always 30 open) --- close all 30 windows when done cycling The whole while, we measure the amount of memory taken using the PROCESS_MEMORY_COUNTERS structure, summating over processes when multiple exist (as they do in the case of Internet Explorer 8 and Chrome 2) The results can be seen here, using both the PrivateUsage (shows as Commit Size in Windows 7 Task Manager) and WorkingSet (shows as Working Set (Memory) in Windows 7 Task Manager) counters: http://people.mozilla.com/~beltzner/images/private-usage.png http://people.mozilla.com/~beltzner/images/working-set.png The datapoint we wanted to get out of this was primarily about Firefox 3.5 vs Firefox 3.0.11, and as you can see we actually take slightly (7-10MB) more memory during the page cycling, but manage to release more when done. Safari had previously been unable to complete this test, but now does. I'd love to get your feedback on how we can improve our recording here. I think we're going to try and bundle together the test and files into an easier-to-use-tool than our delicately cobbled together solution, but if you wanted to try it yourself, here's a ZIP with the required code (needs Python 2.5 or later to be installed on your system): Once unzipped, enter the directory and run the following commands: \path\to\python\python.exe proxyserver.py -v -l -u proxy-cache.db \path\to\python\python.exe measure_any_windows_app.py \path\to \resultsfile\resultsfile.txt You'll want to edit measure_any_windows_app.py to have the correct paths to the various applications, and you'll also want to make sure your browsers are set to use 127.0.0.1 port 8000 as a proxy (under Advanced Network Settings in Firefox, Internet Properties Connections LAN Settings for Chrome/IE/Safari) (Thanks to David Dahl for modifying the required files to get at those measurements) cheers,
[chromium-dev] Re: Memory usage in chrome
On 25-Jun-09, at 6:26 PM, Mike Beltzner wrote: here's a ZIP with the required code (needs Python 2.5 or later to be installed on your system): Oops, forgot the link! http://people.mozilla.org/~beltzner/membuster-talos.rar cheers, mike --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Landing two sided patches
Dear Lords of the WebKit, I come to you seeking guidance about how best to avoid the mess that the tree got into this afternoon. Japhet and I both had two sided patches to land (where one needs to land both the WebKit and Chromium sides together). We emailed the merger for the day (jianli) and asked him to email us when the merge landed. He did so and I closed the tree. japhet and I both started landing upstream. I landed r45191 and the Chromium side (including a large DEPS roll) in r19287. japhet landed upstream in r45193 and r19291. The tree went red because V8IsolatedWorld had landed upstream in the mean time and needed an include file changed because of japhet's upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295). However, that pulled in several other upstream patches, one of which broke the build in another way! So I TBRed upstream to fix that (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness of keyboard, no other patches landed upstream in the mean time. In the past, for small patches, I've emailed the WebKit merger with the patch to land. However, for larger patches, esp those which might have conflicts, this seems unfortunate. It also breaks the SVN log/blame for the future. How best to deal with this now that we pull directly from upstream? Should I just have reverted Chromium at the first sign of trouble? 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: Memory usage in chrome
On Thu, Jun 25, 2009 at 3:26 PM, Mike Beltzner beltz...@mozilla.com wrote: On 25-Jun-09, at 12:52 PM, Mike Belshe wrote: Yeah, the APIs all have constraints. We end up walking the pages and adding them up. See process_util_win.cc in the chromium tree. Be sure to check about:memory and hover over the little ? icons to see what we measure. This screen actually confuses me a little, as the Summary statistics don't match the summation of the process based statistics. Do you mean to say your summary statistics take into account the memory that's being shared across the various processes? Correct. The shared across all processes is a bit of a hack, because you can't know exactly which pages are shared across every single process. We do a heuristic. If so, is there any command-line switch that will output those summary stats to console on a regular basis? You can use --enable-logging --log-level=0 - each time you refresh the about:memory page, it will drop a line to the log file. This can be useful for plots over time. If someone measures the Private Bytes counter, which uses the PROCESS_MEMORY_COUNTERS_EX.PrivateUsage structure, that seems to map to the Task Manager Commit Size which isn't the thing I believe we want to measure. Right. Interestingly, as I watched this value change while webpages were loading, it tracked the same pattern of growth/decline as Memory (Private Working Set) in the Task Manager, though the values were usually about 2x or so more. I suppose this is due to the heap sharing you were speaking of earlier? I'm not quite sure what you mean. But of course, as you load more tabs, you'll see the memory use go up. The Working Set - Private counter doesn't seem to have a structure according to the MSDN document; that's what maps to the Memory (Private Working Set) column in the TaskManager. Right, I think you have to use QueryWorkingSet, walk the pages and categorize them yourself. OK, I can look into trying that. Though I'm wondering if it's worth the bother, as the meta-pattern, to me, is more interesting than the precise megabyte count. For a single process browser, it's not worth the effort; I think it's the only way to know how to account for shared memory. The closest thing I can find is the Working Set counter, which uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up in the Vista Task Manager as Working Set (Memory) For multi-proc browsers like chrome, this will way overstate RAM; there is a good 5-6MB of shared working set in each process. So for 10 tabs, you'd could an extra 50MB for Chrome if you do it this way. Looking both in Task Manager and about:memory, when I have 30 tabs open I'm not seeing 30 processes. Are you sure you're right about this point? You don't always get a new process for every tab. If two tabs are connected via javascript, then they'll be in the same process (the about:memory shows which tabs are in the same process). So, clicking a link, for example, will open in the same tab, but typing the URL in the omnibox will create a new process. Others could tell you more about the exact policy for when you get a new process and when you don't. If you come up with a better way, please let me know! Well, I can tell you what we've done and what we're doing, just trying to get confidence on various metrics. We've replicated the membuster test we used around the release of Firefox 3 (see http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/ ) as a way of measuring Firefox's ability to hold a steady state of memory across a browsing session (ie: not leak) and then release that memory when the session ends (ie: not bogart system resources). The test: - runs on Windows 7, using Python and our Standalone Talos code to make measurements - uses a local web proxy to ensure we're always viewing the same web content - uses the JS at view-source: http://random.pavlov.net/membuster/index.html to: --- open 30 pages using window.open() calls --- load ~300 pages, opening and closing windows with each load (always 30 open) --- close all 30 windows when done cycling OK - I think this might basically use one renderer process in chrome? Because of the new-process creation policy, it may not be representative of real world usage. Darin? The whole while, we measure the amount of memory taken using the PROCESS_MEMORY_COUNTERS structure, summating over processes when multiple exist (as they do in the case of Internet Explorer 8 and Chrome 2) Ok - that will double count shared memory. I'd estimate 3-5MB per process. The results can be seen here, using both the PrivateUsage (shows as Commit Size in Windows 7 Task Manager) and WorkingSet (shows as Working Set (Memory) in Windows 7 Task Manager) counters: http://people.mozilla.com/~beltzner/images/private-usage.png http://people.mozilla.com/~beltzner/images/working-set.png
[chromium-dev] Re: Memory usage in chrome
On 25-Jun-09, at 7:02 PM, Mike Belshe wrote: This screen actually confuses me a little, as the Summary statistics don't match the summation of the process based statistics. Do you mean to say your summary statistics take into account the memory that's being shared across the various processes? Correct. The shared across all processes is a bit of a hack, because you can't know exactly which pages are shared across every single process. We do a heuristic. Cool! Good to know. I'll take a peek into that code you mentioned to see what the heuristic is that you're using. Interestingly, as I watched this value change while webpages were loading, it tracked the same pattern of growth/decline as Memory (Private Working Set) in the Task Manager, though the values were usually about 2x or so more. I suppose this is due to the heap sharing you were speaking of earlier? I'm not quite sure what you mean. I'm basically being lazy. I'd like to not have to make my own counter for Private Working Set, so I watched the values of Memory (Private Working Set) and Commit Size in the Task Manager as the test ran, and noticed that they increased/decreased at the same time, and the delta between them was a near constant 2x. Since my interest here is developing a metric that can help us understand when we're regressing/ improving memory usage, the exact value isn't as important to me as the delta. If the deltas are simply off by a constant factor, I could live with that. As I said: lazy! The Working Set - Private counter doesn't seem to have a structure according to the MSDN document; that's what maps to the Memory (Private Working Set) column in the TaskManager. Right, I think you have to use QueryWorkingSet, walk the pages and categorize them yourself. OK, I can look into trying that. Though I'm wondering if it's worth the bother, as the meta-pattern, to me, is more interesting than the precise megabyte count. For a single process browser, it's not worth the effort; I think it's the only way to know how to account for shared memory. The closest thing I can find is the Working Set counter, which uses the PROCESS_MEMORY_COUNTERS_EX.WorkingSetSize structure and shows up in the Vista Task Manager as Working Set (Memory) For multi-proc browsers like chrome, this will way overstate RAM; there is a good 5-6MB of shared working set in each process. So for 10 tabs, you'd could an extra 50MB for Chrome if you do it this way. Looking both in Task Manager and about:memory, when I have 30 tabs open I'm not seeing 30 processes. Are you sure you're right about this point? You don't always get a new process for every tab. If two tabs are connected via javascript, then they'll be in the same process (the about:memory shows which tabs are in the same process). So, clicking a link, for example, will open in the same tab, but typing the URL in the omnibox will create a new process. Others could tell you more about the exact policy for when you get a new process and when you don't. Someone just did in IRC, actually. Apparently in addition to what you said, as soon as a page is in cache, processes get pooled. I clear caches between test runs, but it sounds like since we're calling these with window.open() in our test, they all get placed in the same process. Overall, though, that should mean that we're *not* double counting memory. In fact, when I observed as the test ran, there were only three processes: one for the browser, one for the single content process from which all tabs were spawned, and one for Shockwave/Flash. Good news, I guess, in terms of reporting accurately! OK - I think this might basically use one renderer process in chrome? Because of the new-process creation policy, it may not be representative of real world usage. Darin? Right, but AIUI, it's an erring on the side of reporting less, not more. If there's a better way to automate pageloads that represents real world usage, please let me know. The whole while, we measure the amount of memory taken using the PROCESS_MEMORY_COUNTERS structure, summating over processes when multiple exist (as they do in the case of Internet Explorer 8 and Chrome 2) Ok - that will double count shared memory. I'd estimate 3-5MB per process. So we're talking about over-reporting by 9-15MB across the test. Again, good to know. I'll try to take a closer look at your test, but I'm not sure when I'll have time :-( No rush here, and I appreciate your time and candor to date! cheers, mike --~--~-~--~~~---~--~~ 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: Landing two sided patches
I suspect there are things we can do that will avoid much of the need to do a Chromium side change in unison with a WebKit side change. #1 is probably upstreaming some .gypi files so that the set of files to build can be stored in svn.webkit.org. The WebKit API will also help, and completing the upstreaming of V8 is another biggie. -Darin On Thu, Jun 25, 2009 at 3:53 PM, Adam Langley a...@chromium.org wrote: Dear Lords of the WebKit, I come to you seeking guidance about how best to avoid the mess that the tree got into this afternoon. Japhet and I both had two sided patches to land (where one needs to land both the WebKit and Chromium sides together). We emailed the merger for the day (jianli) and asked him to email us when the merge landed. He did so and I closed the tree. japhet and I both started landing upstream. I landed r45191 and the Chromium side (including a large DEPS roll) in r19287. japhet landed upstream in r45193 and r19291. The tree went red because V8IsolatedWorld had landed upstream in the mean time and needed an include file changed because of japhet's upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295). However, that pulled in several other upstream patches, one of which broke the build in another way! So I TBRed upstream to fix that (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness of keyboard, no other patches landed upstream in the mean time. In the past, for small patches, I've emailed the WebKit merger with the patch to land. However, for larger patches, esp those which might have conflicts, this seems unfortunate. It also breaks the SVN log/blame for the future. How best to deal with this now that we pull directly from upstream? Should I just have reverted Chromium at the first sign of trouble? 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] gclient runhooks --force not forceful enough?
I did rm Makefile gclient runhooks --force and it didn't regenerate Makefile. tools/gyp/gyp -f make build/all.gyp does rebuild it. Seems like gclient runhooks --force ought to, no? --~--~-~--~~~---~--~~ 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: gclient runhooks --force not forceful enough?
Doesn't gclient runhooks --force setup the scons build on linux? Or did the make build become default at some point? On Thu, Jun 25, 2009 at 5:57 PM, Dan Kegel daniel.r.ke...@gmail.com wrote: I did rm Makefile gclient runhooks --force and it didn't regenerate Makefile. tools/gyp/gyp -f make build/all.gyp does rebuild it. Seems like gclient runhooks --force ought to, no? --~--~-~--~~~---~--~~ 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: gclient runhooks --force not forceful enough?
On Thu, Jun 25, 2009 at 6:03 PM, Albert J. Wong (王重傑)ajw...@chromium.org wrote: Doesn't gclient runhooks --force setup the scons build on linux? Or did the make build become default at some point? Forgot to mention, I have GYP_GENERATORS=make in my environment. The scons build is so slow I can't bear to go back. --~--~-~--~~~---~--~~ 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: gclient runhooks --force not forceful enough?
On Thu, Jun 25, 2009 at 5:57 PM, Dan Kegeldaniel.r.ke...@gmail.com wrote: I did rm Makefile gclient runhooks --force and it didn't regenerate Makefile. tools/gyp/gyp -f make build/all.gyp does rebuild it. Seems like gclient runhooks --force ought to, no? Are you seeing the same thing I am seeing ? For me, through gclient, Makefile is generated one directory up and is messed up. Antoine --~--~-~--~~~---~--~~ 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: gclient runhooks --force not forceful enough?
On Thu, Jun 25, 2009 at 6:13 PM, Antoine Labourpi...@google.com wrote: Are you seeing the same thing I am seeing ? For me, through gclient, Makefile is generated one directory up and is messed up. By gum, yes: $ diff Makefile ../Makefile 22c22 builddir ?= /home/dkegel/chrome-build/src/out/$(BUILDTYPE) --- builddir ?= /home/dkegel/chrome-build/out/$(BUILDTYPE) That explains a few things. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] apologies for build breakage
I did run it through try bots, but overlooked mac because it finished running my job 50 minutes after I submitted it. :~( The especial irony was that the patch is for windowed plugins, which only exist on Windows and Linux; it was just getting typedefs wrong. I will try again later. --~--~-~--~~~---~--~~ 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: apologies for build breakage
We're working on adding more trybot capacity (3x for Mac). Additional Macs should come online in the next week or so, which will reduce the try latency. Right now, we're really underpowered. Yoda would be happy that there is no try. Developers, not so much. --Mark On Thu, Jun 25, 2009 at 18:39, Evan Martin e...@chromium.org wrote: I did run it through try bots, but overlooked mac because it finished running my job 50 minutes after I submitted it. :~( The especial irony was that the patch is for windowed plugins, which only exist on Windows and Linux; it was just getting typedefs wrong. I will try again later. --~--~-~--~~~---~--~~ 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: about gtest's main in chromium
y, that's what I want. I know nothing about .gyp files, that's the way I can understand, 3x~! 2009/6/26 Marc-Antoine Ruel mar...@chromium.org It's set through .sln dependencies; src\chromepython tools\build\win\sln_deps.py chrome.sln printing_unittests printing_unittests base gtest gtestmain icui18n icuuc printing M-A 2009/6/25 Jickae Davis jick...@gmail.com: ah, in fact, I don't really understand what the .gyp files do. Could the gtestmain be found in printing_unittests' project properties under VS2005? I have check that, and didn't find a gtestmain.lib in Configuration Properties--Linker--Input. 2009/6/25 William Chan (陈智昌) willc...@chromium.org printing_unittests depends on gtestmain.lib. See src/printing/printing.gyp. On Wed, Jun 24, 2009 at 12:46 AM, Jickae Davisjick...@gmail.com wrote: yep, for base_unittests, that's true. But what I want to know is how chromium uses GTest. An important problem is how it runs all the GTest projects. Take the simplest GTest project printing_unittests as an example, I know it's run via GTest's main in run_all_unittests.cc. But I don't know how it invokes the main. I checked the project properties of printing_unittests, and didn't find a link to gtestmain.lib as I always do while writing GTest tests. 2009/6/23 Adam Langley a...@chromium.org On Mon, Jun 22, 2009 at 7:55 PM, Jickae Davisjick...@gmail.com wrote: But I find something weird in the chromiun's GTest projects, they neither write a main nor link a gtest_main.lib. How do they start GTest? Well, you can always set a breakpoint at main and see where you end up. For base_unittests, it's base/run_all_unittests.cc for example. 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: gclient runhooks --force not forceful enough?
On Thu, Jun 25, 2009 at 6:20 PM, Dan Kegeld...@kegel.com wrote: On Thu, Jun 25, 2009 at 6:13 PM, Antoine Labourpi...@google.com wrote: Are you seeing the same thing I am seeing ? For me, through gclient, Makefile is generated one directory up and is messed up. By gum, yes: $ diff Makefile ../Makefile 22c22 builddir ?= /home/dkegel/chrome-build/src/out/$(BUILDTYPE) --- builddir ?= /home/dkegel/chrome-build/out/$(BUILDTYPE) That explains a few things. Oh, goody, that means I'm not crazy ! Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Where is the CGContextDrawImage() for MacOSx defined
Hi, Can you please tell me Where is the CGContextDrawImage() for MacOSx defined? I have tried setting up a Breakpoints in ImageCG.cpp:197. It breaks there but when I click 'step into', it never goes to the implementation of CGContextDrawImage. XCode just jumps to the next line. And I also tried building a cscope myself (include .mm file), but when I look for CGContextDrawImage(), it only gives me callers for that function: *** src/skia/ext/skia_utils_mac.mm: global[107] CGContextDrawImage(context, rect, image); *** src/third_party/WebKit/WebCore/platform/graphics/cg/ImageCG.cpp: global[118] CGContextDrawImage(bmap, dst, image); global[197] CGContextDrawImage(context, adjustedDestRect, image); global[211] CGContextDrawImage(context, GraphicsContext(context).roundToDevicePixels(FloatRect(0, 0, CGImageGetWidth(image), CGImageGetHeight(image))), image); *** src/third_party/WebKit/WebCore/platform/graphics/cg/PatternCG.cpp: global[45] CGContextDrawImage(context, rect, platformImage); *** src/third_party/WebKit/WebCore/platform/graphics/win/GraphicsContextCGWin.cpp: global[101] CGContextDrawImage(m_data-m_cgContext, dstRect, image); global[124] CGContextDrawImage(m_data-m_cgContext, CGRectMake(point.x(), point.y(), image-size().width(), image-size().height()), cgImage.get()); *** src/third_party/WebKit/WebCore/platform/win/DragImageCGWin.cpp: global[111] CGContextDrawImage(targetContext, rect, srcImage); global[156] CGContextDrawImage(drawContext, rect, srcImage); *** src/third_party/skia/src/ports/SkImageDecoder_CG.cpp: global[83] CGContextDrawImage(cg, CGRectMake(0, 0, width, height), image); *** src/webkit/glue/webcursor_mac.mm: global[172] CGContextDrawImage(context.get(), rect, image_ptr); *** src/skia/ext/bitmap_platform_device_mac.cc: DrawToContext[299] CGContextDrawImage(context, bounds, sub_image); DrawToContext[306] CGContextDrawImage(context, bounds, image); *** src/third_party/WebKit/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm: print[372] CGContextDrawImage(context, CGRectMake(0, 0, width, height), image.get()); *** src/third_party/skia/experimental/CiCarbonSampleMain.c: TestDraw[208] CGContextDrawImage(cg, r, ref); *** src/third_party/skia/src/utils/mac/SkBitmap_Mac.cpp: drawToPort[133]CGContextDrawImage(cg, rect, image); *** src/third_party/skia/src/utils/mac/SkOSWindow_Mac.cpp: doPaint[168] CGContextDrawImage(cg, r, img); *** src/third_party/skia/xcode/hostapp/test.cpp: SkiaDraw[60] CGContextDrawImage(cg, r, gImage); --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] how to judge layouttests' running result?
I have ran layouttests on Windows XP, and got a result as: Expected to fail, but passed (5): LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html LayoutTests/fast/encoding/invalid-UTF-8.html Expected to timeout, but passed (1): LayoutTests/http/tests/security/credentials-in-referer.html Regressions: Unexpected failures (8): LayoutTests/fast/css/css2-system-fonts.html = FAIL LayoutTests/fast/dom/anchor-toString.html = FAIL LayoutTests/fast/dom/java-applet-calls.html = FAIL LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht ml = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL LayoutTests/plugins/embed-attributes-setting.html = FAIL Regressions: Unexpected timeouts (1): LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = TI MEOUT -- = Tests to be fixed for the current release (786): 86 test cases (10.9%) Passed 364 test cases (46.3%) Skipped 289 test cases (36.8%) Text diff mismatch 191 test cases (24.3%) Simplified text diff mismatch 160 test cases (20.4%) Image mismatch 11 test cases (1.4%) Test timed out 6 test cases (0.8%) Test shell crashed 2 test cases (0.3%) No expected image found = Tests we want to pass for the current release (8984): 8271 test cases (92.1%) Passed 364 test cases (4.1%) Skipped 301 test cases (3.4%) Text diff mismatch 201 test cases (2.2%) Simplified text diff mismatch 164 test cases (1.8%) Image mismatch 12 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found = Tests to be fixed for a future release (0): = All tests (10884): 8753 test cases (80.4%) Passed 2130 test cases (19.6%) Skipped 411 test cases (3.8%) Text diff mismatch 302 test cases (2.8%) Simplified text diff mismatch 183 test cases (1.7%) Image mismatch 13 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found I don't know what it tells, am I passed the layouttests? There's also a layouttests in webkit, what's the relation between chrome's layouttest and webkit's layouttest? I think webkit's layouttest only run on Leopard. --~--~-~--~~~---~--~~ 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: Where is the CGContextDrawImage() for MacOSx defined
CGContextDrawImage() is not defined in Chromium -- it part of Mac OS X's quartz 2D library: http://developer.apple.com/documentation/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextDrawImage I imagine the reason you can't step into it with XCode, is that it has no source code to display. You should be able to step through the disassembly instead. On Thu, Jun 25, 2009 at 7:52 PM, n179911n179...@gmail.com wrote: Hi, Can you please tell me Where is the CGContextDrawImage() for MacOSx defined? I have tried setting up a Breakpoints in ImageCG.cpp:197. It breaks there but when I click 'step into', it never goes to the implementation of CGContextDrawImage. XCode just jumps to the next line. And I also tried building a cscope myself (include .mm file), but when I look for CGContextDrawImage(), it only gives me callers for that function: *** src/skia/ext/skia_utils_mac.mm: global[107] CGContextDrawImage(context, rect, image); *** src/third_party/WebKit/WebCore/platform/graphics/cg/ImageCG.cpp: global[118] CGContextDrawImage(bmap, dst, image); global[197] CGContextDrawImage(context, adjustedDestRect, image); global[211] CGContextDrawImage(context, GraphicsContext(context).roundToDevicePixels(FloatRect(0, 0, CGImageGetWidth(image), CGImageGetHeight(image))), image); *** src/third_party/WebKit/WebCore/platform/graphics/cg/PatternCG.cpp: global[45] CGContextDrawImage(context, rect, platformImage); *** src/third_party/WebKit/WebCore/platform/graphics/win/GraphicsContextCGWin.cpp: global[101] CGContextDrawImage(m_data-m_cgContext, dstRect, image); global[124] CGContextDrawImage(m_data-m_cgContext, CGRectMake(point.x(), point.y(), image-size().width(), image-size().height()), cgImage.get()); *** src/third_party/WebKit/WebCore/platform/win/DragImageCGWin.cpp: global[111] CGContextDrawImage(targetContext, rect, srcImage); global[156] CGContextDrawImage(drawContext, rect, srcImage); *** src/third_party/skia/src/ports/SkImageDecoder_CG.cpp: global[83] CGContextDrawImage(cg, CGRectMake(0, 0, width, height), image); *** src/webkit/glue/webcursor_mac.mm: global[172] CGContextDrawImage(context.get(), rect, image_ptr); *** src/skia/ext/bitmap_platform_device_mac.cc: DrawToContext[299] CGContextDrawImage(context, bounds, sub_image); DrawToContext[306] CGContextDrawImage(context, bounds, image); *** src/third_party/WebKit/WebKit/mac/Plugins/Hosted/NetscapePluginInstanceProxy.mm: print[372] CGContextDrawImage(context, CGRectMake(0, 0, width, height), image.get()); *** src/third_party/skia/experimental/CiCarbonSampleMain.c: TestDraw[208] CGContextDrawImage(cg, r, ref); *** src/third_party/skia/src/utils/mac/SkBitmap_Mac.cpp: drawToPort[133] CGContextDrawImage(cg, rect, image); *** src/third_party/skia/src/utils/mac/SkOSWindow_Mac.cpp: doPaint[168] CGContextDrawImage(cg, r, img); *** src/third_party/skia/xcode/hostapp/test.cpp: SkiaDraw[60] CGContextDrawImage(cg, r, gImage); --~--~-~--~~~---~--~~ 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: Landing two sided patches
Yes, we're working feverishly (is that a good word for this? :) to make this situation a bit less hard. However, in the meantime, the process could go like this: 1) Make sure the canary had a green run. This would really help the WebKit gardener to know which revision to roll up to. 2) Land your patch upstream. There's no need to close the tree -- the only thing you'll break is the canary bot. 3) Let the gardener to roll up to last green revision 4) In parallel, prepare a patch that rolls deps to your revision, including your fix. Since the gardener's roll is green, you shouldn't have any breakage. If you do, it's your fault :) --- this is basically the key to sanity. Don't land your one-revision roll if it breaks your local compile. 5) Let the gardener land their patch 6) Sync and land your patch right after the gardener lands. If you have more than one of these, rinse and repeat. I don't think it is a good idea to land multiple breakages and then sort them out downstream. The situation is much muddier when you are already dealing with multiple breakages upstream. That was the case early this week. In this case, the gardener: 1) finds the breaking rev by studying the canary and trac.webkit.org, 2) checks that the rev before indeed builds, and sort out whatever test regressions it may have locally 3) Lands the roll 4) Depending on the nature of the breakage, calls the expert. I am working on a list that will include various parts of our port, but for now you could just ping levin, darin, or me (in that order ;) 5) The expert will do a one-rev roll, fixing the breakage. Basically, the idea is to let the gardener roll while green, and make one-rev rolls/fixes for bustage. For gardeners: I can not emphasize enough that it is *much* easier to roll deps many times a day in small, green increments. Use the canary, it'll tell you the revs that are safe to roll. Otherwise, you'll be landing large swaths full of red and wonder at the fireworks in amazement. Don't wait for the end of the day. Another note: today, most of the layout test failures you'll see after a merge are either new tests or changes in expectations that just need rebaselining. The regressions should be rare and cause for alarm. Please look at the tests, failing on the canary. Rebaseline or file bugs if we're not passing for a good reason. Don't sweep them under the test_expectations rug. It is *much* harder to dig through the hundreds of lines of failures, trying to figure this out after the fact. Hope this helps. Sorry this is a bit too long, I am trying to get to actually putting this in a more stable format, and this time is as good as any. :DG On Thu, Jun 25, 2009 at 4:46 PM, Darin Fisherda...@chromium.org wrote: I suspect there are things we can do that will avoid much of the need to do a Chromium side change in unison with a WebKit side change. #1 is probably upstreaming some .gypi files so that the set of files to build can be stored in svn.webkit.org. The WebKit API will also help, and completing the upstreaming of V8 is another biggie. -Darin On Thu, Jun 25, 2009 at 3:53 PM, Adam Langley a...@chromium.org wrote: Dear Lords of the WebKit, I come to you seeking guidance about how best to avoid the mess that the tree got into this afternoon. Japhet and I both had two sided patches to land (where one needs to land both the WebKit and Chromium sides together). We emailed the merger for the day (jianli) and asked him to email us when the merge landed. He did so and I closed the tree. japhet and I both started landing upstream. I landed r45191 and the Chromium side (including a large DEPS roll) in r19287. japhet landed upstream in r45193 and r19291. The tree went red because V8IsolatedWorld had landed upstream in the mean time and needed an include file changed because of japhet's upstreaming. I TBRed upstream (r45201) and rolled DEPS (r19295). However, that pulled in several other upstream patches, one of which broke the build in another way! So I TBRed upstream to fix that (r45203) and rolled DEPS again (r19298). Thankfully, due to fleetness of keyboard, no other patches landed upstream in the mean time. In the past, for small patches, I've emailed the WebKit merger with the patch to land. However, for larger patches, esp those which might have conflicts, this seems unfortunate. It also breaks the SVN log/blame for the future. How best to deal with this now that we pull directly from upstream? Should I just have reverted Chromium at the first sign of trouble? 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: HTML5 Web Socket design doc
2009/6/26 John Abd-El-Malek j...@chromium.org
2009/6/25 Fumitoshi Ukai (鵜飼文敏) u...@chromium.org
Thanks for review.
2009/6/25 Michael Nordman micha...@google.com
Only skimmed thusfar as well... but from what i've seen, looks reasonable
to me.
* A version of the diagram you have in the chrome doc would be nice in
the webkit doc too.
Sure. I've added a diagram in webkit part.
* Does WebSocketHandle really need to be refcounted. I know
ResourceHandle is a refcounted object and this design looks modeled off of
that (which may be why you've spec'd it this way). Unless your design
actually needs refcounting on this class, you may be able to simplify things
without it. From the looks of it, WebSocketChannel 'owns' the
WebSocketHandle.
Yes. I missed to add public RefCountedWebSocketHandle as base class of
WebSocketHandle.
Thanks.
should we reuse WebCore/loader instead of adding new component?
The loader is somewhat notorious for its complexity. I think you've made
a good decision to keep this out of there and to design the websocket system
in a good clean modular fashion.
which component is responsible of web socket protocol framing? This
design assumes WebSocketChannel serializes/deserializes message in web
socket frame.
Since WebSocketHandle is inevitably going to be platform specific, any
code you want to be shared code shouldn't be slated for that class. To the
extent the 'web socket protocol framing' can be done indepedent of the
'platform' socket handle (which it looks like it can be), it would be a good
thing to put it in WebSocketChannel so its shared core common code goodness.
I see.
I've one question: Web socket handshaking is also platform independent.
Should we do the handshaking in WebSocketChannel and WebSocketHandle just
provides almost raw TCP socket?
Or Put handshaking in WebSocketHandle as resource loader puts HTTP in
platform code?
Regarding the WebKit API, note that no WebCore data types can be used
there. So you'll need to create wrapper classes.
The WebKit API classes still derive from WebCore, which isn't possible.
The WebKit API is an abstraction around WebCore classes, so it can't use
any WebCore types in it.
Ah, Ok. I updated WebKit API part not to use WebCore classes.
I see you have speced WebKit:: wrapper classes with the same name as the
corresponding WebCore:: classes.
I wonder if that same naming could be confusingt? The naming convention
darin has been employing would be WebKit::WebWebSocketHandle, which
certainly looks odd.
Ok. I follow the naming convention to be WebKit::WebWebSocketHandle.
hmm, I actually find WebWeb very unwieldy. I vote for
WebKit::WebSocketHandle.
Ok. will use WebKit:;WebSocketHandle.
Thanks!
ukai
* virtual void didReceiveData(const String msg) {}
Maybe rename this to channel client api to didReceiveMessage() to help
distinguish between raw 'data' being surface by the 'handle', and complete
'messages' being surfaced by the 'channel'.
Sure. Fixed.
Thanks!
ukai
On Wed, Jun 24, 2009 at 2:32 AM, Fumitoshi Ukai (鵜飼文敏)
u...@chromium.org wrote:
Hi,
yuzo, tyoshino and I start working to implement HTML5 Web Socket and
write design docs
WebKit part: http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh
Chromium part: http://docs.google.com/View?id=dfm7gfvg_1dm97qxgm
We'll send WebKit part to webkit-dev, if it looks ok.
We'd welcome if you could give us feedback on our design docs.
Thanks,
ukai
--~--~-~--~~~---~--~~
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: how to judge layouttests' running result?
http://dev.chromium.org/developers/testing/webkit-layout-tests says: ./run_webkit_tests.sh LayoutTests/path/to/your/test.html --full-results-html will produce a page including links to the expected result, actual result, and diff. Does that help? 2009/6/25 David Jones ds...@163.com: I have ran layouttests on Windows XP, and got a result as: Expected to fail, but passed (5): LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html LayoutTests/fast/encoding/invalid-UTF-8.html Expected to timeout, but passed (1): LayoutTests/http/tests/security/credentials-in-referer.html Regressions: Unexpected failures (8): LayoutTests/fast/css/css2-system-fonts.html = FAIL LayoutTests/fast/dom/anchor-toString.html = FAIL LayoutTests/fast/dom/java-applet-calls.html = FAIL LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht ml = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL LayoutTests/plugins/embed-attributes-setting.html = FAIL Regressions: Unexpected timeouts (1): LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = TI MEOUT -- = Tests to be fixed for the current release (786): 86 test cases (10.9%) Passed 364 test cases (46.3%) Skipped 289 test cases (36.8%) Text diff mismatch 191 test cases (24.3%) Simplified text diff mismatch 160 test cases (20.4%) Image mismatch 11 test cases (1.4%) Test timed out 6 test cases (0.8%) Test shell crashed 2 test cases (0.3%) No expected image found = Tests we want to pass for the current release (8984): 8271 test cases (92.1%) Passed 364 test cases (4.1%) Skipped 301 test cases (3.4%) Text diff mismatch 201 test cases (2.2%) Simplified text diff mismatch 164 test cases (1.8%) Image mismatch 12 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found = Tests to be fixed for a future release (0): = All tests (10884): 8753 test cases (80.4%) Passed 2130 test cases (19.6%) Skipped 411 test cases (3.8%) Text diff mismatch 302 test cases (2.8%) Simplified text diff mismatch 183 test cases (1.7%) Image mismatch 13 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found I don't know what it tells, am I passed the layouttests? There's also a layouttests in webkit, what's the relation between chrome's layouttest and webkit's layouttest? I think webkit's layouttest only run on Leopard. 200万种商品,最低价格,疯狂诱惑你 --~--~-~--~~~---~--~~ 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: how to judge layouttests' running result?
I usually try to execute the regressing tests manually (most of the time by just open the html file in test shell, sometimes you have to start some local web server). If they pass, I tell myself that the test is just flaky. If they still fail, I start debugging. 2009/6/25 David Jones ds...@163.com: I have ran layouttests on Windows XP, and got a result as: Expected to fail, but passed (5): LayoutTests/css2.1/t0805-c5519-brdr-r-01-e.html LayoutTests/css2.1/t0905-c5525-fltblck-00-d-ag.html LayoutTests/css2.1/t0905-c5525-flthw-00-c-g.html LayoutTests/css2.1/t0905-c5526-flthw-00-c-g.html LayoutTests/fast/encoding/invalid-UTF-8.html Expected to timeout, but passed (1): LayoutTests/http/tests/security/credentials-in-referer.html Regressions: Unexpected failures (8): LayoutTests/fast/css/css2-system-fonts.html = FAIL LayoutTests/fast/dom/anchor-toString.html = FAIL LayoutTests/fast/dom/java-applet-calls.html = FAIL LayoutTests/fast/dom/object-embed-plugin-scripting.html = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol-explicit-domain.ht ml = FAIL LayoutTests/http/tests/security/cross-frame-access-protocol.html = FAIL LayoutTests/platform/win/fast/text/uniscribe-missing-glyph.html = FAIL LayoutTests/plugins/embed-attributes-setting.html = FAIL Regressions: Unexpected timeouts (1): LayoutTests/http/tests/security/originHeader/origin-header-for-https.html = TI MEOUT -- = Tests to be fixed for the current release (786): 86 test cases (10.9%) Passed 364 test cases (46.3%) Skipped 289 test cases (36.8%) Text diff mismatch 191 test cases (24.3%) Simplified text diff mismatch 160 test cases (20.4%) Image mismatch 11 test cases (1.4%) Test timed out 6 test cases (0.8%) Test shell crashed 2 test cases (0.3%) No expected image found = Tests we want to pass for the current release (8984): 8271 test cases (92.1%) Passed 364 test cases (4.1%) Skipped 301 test cases (3.4%) Text diff mismatch 201 test cases (2.2%) Simplified text diff mismatch 164 test cases (1.8%) Image mismatch 12 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found = Tests to be fixed for a future release (0): = All tests (10884): 8753 test cases (80.4%) Passed 2130 test cases (19.6%) Skipped 411 test cases (3.8%) Text diff mismatch 302 test cases (2.8%) Simplified text diff mismatch 183 test cases (1.7%) Image mismatch 13 test cases (0.1%) Test timed out 6 test cases (0.1%) Test shell crashed 2 test cases (0.0%) No expected image found I don't know what it tells, am I passed the layouttests? There's also a layouttests in webkit, what's the relation between chrome's layouttest and webkit's layouttest? I think webkit's layouttest only run on Leopard. 200万种商品,最低价格,疯狂诱惑你 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New waterfall mode for sheriffs
Hello, The console view is not the best for sheriffs since it does not show in details the current state of the tree. The waterfall has always been better for that. But since our waterfall is really big, it can be hard to scroll all the time and keep track of all the failures. For that, I modified the current waterfall to have a mode to hide all the green slaves. Only the slaves with failures are shown. Link: http://build.chromium.org/buildbot/waterfall/waterfall?failures=1 This should help sheriffs to quickly see what builders they need to be monitoring, and remind them that some of them are red, even though they are usually completely hidden on the far right of the waterfall. A slave is present on this waterfall if : - The last finished build was red. - A step of the build in progress is red (This will eventually turn the build red) - The slave is offline. Let me know if you have any comments/suggestions about this. Thanks Nicolas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
