Re: [chromium-dev] [LTTF] Finders Pool Drained, Under 300 Failures on Win XP Release
This is awesome, and certainly not thankless. Linus On Fri, Jan 15, 2010 at 7:59 PM, Peter Kasting pkast...@google.com wrote: Dimitri, the LTTF, and anyone else involved, you are awesome, and I consider your work to have the largest importance / (satisfaction + recognition) value on the team. This is a thankless task. You have given me hope that someday we could conceivably reach 0 failures. PK -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -- 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: Why is Linux Chrome so fast?
scrolling jank in gmail http://crbug.com/25741 Linus On Wed, Oct 28, 2009 at 12:05 PM, Adam Barth aba...@chromium.org wrote: On Wed, Oct 28, 2009 at 8:05 AM, Evan Martin e...@chromium.org wrote: General comments: Linux tends to be lighter which means it does better on older hardware, so depending on what sorts of laptops you're talking about that could be a major factor. Windowses later than 2000 or so need surprising amounts of hardware to run well. (I don't mention Mac below because there hasn't been much performance work there yet.) I pulled out the laptops side-by-side to be more scientific about this. Here are the stats: XP: 2GB RAM, Core2 Duo, 2.00 GHz Ubuntu 9.10: 2GB RAM, Core 2 Duo, 2.40 GHz So, the Linux machine as 20% more CPU to work with. 1) Scroll performance is extremely good. Even on Gmail, I can only get the mouse to lead the scroll bar by a dozen pixels. On Slashdot, it doesn't even look like I can do that. On plain pages (one scrollbar on the right, no Flash) scrolling is literally shifting the pixels down. On Linux we do this by sending a command to the X server, which is a single process that even has the graphics drivers built in so it talks directly to your graphics card and can in theory do a hardware-accelerated copy. I would expect this to be pretty fast. Looking at this more carefully, scroll performance on Slashdot is great in both Windows and Linux. On Gmail (no chat mole), there's a noticeable difference. Here's a visualization of the numb on the scroll bar: || || || || || || -- -- Click here and pull down -- -- -- Linux: mouse latency gets to here || || -- Windows: mouse latency gets to here || || || || Admittedly, it's hard to see precisely, but it affects the feel. Scroll on Windows feels slightly heavier. 2) Tab creation is very fast. Maybe the zygote is helping here? Can we pre-render the NTP on other platforms? The zygote is paused right at process start, before we've even started a renderer. On the other hand Windows process creation is more expensive. There is a new tab graph that attempts to measure this. The various lines on the graph are tracking how quickly we get to each stage in constructing the page. We hit the first line 20ms faster on Linux than Windows likely due to the zygote and slow Windows process creation, but process startup seems to be a relatively small part of the total time. Linux hits other lines later and Linux and Windows hit the finish line at around the same time. So, I retried this with a fresh profile on both. The differences are not as dramatic as I remember. I can't actually see a difference when I run them side-by-side. 3) Startup time is faster than calculator. I'm not sure if you're kidding. Do you mean Windows calculator? I meant Linux calculator. In the limit, I'd expect us to pay a lot more on Linux due to using more libraries, GTK initialization, round trips to the X server, etc. but I don't know much about Windows here. I tried turning on the GTK theme. That killed startup performance. Side-by-side startup easily noticeably faster in Linux. To be more precise, drawing the first pixel is noticeably faster. Total startup time is harder to say. Interestingly startup drawing is different between Windows and Linux. We might want to film with a high-speed camera to see exactly what's going on, but here are my impressions: Linux draw order: 1) Fill entire window with blue (This looks bad, can we use a different color? White?). 2) Paint main UI widgets, including NTP. 3) Paint NTP thumbnails. I bet that (2) is actually broken in to two pieces, I just can't see it. Window draw order: 1) Paint NC region (the blue border around the edge). 2) Paint main UI widgets (without omnibox). 3) Blit NTP content area (the sweep from top to bottom is noticeable). 4) Paint omnibox. 5) Paint NTP thumbnails. Keep in mind that this all happens very fast, so I could be imagining things. Ideas for improving perceived windows startup time: 1) Draw a fake omnibox with the rest of the main UI widgets. Currently we draw the omnibox really late and it looks slow and bad. You can see this if you have a dark desktop wallpaper and you focus on where the omnibox will be. You'll see a dark rectangle inside the main toolbar which is the desktop showing through. We should never show a dark rectangle there. 2) Fill the main content area with white when drawing the main UI widgets. You can see this if you focus on the bottom of where the bookmark bar is going to be (especially when the bookmark bar is set to show only on the NTP). You'll see an edge there when the bookmark bar is draw by while the main content area is still transparent. There's no reason we should ever paint an edge there. I bet the reason Windows startup feels slower is whatever drawing operation we're using for the
[chromium-dev] Re: detecting tabs using a lot of CPU?
Yes, please! However, I would get that dialog about 1000 times a day: http://crbug.com/22948 Linus On Wed, Oct 7, 2009 at 9:59 AM, Paweł Hajdan Jr. phajdan...@chromium.orgwrote: Just a while before one of my tabs (GMail) started using a lot of CPU time (67% while I was compiling in the background). The browser and the system were responsive at all times, but processing power was wasted. We have a warning dialog for hanged renderers offering to kill them. What do you think about a warning dialog for renderers consistently using a lot of CPU? --~--~-~--~~~---~--~~ 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: [DESIGN DOC] registerProtocolHandler HTML5 API
I was agreeing with Ben, I thought. - in-page discovery ui - script can't initiate out-of-page ui - only user actions can bring up out-of-page ui Linus On Mon, Sep 28, 2009 at 5:44 PM, Nick Baum nickb...@chromium.org wrote: I think Ben meant that the javascript would have to come from a user-click (just like for popups), which I totally support. For what it's worth, I think it will be better for the page to provide in-context discovery of this (in Gmail settings, for example), rather than force the user to discover an out-of-page UI. I really don't see this happening very often, so I'm not particularly worried about it being annoying. -Nick On Sat, Sep 26, 2009 at 12:19 PM, Linus Upson li...@google.com wrote: Yes. Please do not add more ways for script to instigate out-of-page UI. It is all evil. Linus On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Yes. Please do not add more ways for script to instigate out-of-page UI. It is all evil. Linus On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Cross-compiling on ARM
Any chance gold will support linking Windows binaries? Linus On Tue, Aug 25, 2009 at 7:23 AM, Joel Stanley j...@jms.id.au wrote: On Tue, Aug 25, 2009 at 17:06, Lei Zhangthes...@chromium.org wrote: Only x86 and x86_64 were supported at the time gold was originally released. Does it support ARM yet? Yes, gold can link ARM binaries as of a few months ago. I have used it in my cross compiling. Ubuntu is shipping it it in Karmic (for ARM, as well as the x86 architectures) in the binutils-gold package. Joel --~--~-~--~~~---~--~~ 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: Chrome Core Product Principles
It would be nice to have something about memory consumption in the Speed section as well. Linus On Thu, Aug 13, 2009 at 12:04 PM, Darin Fisher da...@chromium.org wrote: Very nice! Some things I would add to the speed section: *How will my code perform when the operating system or hard disk is bogged down?* *Am I taking care to avoid blocking file system access on the UI and IO threads?* -Darin On Thu, Aug 13, 2009 at 11:14 AM, Ben Goodger (Google) b...@chromium.orgwrote: I've put together a brief document describing the core principles of the Chrome product and some of the ways we try and achieve them. http://dev.chromium.org/developers/core-principles Thanks to Ian Fette and John Grabowski for helping me fill this out. Feel free to edit if you have anything else to add. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Allocator Choice
Does all this work with Purify? Linus On Wed, Aug 12, 2009 at 9:09 AM, Mike Belshe mbel...@google.com wrote: On Tue, Aug 11, 2009 at 9:57 PM, Dean McNamee de...@chromium.org wrote: Do we have numbers on how the 4 allocates compare on those tests (page cycler, etc)? I do - I sent some of them around a few days ago. Summary: jemalloc and tcmalloc are pretty close; where jemalloc is a little more compact and tcmalloc is a smidge faster. Overall jemalloc looks pretty darned good. The source to tcmalloc is more hackable though. The windows heap varies by platform, as they did a lot of work on the Vista heap, including making LFH the default. But both jemalloc and tcmalloc considerably outperform the windows heaps both on size and perf. Mike On Tue, Aug 11, 2009 at 8:25 PM, Mike Belshembel...@google.com wrote: In an effort to make it easier to test debugging heaps and allocators, I just landed a changelist which makes our allocators switchable at runtime. Unlike Obama's plan for healthcare, this CL is about giving you more choice. From an environment variable, you can now switch between 4 different allocators. set CHROME_ALLOCATOR=tcmalloc // default - use TC Malloc set CHROME_ALLOCATOR=jemalloc // use JEMalloc, the allocator also used in firefox set CHROME_ALLOCATOR=winheap // use the built in windows heap set CHROME_ALLOCATOR=winlfh // use the low-fragmentation windows heap This change also contains a fix to tcmalloc to more aggressively return pages (in other words, actually return them sometimes). Without this fix, Chrome grows but doesn't shrink. As a result, this change *DOES* have a negative performance impact on chrome (we're now returning pages fairly aggressively) Good news: - Our memory test shows a 4% drop (not terribly significant) http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150graph=commit_charge Neutral news: - The Moz page cycler shows no change: http://build.chromium.org/buildbot/perf/vista-release-dual-core/moz/report.html?history=150 Bad news - The JS page cycler shows a 3% drop. http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150 I'm working on this. Let me know if you have problems or feedback. Also, if you do play around with the allocator choices, let me know your experience. 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: Quota UI for LocalStorage (and others in the future)
I'm coming to the opinion that we should leverage the install mechanism of the extension system for apps that need special permissions, increased quotas, expanded lifetimes, etc. The extension can be almost vacuous, and in our extension world exceptionally lightweight. It only needs to make the special capability available to the page. As Maciej brought up on the whatwg list, the extension system gives us multiple affirmative steps, vetting, reputation and revocation. It also gives us a UI access point. All of these are important for controlling apps that aren't safe and stateless. Linus On Wed, Jul 29, 2009 at 10:24 AM, Ian Fette i...@chromium.org wrote: I would say that if all the browsers are doing 5MB fixed quota for local storage, it is a good way to start. Sadly, I think we need to start thinking about this now for databases though (certainly I don't want to hit yes 4,000 times as my gmail syncs up to 20GB) 2009/7/29 Jeremy Orlow jor...@google.com On Wed, Jul 29, 2009 at 9:37 AM, Peter Kasting pkast...@chromium.orgwrote: On Wed, Jul 29, 2009 at 12:39 AM, Ben Laurie b...@google.com wrote: That seems overly simplistic to me - for example, just because I sometimes want to let a chat app have access to my camera, doesn't mean I want it always to have access. Given the number of users I've seen fix this problem with duct tape, I think I can conclude that users would use controls if they had controls they understood and trusted. I don't agree. I believe granularity is not only useless but harmful for the majority of users. See user studies of desktop app install flows or options dialogs that universally conclude that giving people more choices helps a small number of people and loses a large number. This is the philosophy we designed Chrome around, so we're strong backers of it. I agree on principle. I can imagine a couple ways the web app might state the capabilities it needs up front. The problem is that, with newer versions of the application, the needs might change. But how do we keep them from changing so often that the user just gets used to clicking 'yes' every time? I can't think of any good solution for this. Anyway, I think we've gotten a bit abstract here. It's good to talk about this in general, but in the mean time I'm not sure what to do for LocalStorage. Is the fixed quota per origin a good way to start? If so, is the plan to leave it that way until someone tries to tackle this stuff in a more unified way? J --~--~-~--~~~---~--~~ 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: Quota UI for LocalStorage (and others in the future)
Everything is a cache. We are free to toss out local storage, databases, appcaches, cookies, etc. any time we want. I think the best way is to have a good eviction algorithm for local storage. What eviction algorithm are we using for the main browser cache? Perhaps some version of that that accounts for recency, usage, size, etc.? Linus On Wed, Jul 29, 2009 at 11:31 AM, Ian Fette i...@chromium.org wrote: Add them to the malware blacklist :) 2009/7/29 Jeremy Orlow jor...@chromium.org On Wed, Jul 29, 2009 at 11:15 AM, Linus Upson li...@google.com wrote: I'm coming to the opinion that we should leverage the install mechanism of the extension system for apps that need special permissions, increased quotas, expanded lifetimes, etc. The extension can be almost vacuous, and in our extension world exceptionally lightweight. It only needs to make the special capability available to the page. As Maciej brought up on the whatwg list, the extension system gives us multiple affirmative steps, vetting, reputation and revocation. It also gives us a UI access point. All of these are important for controlling apps that aren't safe and stateless. I like this approach. So the only loose end is this: what should we do (if anything) about malicious apps using thousands of sub-domains (which are each their own origin, and thus get their own 5mb) to fill up your machine. As far as I know, no other browser deals with this and it hasn't ever been a problem (...yet), so I guess we can just ignore it for the time being? J --~--~-~--~~~---~--~~ 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: Quota UI for LocalStorage (and others in the future)
I agree on the need for a better UI to manage cached resources and selectively clear parts of the cache. The current web model of per-origin grouping isn't very satisfying because some apps span multiple origins and some origins host multiple apps. Given the extensive discussions around this for the past few years I'm not optimistic a better answer is forthcoming. In the end, perhaps it doesn't matter. If the browser is smart about managing its caches, the right thing should just happen without the user doing anything special. If I use offline gmail a bunch, and have for a long time, the browser should never throw away its appcache, databases, cookies, files, etc. If I went to some random site once which availed itself of an appcache and database on my machine the browser should throw those away first if I suffer space pressure. Linus On Wed, Jul 29, 2009 at 11:34 AM, Mike Beltzner beltz...@mozilla.comwrote: On 29-Jul-09, at 2:31 PM, Ian Fette wrote: Add them to the malware blacklist :) Yeah, I think this is right. Bad acting websites should be considered malware, and blocked for that reason. Linus: I agree that we can (and probably should) work on the webapps list to build some good specifications about how offline applications communicate expectations about permission and space requirements. We should also, though, make sure that as useragents we provide some sort of UI for cataloguing what offline apps are installed, how much space they're taking, and provide mechanisms for removing them. 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: Design Doc: out of process (v8) proxy resolving
Sorry. The point of my sandbox the browser suggestion wasn't to increase robustness in the case of failure. It was only to limit the damage an exploit might cause. The browser process is complicated enough that it is hard to secure. A small broker would be easier to understand and make resistant to attack. Linus On Wed, Jul 29, 2009 at 1:40 PM, Erik Kay erik...@chromium.org wrote: On Wed, Jul 29, 2009 at 9:44 AM, Linus Upson li...@google.com wrote: I realize this is not a small request, but it would be better if we could move to a model where the browser was sandboxed and talked to a much simpler process to carry out trusted operations on its behalf. While I like the general goal of what you're proposing, the downside of this approach is that if there's a crash, you lose the browser process. If we still wind up storing much of the state of the browser in this main process, then we lose a lot of state and potentially cause much of the browser to become unusable (I'm assuming that the whole browser wouldn't crash since the 'microkernel' would likely keep everything running). When one of these utility process crashes, we only lose that operation. Erik Linus On Wed, Jul 29, 2009 at 3:29 AM, Eric Roman ero...@chromium.org wrote: Here is a design document for http://crbug.com/11746 http://sites.google.com/a/chromium.org/dev/developers/design-documents/out-of-process-v8-pac Feedback welcome. --~--~-~--~~~---~--~~ 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: Mozilla design challenge
With a good heuristic, I think it will be very unlikely that we'll kill a renderer that has useful state. What are the chances that a tab on a site that I don't go to often, and that I opened 30 tabs ago has js/dom state that is critical for me? Mobile browsers already euthanize unused tabs aggressively. Since so few users have 20+ tabs open at once perhaps we can just reset their expectations for what happens if they accumulate a large number of tabs. Perhaps the heuristic could be tied to the mythical great overflow UI. For all of these heavy users I suspect they would prefer chrome to remain zippy fast with large tab sets rather than paging a renderer that 99.9% of the time doesn't have any interesting state. Linus On Tue, Jul 21, 2009 at 2:03 PM, Scott Hess sh...@chromium.org wrote: I don't think it's reasonable to require the user to specify which tabs to suspend, except, perhaps, if we develop a metric for power-hungry tabs and expose that. I think there is some potential for UI geared towards particular use-cases which could be overloaded to also allow more aggressive suspend. For instance, WRT my earlier posting, I would expect my pinned tabs to be given stronger priority, and my on-deck-to-read tabs to be treated more like preloaded/rendered bookmarks. There could be other UI advantages in there, like the on-deck tabs for a particular project could group under a single tab with other UI widgets to select which document within the group. -scott On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwarn...@google.com wrote: Is it possible to provide an intuitive UI that allows users to choose which tabs to be suspended? For example, just like users can click buttons on taskbar to pop up a particular window, we could provide a small window that pop-in tabs / windows. And then we can suspend all windows / tab that are popped into. Ryosuke On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay erik...@chromium.org wrote: You may be on to something, but I think it's more complex than this. For example bookmark systems don't work because people use them for a number of conflicting purposes (my list of things to read every day, a simple history system, a 'to read' list, a collection of links for research), which have different UI requirements. I think the same thing has happened with tabs (and there's a surprising amount of overlap). Here are the use cases I know I wind up using: - a few long running apps that need to keep running, potentially notifying me of new events (calendar, mail, chat, buildbot, etc.) - a few pages that I'm currently actively using (a screenshot from a bug I'm looking at, some reference documentation, a writely page I'm editing between compiles, etc.) - a to read list of pages that I started reading but didn't finish yet (sometimes this is a collection of related pages when researching something) - I'm sure there are others. In my use case, 80% of my tabs could easily be killed / suspended (or even hidden altogether) without any downside to me. The problem is that there isn't a way to automatically figure out which ones are which. Which ones have pending state that might be lost? (yes, some of this is bad app design, but there are many like this) Which ones do I expect to keep running all of the time because of notifications? What about that flash game that I left running in the background? Maybe we could come up with some heuristics that could detect some of this automatically, but I worry that there will be so many exceptions that it won't work. That means we'd need to come up with a better UI to express these concepts where the user chose to treat tabs differently in some explicit way. There are a number of extensions that try to do this for some specific use cases (to read lists, pinned tabs, etc.). I'm not sure that these are better than bandaids though. Erik On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee de...@chromium.org wrote: I feel like people are using tabs as a replacement for a good history system. At least in all current browser implementations, tabs are running. Even if we can make the UI scale to 1000 tabs, the 500 flash instances that are likely running aren't really going to perform. The making tab performance scale is a separate technical issue that will hopefully also improve. Looking at a lot of these design videos, they looked more like good ideas to me for history navigation than tab navigation. If history was good, I think people wouldn't be so worried about losing something by closing a tab. Having had bad history systems for so many years, people are now trained to keep tabs open if they ever might want to look at that page again in the future :\ On Sat, Jul 18, 2009 at 1:16 AM, Peter Kastingpkast...@google.com wrote: http://design-challenge.mozilla.com/summer09/ The results of the Reinventing Tabs in
[chromium-dev] Re: Memory usage in chrome
If I recall correctly, the best way we found to measure the total memory usage of a multi-process system like chrome was to measure the total commit charge of windows as you run the test. This will correctly account for shared memory, mapped pages that have been touched, kernel memory, etc. I don't recall if it includes virtual alloced paged that haven't been made real. The big limitation is that your test needs to be the only thing running on the machine. Linus On Thu, Jun 25, 2009 at 4:11 PM, Mike Beltzner beltz...@mozilla.com wrote: 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
[chromium-dev] Re: [linux] green flashes in page content
I think it would be great if I could turn on a pref in release builds that would show me jank. I'd also like to see all of the UI elements turn crazy colors if we fail to service the event queue in less than 200ms. Linus 2009/5/19 James Hawkins jhawk...@chromium.org On Tue, May 19, 2009 at 11:20 PM, William Chan (陈智昌) willc...@chromium.org wrote: On Tue, May 19, 2009 at 5:12 PM, James Hawkins jhawk...@chromium.org wrote: On Tue, May 19, 2009 at 5:07 PM, Evan Stade est...@chromium.org wrote: Are we sure we need this functionality? I understand the intention of seeing when we're not drawing fast enough, but I'm seeing the green background all the time (on a fast machine), which leads me to believe that the debugging aid is a red herring. Yea, you should see it all the time. We'll never be able to fix that. But how much of it you see is a good measure of jank. If enough people hate it, we can remove it (and only enable when we care to look at jank). We should leave page load/rendering time to measurements from the tests. This should be something that a developer working on jankiness could enable himself. It's rather distracting to the developers who don't need to look into jankiness, but do need to run debug builds regularly. I personally like seeing the green background, since I do like seeing how much jank there is. It doesn't bother me at all. That said, I can see how it'd annoy some people. If most people dislike it, then I think we should just make it the same as the release behavior (use a white background), but I think it'd be nice to have a command line flag or a preference or something so I can run with a green or whatever background to aid in debugging jankiness. Sure, I think a flag or pref would be ideal. --~--~-~--~~~---~--~~ 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 string16
An angel loses its wings for each 00 byte in UTF-16. Is 'host' measured in base-2 or base-10? Linus On Tue, Feb 3, 2009 at 6:11 PM, Evan Martin e...@chromium.org wrote: [A bunch of the team met up today to hammer out some decisions.] In brief: for strings that are known to be Unicode (that is, not random byte strings read from a file), we will migrate towards using string16. This means all places we use wstring should be split into the appropriate types: - byte strings should be string or vectors of chars - paths should be FilePath - urls should be GURL - UI strings, etc. should be string16. string16 uses UTF-16 underneath. It's equivalent to wstring on Windows, but wstring involves 4-byte characters on Linux/Mac. Some important factors were: - we don't have too many strings in this category (with the huge exception of WebKit), so memory usage isn't much of an issue - it's the native string type of Windows, Mac, and WebKit - we want it to be explicit (i.e. a compile error) when you accidentally use a byte string in a place where we should know the encoding (which std::string and UTF-8 doesn't allow) - we still use UTF-8 in some places (like the history full-text database) where space is more of a concern --~--~-~--~~~---~--~~ 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: What WebKit goodies do we get in 155?
Do you also want a list of chrome specific non-webkit goodies like the new network stack? Linus On Tue, Jan 6, 2009 at 1:44 AM, David Levin le...@google.com wrote: This fellow has done a good job of highlighting improvements to WebKit on an on going basis: http://hanblog.info/blog/category/WebKit Of course, not everything mentioned in there is in available just because we're at ToT. (Some things are behind ifdef's etc.) On Mon, Jan 5, 2009 at 11:06 PM, Adam Barth aba...@chromium.org wrote: If 155 is coming off of trunk, it has postMessage(), which is exciting for us security wonks. Adam On Mon, Jan 5, 2009 at 9:30 PM, Mark Larson (Google) m...@chromium.org wrote: I'm working on release notes for 155. The big addition in 155 (vs the 154 code we've been releasing) is the WebKit update. What have we gained since we started merging to WebKit's trunk? So far, I've got -- full page zoom -- autoscroll -- CSS gradients -- CSS canvas drawing -- (partly) CSS masks -- (partly?) CSS reflections Can you think of other features worth noting in release notes? Thanks, 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: What WebKit goodies do we get in 155?
Should we mention that chrome scores 100/100 on Acid 3 (but actually fails to render correctly)? Linus On Tue, Jan 6, 2009 at 12:37 PM, e. roman ero...@chromium.org wrote: On Tue, Jan 6, 2009 at 12:35 PM, e. roman ero...@chromium.org wrote: On Tue, Jan 6, 2009 at 12:26 PM, Evan Martin e...@chromium.org wrote: On Tue, Jan 6, 2009 at 12:17 PM, e. roman ero...@chromium.org wrote: While not new to WebKit, Chromium's port now implements more of the base features. For example, brettw recently added support for stroked/filled text, and transformed form controls. Example: http://webkit.org/blog/85/introducing-text-stroke/ Though it seems the second example on that page doesn't work (Red stroked text with a hollow interior and a black stroked shadow.) ... Yeah, there are some bugs (scrolling messes up the shadows too). Probably this: http://code.google.com/p/chromium/issues/detail?id=2982 Actually, meant to paste this bug number as it includes the repro. http://code.google.com/p/chromium/issues/detail?id=5925 http://codereview.chromium.org/8615 http://codereview.chromium.org/9008 On Tue, Jan 6, 2009 at 9:09 AM, Linus Upson li...@google.com wrote: Do you also want a list of chrome specific non-webkit goodies like the new network stack? Linus On Tue, Jan 6, 2009 at 1:44 AM, David Levin le...@google.com wrote: This fellow has done a good job of highlighting improvements to WebKit on an on going basis: http://hanblog.info/blog/category/WebKit Of course, not everything mentioned in there is in available just because we're at ToT. (Some things are behind ifdef's etc.) On Mon, Jan 5, 2009 at 11:06 PM, Adam Barth aba...@chromium.org wrote: If 155 is coming off of trunk, it has postMessage(), which is exciting for us security wonks. Adam On Mon, Jan 5, 2009 at 9:30 PM, Mark Larson (Google) m...@chromium.org wrote: I'm working on release notes for 155. The big addition in 155 (vs the 154 code we've been releasing) is the WebKit update. What have we gained since we started merging to WebKit's trunk? So far, I've got -- full page zoom -- autoscroll -- CSS gradients -- CSS canvas drawing -- (partly) CSS masks -- (partly?) CSS reflections Can you think of other features worth noting in release notes? Thanks, 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: Modal dialogs in Chrome
Perhaps the work Charlie is doing could help here. Linus On Tue, Dec 16, 2008 at 4:32 PM, Brian Ellis phoenix1...@gmail.com wrote: I may be repeating what Peter said to some extent, but unless I'm missing something (and I may well be), the browser's security model should prevent pages from referring to each other via JavaScript across domain boundaries... so if the page-modal dialog also locked all other tabs in the same tab group (which, as I understand it, is defined as those tabs which share a domain) by graying out the tab or otherwise indicating that it's unavailable, we could get 95% of the way there with 5% of the headaches. It would be awesome if we could perform some kind of analysis to determine that certain tabs are independent of the locked page and not gray out those, but that seems like a lot of work for not much extra benefit. The main thing here is that user should not have to respond to the alert before they're allowed to look at another page on a completely different domain; anything that gets us that is, in my opinion, worth the time spent to make it happen. Brian On Dec 16, 4:00 pm, Peter Kasting pkast...@chromium.org wrote: On Tue, Dec 16, 2008 at 3:56 PM, Darin Fisher da...@chromium.org wrote: I don't understand what tab-group-modal UI would be like. That is fair, I don't have a good idea either. I assumed something like dim the page and/or put the alert window (using a ConstrainedWindow) over each page in the group, but there are obvious downsides to that. I'd prefer to do something like auto-cancel alerts that originate from background tabs. Maybe use an alternate, non-modal UI to present the alert text in case that is interesting. That seems promising. The first thing I think of for alternate UI is some sort of taskbar notification toast or something, but there are probably other possibilities too. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to chromium-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: New InfoBar hookup
Anything you can do to make the animations smoother and less janky would also be appreciated. Linus On Wed, Nov 19, 2008 at 10:03 PM, Ben Goodger (Google) [EMAIL PROTECTED] wrote: In a continuation of the state/view separation work I have been doing with the Browser window, my attention has turned to some of the bits of UI hosted by the Browser frame, but owned (at present) by the WebContentsView. After some discussion with Brett, it's our conclusion that the bits of UI that WebContentsView owns but which end up being attached to the frame should probably just live in the frame. This way we make the WebContentsView simpler, as well as simplifying many of the interactions between the hosting frame and the WebContentsView. The relevant UI components are the InfoBars, the FindBar and the Download Shelf. As a result, what I am seeking to do is move Chrome browser specific UI components out of the WebContentsView and into BrowserView. The first component I am going to tackle are the InfoBars. My plan of attack is as follows: Create a new views::View subclass called InfoBarContainer or some such. This is the spiritual successor of InfoBarView. This is a View that will be owned by the BrowserView that will contain any InfoBars associated with the selected tab. Massage InfoBarItemView/InfoBarConfirmView/InfoBarMessageView etc to be less state-ful. Rather they will obtain their state by talking to a hierarchy of platform independent InfoBarDelegate interfaces which the modules that wish to add InfoBars will implement. Add some methods to WebContents for the purposes of adding and removing InfoBars. The parameter will be an InfoBarDelegate interface or derivative. Add notification types broadcasting the addition and removal of InfoBars for a given WebContents. The Source of the Notification is a WebContents*, the Details is the InfoBarDelegate*. The InfoBarContainer view observes these notifications to construct InfoBar views for the delegates as they're added and removed. The InfoBarContainer is created and owned by the BrowserView, and has a direct communication channel with it, so the addition and removal of InfoBars from it don't need to notify the BrowserView by means of Toledo, Copenhagen and Djibouti (aka TabContentsDelegate). The BrowserView, which observes TabStripModel changes, is able to reset the InfoBarContainer every time a tab change occurs so that its state is re-validated. I plan to build this new infrastructure alongside the existing one to make things simple, converting one InfoBar type at a time. -Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: sent from test shell on Linux!
Very nice. Linus On Tue, Nov 11, 2008 at 2:22 PM, Dan Kegel [EMAIL PROTECTED] wrote: On Tue, Nov 11, 2008 at 2:08 PM, Evan Martin [EMAIL PROTECTED] wrote: Dude, gmail works in the test shell on Linux! But not the enter key, last I checked -- I screwed up keyboard handling somewhere. :) True, and I don't think you can use ^V to work around it yet :-) Thanks for getting SSL to work! My pleasure. I just did a shootout between test shell and firefox on linux by pasting the SunSpider public URL in each. Happily, it ran to completion on both. It's cool seeing this thing come together! - Dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Fwd: [chromium-dev] Re: OS X IPC Design doc
If you want to argue using data, we'll use that. If you want to argue using opinions, we'll use mine. Linus On Fri, Nov 7, 2008 at 7:55 PM, Amanda Walker [EMAIL PROTECTED] wrote: They work fine, though using Apache as an example, a Linux box running Apache can generally handle a higher load than Mac OS X running on the same hardware (historically, this has been true for any BSD-based kernel, not just Mac OS X). That said, on modern hardware Apache is mostly limited by TCP throughput over Ethernet, not interprocess communication. 10.5 is indeed better in this regard than prior versions of Mac OS X, though the experience of other Mac client teams at Google show a similar performance differential, as do other comparisons. For a recent example, see http://www.cs.virginia.edu/~jom5x/papers/macos.pdf. While they didn't make a perfect apples to apples comparison, they did use comparable hardware and measured an almost 2:1 performance difference between Mac OS X and Linux when it came to latency using signals and pipes between processes. However, we can all go back and forth all day with based on prior experience, X is faster than Y vs. but it shouldn't be :-). We'll put together some performance tests that will let us do some testing of Mac OS X pipes signals, Linux pipes and signals, and Mach IPC on the same piece of hardware. Having some objective measurementa should help this discussion immensely. --Amanda On Fri, Nov 7, 2008 at 8:54 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: On Thu, Nov 6, 2008 at 2:05 PM, Amanda Walker [EMAIL PROTECTED] wrote: Linux and Darwin are only superficially similar, and the differences get larger the closer to the kernel we get. I realize I'm being repetitious here :-), but generally speaking, starting with the assumption that one technique will work on both, especially if it involves IPC, threading, or process creation, is a mistake. I'm very surprised that this is the case for Mac OS X 10.5. It is to Mac's advantage to make it easy to port Unix code to Mac OS X. If Apache can run well on Mac OS X, these common system calls should have a good implementation on Mac OS X. Wan-Teh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Design doc: Background Browser Task
First thoughts: 1. It would be good if this proposal converged in some way with HTML 5 workers 2. There needs to be a way to name and communicate with these tasks (perhaps HTML 5 worksers have such a thing?) 3. I also don't see a need for the start on browser launch option 4. I don't think we should make any process/thread guarantees in the API. That should be an implementation detail 5. Please get feedback from Aaron Boodman and Chris Prince who have done extensive work on ... uh... workers. Linus On Wed, Oct 29, 2008 at 2:03 PM, Nick Baum [EMAIL PROTECTED] wrote: Permissions: I agree with Brian that drag-n-drop is somewhat clumsy for granting permissions (see how well that works for bookmarklets...). I'm syncing up with Mike Smith on this tomorrow, and Glen and I will work on a better solution. Also, what happens next time I visit the app? Is it authorized to launch the background task, or do I have to re-authorize it? Lifetime: Do we need the start on browser launch option? What's the use case for this? Process model: Are there cases when a background task would need to communicate with the tab that created it? For example, opening an event in an existing calendar window. Overall, this seems like a well thought-out proposal! -Nick On Wed, Oct 29, 2008 at 1:11 PM, Dmitry Titov [EMAIL PROTECTED] wrote: Good idea about OK delay... That part of the proposal is indeed the most controversial. Some folks love it, some hate it. Modal dialog can provide UI for learn more..., ask for specific permissions, perhaps even capture credentials to use while running in the background. On the other side, Allow/Deny dialogs are sometimes bad because they basically shift blame to the user w/o transparency on what's going on. So we do expect opt-in mechanism will perhaps change - please voice any idea you like more. Dmitry On Tue, Oct 28, 2008 at 6:43 PM, Brian Rakowski [EMAIL PROTECTED] wrote: Drag and drop seems like a clumsy and unfamiliar mechanism for granting this capability. A modal dialog would be better. We can inject a delay on making the OK button active if we are worried about clever attacks that get users to click on an OK that appears underneath the cursor. -Brian On Tue, Oct 28, 2008 at 5:55 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, Here is a draft of a design doc for Background Browser Task: http://docs.google.com/View?docid=dd6rm2wb_3fmz8pnnp Your feedback is appreciated. Thanks, Jian --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
