Re: [chromium-dev] Interesting performance characteristics of http://a.qoid.us/google.html
On Tue, Jan 12, 2010 at 11:33 AM, Evan Martin wrote: > On Tue, Jan 12, 2010 at 10:17 AM, Brett Wilson wrote: >> I imagine the problems on Linux are the same as they were on Windows, >> where the underlying graphics layer wants to place glyphs aligned on >> pixel boundaries. This gives rounding problems and the letters jump >> around. I spent several weeks making the rotations and transparency on >> Windows text and form controls look good. > > Can you elaborate a bit on what you did? (I write this as maybe the > person who will need to fight with this at some point, but practically > I wonder if it'll eventually fall on you. :P) This is the code in SkiaFontWin.cpp. That's non-ideal, and it would be better to have Skia get the outlines itself and use the Skia path. I don't actually know where the rounding problems occur on Linux. Skia should be fine with it, but its probably in the way it interacts with FreeType (maybe a glyph cache that requires being pixel-aligned?) Brett -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Interesting performance characteristics of http://a.qoid.us/google.html
On Mon, Jan 11, 2010 at 9:04 PM, Chris Evans wrote: > Hi, > I found this interesting: http://a.qoid.us/google.html > Because it's clearly very non-JavaScript focused (just a CSS rotation) and > yet the browsers exhibit very different performance characteristics. > All on my underpowered Windows laptop, > Chrome 3 & 4: smooth. Very nice anti-aliased accurate rendering. > Safari 4: not quite as smooth; less fps but still not bad. Text / lines more > jagged and text "wobbles" during the rotation. > The other browsers do not support the CSS used / required for this demo. > There was a similar version, but using SVG animation to do something very > similar. (It's currently offline). Firefox and Opera were able to attempt > the rotation of this one but both performed much worse that Safari and > Chrome. > Anyone know why Chrome, and to a certain extent Safari, are so much better > on this non-JS test? Is the Skia library underpinning Chrome superior? > There's also a difference between Chrome Windows and Chrome Linux. Whilst > Chrome Linux performs smoothly, the text is clearly jiggling around and even > getting more / less bold throughout the rotation cycle. Doesn't do that on > Windows. Any ideas? I imagine the problems on Linux are the same as they were on Windows, where the underlying graphics layer wants to place glyphs aligned on pixel boundaries. This gives rounding problems and the letters jump around. I spent several weeks making the rotations and transparency on Windows text and form controls look good. Brett -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] How can I tell if a Renderer process finishes loading a page
On Mon, Jan 11, 2010 at 12:59 AM, hap 497 wrote: > Thank you. > > But when I load www.cnn.com, I see something strange: > First the throbber is spinning, and then the cnn fave icon is shown > and then the throbber is spinning again, and then fave icon is shown. > And then the fave icon stays. > > Can you please help me understand under what situation will cause this > to happen? I don't think it is caused by frame set. This is because I > tried http://java.sun.com/j2se/1.5.0/docs/api/index.html, the throbber > stops after each frame in frame set is loaded. I don't think anybody is able to answer this type of question off the top of their head. RenderView::didStartLoading / didStopLoading correspond to the throbber starting and stopping in the renderer, I'd trace back form there. Brett -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Splitting off some pieces of chrome.gyp...
On Mon, Dec 7, 2009 at 1:43 PM, Bradley Nelson wrote: > Hello All, > Last week I re-landed a change to split off parts of chrome.gyp into .gypi's > in the same directory. > I had done something similar a couple weeks back, but took it out because > concern was raised about merge conflicts in m4. > I put it back in because I got the all clear on m4. > The goal is to reduce contention on chrome.gyp which has gotten quite large > - 7000+ lines. I just tried to add a file to chrome.gyp and I couldn't find where it should go. It took me a minute to remember this thread. I'm concerned our build system is getting out of control. I can not explain in simple sentences where anything should go. Even if I'm using my visual tool and find the right project, the only real way to find where a file should go is to grep for files nearby. .gyp files already had this property where you can't find where things should go in them and you needed to search. Now it seems like we've added an additional layer of "you don't know which file its in, either." How much does this solve contention? It seems like actual conflicts for changes will be the same as before. What contention cases are there that splitting everything out helps a lot? Thanks Brett PS Thanks for working on the build system, I don't mean to be non-appreciative. -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Thoughts on "// NOLINT"?
On Wed, Dec 9, 2009 at 4:24 PM, John Abd-El-Malek wrote: > btw I searched the code, almost all the instances are in code from different > repositories, like v8, gtest, gmock. I counted only 17 instances in > Chrome's code. Most of the Chrome NOLINTs look like the're around ifdefs, where the ifdef code sometimes mean that a comma or a semicolon goes on the line after the ifdef. We should be working to remove these anyway since the ifdefs are super ugly, and I'm not sure the NOLINT comment actually makes them worse. Some of these may not be practical or desirable to remove, though. So I don't think I see a big problem with the way NOLINT is used in Chrome. Looking through V8 I don't see a huge problem either. Some NOLINT calls weren't clear to me why the linter complained. I suggest that NOLINT comments be documented. In some places they already are. Then reviewers will know to argue when they see something untoward, whereas just "// NOLINT" isn't alwasy clear about what the problem is and whether they should complain. This will also make NOLINTs more painful to add since you have to justify why you're adding it, which will hopefully decrease its usage. Brett -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] Re: Changes to using threads in the browser process
On Tue, Nov 3, 2009 at 6:01 AM, Mike Pinkerton wrote: > > Can you put this information, as well as some examples for proper > usage, on dev.chromium.org. I doubt this stuff is very well documented > from the perspective of someone trying to use it, and this looks like > a great start!!! The place to put it is here: http://dev.chromium.org/developers/design-documents/threading Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab Thumbnails and Aero Peek (of Windows 7)
2009/10/23 Hironori Bono (坊野 博典) : > Hi Brett, > > Thank you so much for noticing this. I'm integrating the > ThumbnailGenertor class into my prototype now. :) > By the way, I'm a little wondering if there is a function that changes > the width and the height of a thumbnail image generated by the > ThumbnailGenerator class at run time. If not, I would like to hear > there is a plan to add it. > When Windows 7 shows tab thumbnails, it automatically calculates the > width and the height of a thumbnail image so that it can show all > thumbnails in one line. (When we open too many tabs and Windows 7 > cannot show their thumbnails, it shows a list of tab titles.) In > brief, we cannot assume the width or the height of a thumbnail as > constant values on Windows 7. > So, it may be better for the ThumbnailGenerator class to have an > interface that changes the width and the height of its thumbnails. (I > has added code that resizes the thumbnails retrieved from the > ThumbnailGenerator object and sends the resized thumbnails to Windows > 7. So, I don't mind it at all.) There isn't a way to do this. The reason is that the thumbnail generator precalculates thumbnails in advance for many pages (for example, when we're discarding the backing store). This means we have to know basically when we start Chrome what the max thumbnail size will be. It uses power-of-two downsampling to be as fast as possible, so the actual thumbnails aren't guaranteed to be any particular size. I would just use the default size for now. If it doesn't look OK, we can add a future enhancement to request the size, so the ones it generates on-demand (the ones where there is a backing store) can have a larger size if needed. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Spellchecker and memory-mapped dicts
On Thu, Oct 22, 2009 at 2:30 PM, Evan Martin wrote: > On Thu, Oct 22, 2009 at 2:22 PM, Brett Wilson wrote: >> This doesn't help on Mac where we want to use the system spellchecker. > > FYI, we got a patch to use the system spellchecker on Linux as well. > http://code.google.com/p/chromium/issues/detail?id=24517 > I should probably ping the original uploader again... > > This Ubuntu document describes some use cases as to why unification is good: > https://wiki.ubuntu.com/ConsolidateSpellingLibs It doesn't cover the negatives: A unified interface is fine except that if it calls through to the same library we used to have. The slowness and memory wastefullness of the Hunspell storage is why we wrote our own. We should be careful not to hurt the user experience. If you don't recall, initializing hunspell could easily take a few seconds when you type your first word in a text field (this will always block the renderer you're typing into). It takes 5-10 MB more memory than ours for the same data. I would not want to get this crappyness back. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Spellchecker and memory-mapped dicts
On Thu, Oct 22, 2009 at 1:39 PM, Evan Stade wrote: > > Hi all, > > At its last meeting the jank task force discussed improving > responsiveness of the spellchecker but we didn't come to a solid > conclusion so I thought I'd bring it up here to see if anyone else has > opinions. The main concern is that we don't block the IO thread on > file access. To this end, I recently moved initialization of the > spellchecker from the IO thread to the file thread. However, instead > of reading in the spellchecker dictionary in one solid chunk, we > memory-map it. Then later we check individual words on the IO thread, > which will be slow since the dictionary starts off effectively > completely paged out. The proposal is that we read in the dictionary > at spellchecker intialization instead of memory mapping it. > > Memory mapping pros: > - possibly uses less overall memory, depending on the structure of the > dictionary and the usage pattern of the user. > - loading the dictionary doesn't block for a long > time this one no longer occurs either way due to my recent > refactoring > > Reading it all at once pros: > - costly disk accesses are kept to the file thread (excepting future > memory paging) > - overall disk access time is probably lower (since we can read in the > dict in one chunk) > > For reference, the English dictionary is about 500K, and most > dictionaries are under 2 megs, some (such as Hungarian) are much > higher, but no dictionary is over 10 megs. > > Opinions? I've thought about this some (I wrote the memory map thing there now). History of the spellchecker: v1 : Per-process Hunspell storage (lots of memory duplicated in each renderer, expensive to load). v2 : Browser-process Hunspell storage (lots of memory, expensive to load, only occurs once) v3 : Browser-process memmap (less memory, cheap to load, only occurs once). I would like to consider moving hunspell back to the renderer so we can avoid sync IPCs and blocking the I/O thread on spellchecking. Spellchecking isn't fast (especially suggestions) even when everything is in memory, so it always sucks to have it block the I/O thread. Now that it can be memmapped, each renderer can memmap its own image of the data. This doesn't help on Mac where we want to use the system spellchecker. There would also be some amount of duplication since there are certain tables that are initialized once at the beginning (I don't think its that big, though). I would suggest first making the current histograms in the spellchecker.cc file UMA (currently they're debug-only local ones) so we can see how much blocking we're getting from Hunspell in the field. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Tab Thumbnails and Aero Peek (of Windows 7)
Hi Hironori, Thanks for researching this topic. On generating thumbnails, I wrote chrome/browser/tab_contents/thumbnail_generator which tries to get the most up-to-date thumbnail images for all tabs (except ones that haven't ever been shown) with minimal performance overhead. The code hasn't been used much in practice yet, but seems to basically work. It was written for a tab switcher, and the intent is that it will provide thumbnails for all services in the future (including the new tab page and the Windows 7 features) for all platforms. So I would definitely use that, and we should work on fixing any bugs or limitations that pop up. It's defaulted to off for most builds because it has a runtime overhead and its not currently used. If you want to turn it on for your build, it's started in the constructor for TabContents. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Running applications in chrome with javascript
On Mon, Oct 19, 2009 at 1:19 AM, David wrote: > > Someone knows where is a good guide for make an npapi plugin? and how > to call function to execute process... Your best bet is probably starting with the layout test plugin: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/npapi_layout_test_plugin/ You'll need to know C++ to write NPAPI no matter what. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Brent's Windows port of WebKit moving to Skia
On Mon, Oct 19, 2009 at 7:27 AM, Evan Martin wrote: > On Sun, Oct 18, 2009 at 11:58 PM, Adam Barth wrote: >> It looks like Brent Fulgham is strongly considering moving his Windows >> WebKit port to Skia: >> >> http://whtconstruct.blogspot.com/2009/10/exploring-skia.html >> >> Is there some way we could help him out by making the code in src/skia >> more easily re-usable by other projects? > > It would be nice. I think Skia has, more or less, a single developer: > http://code.google.com/p/skia/updates/list > So it might be up to Brent to make it happen, unfortunately. We had some discussions with Mike Reed (the Skia guy) a few weeks ago. We all agreed that this stuff should move to Skia somewhere, or at least a bunch of it, because it has been very useful to other developers. But I don't think anybody's working on it right now. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] String handling in base moved around, and where you should put your shared code
I finished moving the last bit of string stuff in preparation for separating ICU from base. All ICU and related utilities have moved to src/base/i18n. The rest of base should not depend on base/i18n because it will be a separate library, but base/i18n can depend on the rest of base. The core UTF8/UTF16/Wide conversion functions have been added to a new file: base/utf_string_conversions.h. This file doesn't use ICU, but rather a few ICU functions and macros I pulled out into base/third_party/icu. Currently, base/string_util.h includes base/utf_string_conversions.h and is likely to stay this way since nobody wants to change all of the files in the project. But if you write a new file or are updating the includes for an existing one, think about whether you need all of string_util or just the UTF conversion functions. The UTF conversion functions will almost never change, so you won't have to recompile your file when Bill S. Preston, Esq. adds SeparateStringIntoBitsAndInterpretEveryThirdPartAsAnInt64() to string_util. base/sys_string_conversions no longer includes SysUTF8ToWide and friends since there's no longer any point for those. sys_string_conversions contains only functions for converting to the system's native multibyte encoding (which you'll almost never need). The more advanced conversion functions that use ICU are in base/i18n/icu_string_conversions.h. You will have to include this file explicitly if you need them. This is WideToCodepage and friends for general character set conversion. It's rare to need this since you should be using Unicode. The final part I haven't done is make a separate base_i18n project that clients wanting ICU and related stuff will link to. This will replace base_gfx which has no purpose since I moved all the Skia and libpng/jpeg dependencies to app. This will allow clients to decide if they really need internationalization support. = I'm adding something, where does it go? First, please consider putting it inside your component's directory. When everybody adds all their crap to base, it ends up that nobody can find anything and the build is more interdependent. If you're not actually sharing anything between toplevel projects, it shouldn't be in base. Second, consider putting it in src/app. App is "the stuff you need to build a Windowed application," whereas src/base is "the stuff you need to build *any* application." Think of some random daemon or library on ChromeOS. It should link to base but not app. Is your stuff useful to every client executable, or just "applications" dealing with the windowing system, clipboard, drag & drop, etc.? Note also that WebKit/glue and test_shell can now depend on app, which makes it easy to not put stuff in base now. It's assumed anything in app can depend on ICU (base/i18n) since real applications will be internationalized. Put it in base if it really should be linked in with every Google client application, the crash reporter app, all ChromeOS daemons and login manager, etc. This shouldn't be that much stuff! If it needs ICU, put it in base/i18n. If it doesn't, put it in base or the appropriate subdirectory. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Local State / Preferences distinction
On Wed, Oct 7, 2009 at 1:26 PM, Tony Chang wrote: > The quasi-defunct profile system that uses the enable-udd-profiles > still has a separate Local State file and safe browsing databases > because it used different user data directory (udd). > > This change seems orthogonal to the profile system as it is currently > implemented. We can resplit the Preferences file in the future if > needed (and once the actual split is clear or needed). I couldn't figure out how it works, but it looks like the UDD profile switching is broken on WIndows (the submenu doesn't even pop anything up for me) and the code I was thinking of in the ProfileManager seems to never be used. This mess makes me very sad. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Local State / Preferences distinction
On Wed, Oct 7, 2009 at 12:52 PM, Tony Chang wrote: > Actually, the original distinction was stuff that could be shared > across computers and stuff that couldn't be shared (i.e., local > state). I think originally this was for the difference between stuff > that a mounted home directory would sync and stuff that wouldn't sync. > > In practice, I think it's used for both, which is all the more reason > to merge them. This comes up with the quasi-defunct profile system. Local State is supposed to be cross-profile, while the stuff in "Default" is your profile data. The safe browsing data in Local State should always stay with the safe browsing files, which currently stay in user-data-dir. I suspect the metrics stuff should also be cross profile. Do we need this profile support? The interface has been hidden behind a command line flag "enable-udd-profiles". Is it time to rip all of this profile stuff out? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Unimplemented GraphicsContextSkia functions
On Wed, Sep 30, 2009 at 12:18 AM, Andrew Scherkus wrote: > I'm doing some UI refactoring to use GraphicsContext but noticed > drawPath() is unimplemented (causes linker error). > What's a good practice to implementing something no one has ever used > before? Do we strive to be pixel perfect to GraphicsContextCG's > implementation? I don't want to cause developer grief 6 months from now > when someone uses a broken drawPath() implementation :) Doesn't that mean it's also uncalled? Implementing an uncalled function seems like a bad idea. It would be interesting to see if or how this is called in Safari. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 4:37 PM, Jeremy Orlow wrote: > On Tue, Sep 29, 2009 at 4:20 PM, Brett Wilson wrote: >> >> On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow wrote: >> > I'm guessing different people/companies will have different needs for a >> > kiosk mode. >> > Maybe all of these should be separate flags rather than one "kiosk" >> > flag? >> > We could then offer recommendations in a "Chromium for kiosks" Wiki >> > page? >> >> I think the reasoning for allowing this feature is that some minority >> would find it helpful and it wouldn't hurt much. I'm concerned that it >> is getting much too complicated. I think we shouldn't do it if it is >> going to be this complicated. > > Would multiple command line flags rather than one really complicate the > design? Mohamed's original patch was just a bunch of if statements keying > off of one flag. Seems like the same amount of work to have each if > statement key off of a different one. Or am I missing something? The original patch was billed as "let's make full screen a command line switch" which people were generally OK with. This proposal touches a dozen subsystems for an unofficially supported feature, whether it's with different command line switches or not. If it's this complicated, it needs to be designed cleanly, tested, and with official support. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
On Tue, Sep 29, 2009 at 4:15 PM, Jeremy Orlow wrote: > I'm guessing different people/companies will have different needs for a > kiosk mode. > Maybe all of these should be separate flags rather than one "kiosk" flag? > We could then offer recommendations in a "Chromium for kiosks" Wiki page? I think the reasoning for allowing this feature is that some minority would find it helpful and it wouldn't hurt much. I'm concerned that it is getting much too complicated. I think we shouldn't do it if it is going to be this complicated. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Kiosk Mode for Chrome
On Thu, Sep 24, 2009 at 10:32 PM, Adam Barth wrote: > > On Thu, Sep 24, 2009 at 10:07 PM, Darin Fisher wrote: >> Maybe I'm in the minority, but it doesn't sound that unreasonable to support >> command line options for disabling the status bubble and starting in full >> screen mode. We could lump these together into a --kiosk-mode command line >> flag. This seems like something that could be done in a fairly lightweight >> manner. >> >> Maybe others object? Darin is right that this is easy to do and support. > We could also turn off other features that don't make sense for > kiosks, like downloading files. But doing this stuff you added is when the support costs start getting nontrivial and why these features are often a risky road to travel. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: "Clear Strict-Transport-Security state" checkbox added
On Thu, Sep 17, 2009 at 3:50 PM, Evan Martin wrote: > > On Thu, Sep 17, 2009 at 3:38 PM, Adam Langley wrote: >> >> On Thu, Sep 17, 2009 at 3:37 PM, Ben Goodger (Google) >> wrote: >>> Whoever added this UI, please remove it before I have to when I get >>> back next week. >> >> Very well, reverting. > > Why not #ifdef around it? I fear if you revert you'll never check it in > again. If that happens, it's the best possible argument that this is a silly thing to add. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: "Clear Strict-Transport-Security state" checkbox added
On Thu, Sep 17, 2009 at 3:31 PM, Adam Langley wrote: > > On Thu, Sep 17, 2009 at 3:03 PM, Peter Kasting wrote: >> It's disappointing to me that this change was made without any bug in the >> bug database linked, and without any input from a member of the UI team, >> despite the code reviewer (abarth) explicitly wondering about getting UI >> review. > > Glen recently moved this dialog so that's it's now four clicks away > from the main UI. That certainly starts to put it in the realm of > trival UI changes. Also, the dialog is already concerned with things > that our users don't know about (like 'cookies') and it has sensible > default if you don't know what it means. > > I'm more bothered that people who care about their privacy have the > ability to control the information we store about them. Advanced users (including me) know what everything means in that dialog except the checkbox, and it's very scary and obscure sounding. I agree with Peter that it should not have gone in. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Need help on how to send data from RenderView to a custom DOMUI instantly
On Tue, Sep 15, 2009 at 7:31 PM, Mohamed Mansour wrote: > Hi all, > I am having trouble trying to figure out how I could replace the contents of > a specific WebFrame while I am in RenderView with a custom DOMUI page that I > have created. > Here is a scenario: > > User visits http://www.google.com > User waits till page is done loading > User selects Options > Print Preview > The current page will be replaced with a custom PrintPreview DOMUI page > (print:http://www.google.com) where I would be passing some Data such as a > vector of bytes (image) from RenderView to PrintPreviewDOMUI > > I have created the DOMUI page and made sure it works, and created the bitmap > and encoded it with JPEGEncoder, but I am clueless on how the connection > would be from RenderView to DOMUI. > Any assistance is appreciated. The reason why I want to replace the current > contents is because print preview depends on what is exactly visible at that > time. Unless there is a better way. > Thanks in advance! Is the code you're writing in C++ or JS? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Layout tests can now be run on both XP and Vista
On Tue, Sep 15, 2009 at 4:26 AM, Dirk Pranke wrote: > > Hi all, > > I have just landed a patch that enables us to run layout tests on > Vista as well as XP. > > In theory, you should continue to use the tools just as you have in > the past, and everything will work transparently. In practice, I may > have screwed up something, so if you notice problems please let me > know. > > One important change is that we now have a few XP-specific baselines > in webkit/data/layout_tests/platform/chromium-win-xp (mostly in the > way we handle various international characters and font differences > between XP and Vista). We do not have any Vista-specific baselines > (although one could argue that if there is a baseline in chromium-win > and a baseline in chromium-win-xp then the chromium-win one is > Vista-specific). We will be following the WebKit convention that the > generic platform directory represents the "most recent" version of the > platform (meaning that until Win 7 is released, all Vista baselines go > in chromium-win. When Win 7 is released, Vista-specific baselines will > go in chromium-win-vista). > > In practice, this means you might need to be careful about where your > new baselines end up when using the rebaselining tool. You should make > sure they end up in chromium-win unless you are sure they are > XP-specific (in which case you will be responsible for landing > baselines for both XP and Vista). > > If you have any questions about this, or run into problems, please let > me know ASAP. > > One last thing for those who might look at this stuff in detail - > test_shell has been changed to use a "generic" theme for rendering > form controls, scroll bars, and other native widgets, in order to not > have any differences from the different themes on the different > versions of Windows. If you are wondering why the scroll bars and > other controls in the baselines look really odd, that's why. Also, the > checkin involved updating > 700 images, so I didn't have anyone but me > review them. Let me know if you see anything that doesn't look right > :) > > Also, we will probably be landing Win 7 baselines Real Soon Now, since > adding them is a very small additional amount of work on top of the > stuff I just landed. Hm, now I have no excuse for not running the layout tests :( Thanks for working on this, though! Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Please stop hardcoding URLs everywhere
Did you know that most common URLs like "about:blank" and schemes like
"javascript" are in a nice file of constants for you to use, so you
don't have to duplicate the same data over and over? I didn't think
so.
I noticed a few places where we'd accumulated a few more hardcoded
URLs since I last looked, and did a patch a week ago. I went to upload
it today and there was a conflict. Somebody had added a *new*
GURL("about:blank") near my change since I had initially wrote my
patch!
The file is chrome/common/url_constants.h. Examples of use:
GURL(chrome::kAboutBlankURL).
url.SchemeIs(chrome::kJavascriptScheme);
Now you know.
In a related note, I noticed that the platform specific files for the
task manager view *each* have this at the top of them:
const wchar_t* const kAcknowledgements = L"about:credits";
const wchar_t* const kTOS = L"about:terms";
It makes me sad that both times the people who ported this file
thought that the best thing would be to copy and paste the Windows
code rather than share them in some clean way.
I've added the constants to our nice file of URL constants. If you're
adding or reviewing things, please be on the lookout for hardcoded
URLs. It makes it easier to maintain and look up when the ones with
special meaning are all in the same place, and we don't have to rely
on the linker to remove all the duplicated data (especially for dozens
of "about:blank" and "about" scheme checks).
Brett
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: linux startup regression
On Thu, Sep 3, 2009 at 9:26 AM, Evan Martin wrote: > Ok, I'll mark that I own this here and unassign it if I can't figure it out: > http://code.google.com/p/chromium/issues/detail?id=20991 > > On Thu, Sep 3, 2009 at 2:41 AM, Dean McNamee wrote: >> Ug, I can't reproduce this on my desktop. If I had to take a guess, I >> would guess Brett's gfx::Font change. It could be my font change. It does measure some extra text on startup. But I would have thought this was nothing compared to the text we already measure. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Layout try slaves
On Mon, Aug 31, 2009 at 10:13 AM, Marc-Antoine Ruel wrote: > > If you are not a committer, you can skip this message. > > If you want to run layout tests as a try job, you can use the layout > try slaves. They are not in the default pool so you need to reference > them manually. > > The format is: > gcl try foo --bot layout_win,layout_mac,layout_linux This is great. Is this documented anywhere? Seems like http://dev.chromium.org/developers/how-tos/webkit-merge-1 would be a very useful place to have it. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 9:17 AM, Brett Wilson wrote: > On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote: >> >> I spent a chunk of last week looking at the new tab page performance >> on startup on the Mac. I found that the renderer was waiting on data >> from the browser process for what seemed like far too long. The key >> to this problem is that resource requests for the new tab page are >> funneled through the browser process' main (UI) thread. At least on >> the Mac, when a new tab is being created or while the application is >> starting up, there's a lot of contention for the UI thread: the window >> is being drawn and there might be animations or other effects, not to >> mention that infernal throbber. >> >> The good news is that turning off the tab strip's Core Animation layer >> improves this, as well as many other things. A patch to do this just >> landed again at r24881 (on the third try). In my experiments, this >> reduced the time from when the renderer requests the new tab page to >> the time that all of the resources are present in the renderer from >> between 1-3 seconds to just a hair over 300ms. This is a huge >> improvement. >> >> I still think that 300ms is too long, though, especially when you >> consider that this is not the time from launch, but the time from the >> renderer's request, which itself can come as much as 300ms after >> launch. >> >> I'm experimenting with a change that lets the new tab HTML and CSS be >> served directly from the browser's IO thread instead of the UI thread. >> Since these tasks require profile and theme access, the approach is >> to build up the HTML and CSS early, on the UI thread where such access >> is permitted, and cache them. When a request for the HTML or CSS >> comes in, the browser can then service them entirely on the IO thread. >> This gets the data into the renderer almost immediately after it's >> requested, so that the renderer is able to fully lay out the new tab >> page without having to wait for the browser to do things like draw the >> new tab. Additional resource requests, such as thumbnails and >> favicons, are still being served from the UI thread. Based on my >> experiments, this shouldn't be a problem: the renderer isn't ready to >> receive these until it's done with layout based on the HTML and CSS, >> and once it reaches that point, the browser should be done with heavy >> UI tasks and there shouldn't be much contention for its main loop. It >> might ultimately be better to be able to serve all new tab requests >> from a non-UI thread in the browser, but that could mean additional >> caching. >> >> This change improves new tab page performance by about 65ms on my >> laptop in release mode. Now we're down to 240. Great. What else can >> we do? >> >> Well, that annoying throbber is still chewing up time, causing some >> amount of UI loop contention while the images, thumbnails, and icons >> are fetched. Windows and Linux don't have a throbber for the new tab >> page. We shouldn't either. Excellent, now we're down to 200ms. It's >> still high, but it's reasonable. It's a perceptible improvement from >> the 300ms we started with. >> >> What else can we do? One thing that's begging for improvement based >> on my timings is the renderer startup delay. We don't bother starting >> up a renderer until about 200ms after launch, and it takes the >> renderer 70ms from that point to reach its main loop. I bet that if >> we did renderer startup much earlier, we'd have one warm and ready to >> go by the time we needed it. This doesn't have to be >> startup-specific, we could always maintain a spare renderer in the >> pool (within reason) so that we're not caught twiddling our thumbs >> waiting for the one we just launched. > > Interesting. > > One of these days, I need to finish my intern's summer project (he had > to leave early). It was a rewrite of thumbnail storage so we only > store the thumbnails for the new tab page, rather than in the history > system for each day. > > One thing I've thought of lately is to store the actual new tab items > in this same database. This way, we don't have to wait for history to > load (>10MB) and we don't have to do a complex query over that history > data to get the new tab page data. By "items" I mean the URLs, titles, and ordering of the stuff on the new tab page, not just thumbnails. > Your post makes me wonder
[chromium-dev] Re: Long (exciting?) writeup on improving Mac New Tab Performance (not entirely Mac-specific)
On Mon, Aug 31, 2009 at 8:56 AM, Mark Mentovai wrote: > > I spent a chunk of last week looking at the new tab page performance > on startup on the Mac. I found that the renderer was waiting on data > from the browser process for what seemed like far too long. The key > to this problem is that resource requests for the new tab page are > funneled through the browser process' main (UI) thread. At least on > the Mac, when a new tab is being created or while the application is > starting up, there's a lot of contention for the UI thread: the window > is being drawn and there might be animations or other effects, not to > mention that infernal throbber. > > The good news is that turning off the tab strip's Core Animation layer > improves this, as well as many other things. A patch to do this just > landed again at r24881 (on the third try). In my experiments, this > reduced the time from when the renderer requests the new tab page to > the time that all of the resources are present in the renderer from > between 1-3 seconds to just a hair over 300ms. This is a huge > improvement. > > I still think that 300ms is too long, though, especially when you > consider that this is not the time from launch, but the time from the > renderer's request, which itself can come as much as 300ms after > launch. > > I'm experimenting with a change that lets the new tab HTML and CSS be > served directly from the browser's IO thread instead of the UI thread. > Since these tasks require profile and theme access, the approach is > to build up the HTML and CSS early, on the UI thread where such access > is permitted, and cache them. When a request for the HTML or CSS > comes in, the browser can then service them entirely on the IO thread. > This gets the data into the renderer almost immediately after it's > requested, so that the renderer is able to fully lay out the new tab > page without having to wait for the browser to do things like draw the > new tab. Additional resource requests, such as thumbnails and > favicons, are still being served from the UI thread. Based on my > experiments, this shouldn't be a problem: the renderer isn't ready to > receive these until it's done with layout based on the HTML and CSS, > and once it reaches that point, the browser should be done with heavy > UI tasks and there shouldn't be much contention for its main loop. It > might ultimately be better to be able to serve all new tab requests > from a non-UI thread in the browser, but that could mean additional > caching. > > This change improves new tab page performance by about 65ms on my > laptop in release mode. Now we're down to 240. Great. What else can > we do? > > Well, that annoying throbber is still chewing up time, causing some > amount of UI loop contention while the images, thumbnails, and icons > are fetched. Windows and Linux don't have a throbber for the new tab > page. We shouldn't either. Excellent, now we're down to 200ms. It's > still high, but it's reasonable. It's a perceptible improvement from > the 300ms we started with. > > What else can we do? One thing that's begging for improvement based > on my timings is the renderer startup delay. We don't bother starting > up a renderer until about 200ms after launch, and it takes the > renderer 70ms from that point to reach its main loop. I bet that if > we did renderer startup much earlier, we'd have one warm and ready to > go by the time we needed it. This doesn't have to be > startup-specific, we could always maintain a spare renderer in the > pool (within reason) so that we're not caught twiddling our thumbs > waiting for the one we just launched. Interesting. One of these days, I need to finish my intern's summer project (he had to leave early). It was a rewrite of thumbnail storage so we only store the thumbnails for the new tab page, rather than in the history system for each day. One thing I've thought of lately is to store the actual new tab items in this same database. This way, we don't have to wait for history to load (>10MB) and we don't have to do a complex query over that history data to get the new tab page data. Your post makes me wonder if this new "New Tab Page Database" can live on the I/O thread. It will actually run the DB operations on yet another thread, but we wouldn't have to go through the UI thread. Old way: I/O thread -> UI thread -> History thread -> UI thread -> I/O thread. New way: I/O thread -> DB thread -> I/O thread There's no reason this object needs to live on the UI thread, so the only problem would be plumbing the requests so it gets served properly (though this might actually be kind of hard). Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Formatting substrings in a views::Label
+finnur who did this for the about box. Brett On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote: > Argh. Forgot attachment. > > > > On Wed, Aug 26, 2009 at 2:15 PM, Aaron Boodman wrote: >> I'm playing with different ideas for the extension install dialog, and >> would like to do something like the attacked mock. >> >> I can see that there is no support for this in Label presently and I'm >> told by Dean that the APIs for doing this are different across >> platforms. Is it worth adding an abstraction to Label for this? >> >> - a >> > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Copying of profiles across systems
On Wed, Aug 26, 2009 at 10:23 AM, Avi Drissman wrote: > I've heard people proclaim the principle of being able to copy a profile > across systems as being a deciding factor for certain changes (e.g. the > history epoch change). However, it doesn't seem to be universally held or > obeyed, and I'm not sure to the extent to which it can be obeyed. So some > questions: > > - Is "profile platform independence" a guiding principle? > - To what extent do we work to make it reality? I don't think this is a guiding principle. We should do it when it's reasonable. I think most places it is reasonable to do so. > - In the cases where it can't be kept (e.g. download folder path) should we > keep a copy for each platform? I don't think so. > - Is it worth rewriting today's code that doesn't conform (e.g. extensions > and themes which use full paths and platform path separators)? I don't think so, although I do wonder if full paths are necessary, even if we're not worried about platform portability (not knowing anything about what these are used for if there are any). Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Linux/Mac time epoch change
I just checked in r24417 which changes the "0" for times on Mac & Linux (used to mean 1970) to match Windows (1601). This means that the profiles can be copied between systems without getting the dates all wrong, and should also fix some bugs related to cookie expiration ( http://code.google.com/p/chromium/issues/detail?id=14734 ). This will be in the release notes of the next dev version affected, but I wanted to add some extra info for developers who may be affected. When you run a version of Chrome after this, it will do a one-time update of your history database to change the times, so you may notice additional lag before the new tab page or autocomplete results are available. You shouldn't have to worry about exiting in the middle of this process, it should recover. It deletes the full text index of your history, which, because of its size, didn't seem worth updating. You won't get full text search results from before the upgrade, but any browsing after that will be indexed. It also deletes any history older than 3 months rather than migrates it (this won't affect most users of Mac & Linux, since they haven't been using it that long). You can load the updated profile in previous versions of Chrome, but the dates will be far into the future, and any data added by the old version will be wrong and won't be fixed when you start using the new one again. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about resource_dispatcher_host.h
On Mon, Aug 24, 2009 at 12:49 PM, hap 497 wrote: > Thanks. But the picture in the document shows there is only 1 > ResourceDispatcherHost and there are 2 Renderer Processes: > > http://dev.chromium.org/developers/design-documents/multi-process-architecture > And the ResourceDispatcherHost has access to both Channels for each Renderer > Process. Information about each request including the originating renderer is tacked onto each URLRequest in the form of "ExtraRequestInfo." See one of the functions in there such as ResourceDispatcherHost::OnResponseCompleted for how this is retrieved. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: private VM field on the about:memory page
On Mon, Aug 24, 2009 at 6:18 AM, Anand Mistry wrote: > I'm looking at the about:memory page and am wondering how useful is the > private VM field? Would it be just as good to have a total VM instead? The > reason I ask is because private VM doesn't map easily to Linux where private > pages can be shared becuase of copy-on-write. Did you see the memory usage backgrounder? http://dev.chromium.org/memory-usage-backgrounder It's written to be Windows specific, but 80% of the things will apply to Linux. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Wed, Aug 19, 2009 at 9:49 PM, Brett Wilson wrote: > On Wed, Aug 19, 2009 at 6:00 PM, Dean McNamee wrote: >> >> I kinda feel like this is one of those things you can try hard to >> premeditate, but in the end you'll just have to deal with it being >> ugly for a while and hope it eventually converges to something better. > > The changes in the bulk of the Chrome code are pretty easy to tell in > advance. Just search for OS_LINUX. It would be nice if the first pass > didn't just tack on OS_FREEBSD to every OS_LINUX in chrome, especially > since I think there's a good chance it won't be maintained > longer-term. I definitely believe you that there will be a bunch of > unknown build/third_party stuff. > >> Sort of a non-answer, but I'd be happy to see this running on a BSD >> first, and then we can argue about the patch. > > Are you suggesting getting it running before checking anything in? I > think BenL's was planning to do it piecemeal. Here's an idea I like: Do a pass of porting "base" and "chrome/browser/renderer_host", which are some of the key infrastructure bits that have a bunch of platform-specific stuff in them. It doesn't have to be "everything is working perfectly," but rather do a patch to modify the ifdefs as best as you can figure out. Then we can discuss in concrete terms how the ifdefs in the code look and whether they're OK or need rearchitecting. This wouldn't need to block the current build patch, but I think should be done before committing ifdefs to the code. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Wed, Aug 19, 2009 at 6:00 PM, Dean McNamee wrote: > > I kinda feel like this is one of those things you can try hard to > premeditate, but in the end you'll just have to deal with it being > ugly for a while and hope it eventually converges to something better. The changes in the bulk of the Chrome code are pretty easy to tell in advance. Just search for OS_LINUX. It would be nice if the first pass didn't just tack on OS_FREEBSD to every OS_LINUX in chrome, especially since I think there's a good chance it won't be maintained longer-term. I definitely believe you that there will be a bunch of unknown build/third_party stuff. > Sort of a non-answer, but I'd be happy to see this running on a BSD > first, and then we can argue about the patch. Are you suggesting getting it running before checking anything in? I think BenL's was planning to do it piecemeal. > I just went through some work trying to build it on OpenBSD (promised > a friend I'd try). There are a lot of little things we need to do > before we even have this debated. Pretty much everything in > third_party (icu, libevent), gmock, etc. Some of these will probably > require changes upstream. Interesting, thanks for the information. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: FreeBSD port and ifdefs
On Wed, Aug 19, 2009 at 1:23 PM, Darin Fisher wrote: > On Wed, Aug 19, 2009 at 1:14 PM, Evan Martin wrote: >> >> Rad that you're doing this! >> >> I think that we shouldn't have any linux-specific directories except >> for one or two cases where it's *really* Linux-specific (like crash >> dumping or ). So the same should be true for you. >> >> It seems the configurations we'll see most frequently in code are: >> 1) POSIX (basically, non-Windows -- we have this already) >> 2) POSIX minus Mac (since Mac has the most extensions, especially at >> the GUI layer) >> 3) POSIX minus Linux (aka everything BSD-derived, more or less) >> >> Dean proposes a define for #2, agl proposes a define for #3. I think >> it'd be nice to keep the defines down if possible. >> >> I wonder if #2 could be covered by OS_POSIX && TOOLKIT_GTK. Or, > > What about TOOLKIT_VIEWS? Darin is right. There is actually a #4 on Evan's list: POSIX minus Mac minus Views. I did a search for every place we use OS_LINUX. They fall into a couple of cases: - Graphics stuff like X-windows & fonts that are shared between TOOLKIT_GTK and TOOLKIT_VIEWS on Linux. - File path handling stuff. Here Linux/BSD are different from Mac, because there is no encoding, while Mac defines one. - Low level stuff like threads, where Mac has something fancy, but we want to use pthreads or whatever on Linux - A very few system info queries that are likely different between Mac, Linux, and *BSD. Maybe this also includes crash reporting? - Some that should be TOOLKIT_GTK instead of OS_LINUX It looks like the vast majority of them fall into the first two categories (graphics and file paths). It would be nice to optimize our ifdefs so these common ones don't get more complicated. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: browser/sync is moving in
On Mon, Aug 17, 2009 at 11:19 PM, est wrote: > > Thanks for the explaination, Nick Carter. > > I understand now, Chrome is a Google product while Chromium is a open- > source project. > > Any thing else differs between Google Chrome and Chromium? I found > dictionaries missing from Chromium. Dictionaries are in chrome/third_party/hunspell/dictionaries You need to copy the one(s) you want to your profile dictionaries directory for them to work. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: RenderView page ID
On Mon, Aug 17, 2009 at 2:59 PM, Evan Stade wrote:
> I believe Brett meant to say chrome/renderer/render_{view,widget}.{h,cc}
They're both correct, depending on whether you want the browser or the renderer.
Brett
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: RenderView page ID
On Sun, Aug 16, 2009 at 7:56 PM, hap 497 wrote: > From this documentation, > http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code > it said each RenderView has a page ID. > But from RenderView.h, I dont see any attribute for page ID. > Can you please tell me where does RenderView keeps its page ID? You want chrome/browser/renderer_host/render_view.h which unfortunately shares a class name with something in WebKit. The ID you are looking for is routing_id in RenderWidget (the base class of RenderView). Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac History Menu
On Wed, Aug 12, 2009 at 12:18 PM, Avi Drissman wrote: > Brett— > > Are we talking about the history page, or history items? The history page > gets its own tab, sure. But when someone picks an item from the history > menu, where does it go? I think current foreground tab is right, with > command for background tabs. Yes, I was confused. I think clobbering is OK in that case. My new & improved opinion is it should act like the drop-down on the back/forward menus. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Mac History Menu
On Wed, Aug 12, 2009 at 11:15 AM, Robert Sesek wrote: > Two things about the Mac history menu that I'd like people to weigh in on: > 1. The "Show All History" command should have a keyboard shortcut. We can't > use the logical Cmd+H because it's bound by the system. Stuart suggested > Cmd+Y, as that's what Camino uses. Firefox and Safari both lack keyboard > shortcuts for this menu command, so it's really up to us to define it. So > Cmd+Y seems as good as any other. Thoughts? > 2. Currently, items in the history menu open in the current foreground tab. > I'm currently working on a CL to make it so that if you hold down the Cmd > modifier while selecting a history/bookmark menu item, it will open in a new > tab. I was wondering, though, if we should instead reverse this behavior so > that history items (and maybe bookmark?) open in a new tab, and you can use > the modifier to open in the current tab. Windows always opens history in a new tab. I think this is the correct behavior: I don't think anybody expects going to history will clobber their current tab. I don't see why there should be a modifier key to clobber the current tab. It seems obscure, useless, and potentially confusing. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Do we have any existing code for reading/writing INI files?
On Mon, Aug 10, 2009 at 3:28 PM, Daniel Cowx wrote: > > Just wondering if there's any code kicking around somewhere in the > codebase for reading/writing INI files? No, we don't deal with ini files at all to my knowledge. We use JSON for that type of thing. What do you need it for? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How do I filter CC'd code reviews in Gmail?
On Fri, Jul 31, 2009 at 5:44 PM, Rahul Kuchhal wrote: > I thought to: and -cc: would work in this case? Have you tried > using that in "Has the words" on Filter edit screen? One problem with this is that it doesn't fix the case where people respond to the review mail via email rather than Reitveld. Then I get put on the "to" line since I was originally in the "reply-to" line. I doubt I will have much luck making people stop using email this way, so I will try one of the "second email" approaches. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: new hunspell has tons of valgrind warnings... revert?
On Sat, Aug 1, 2009 at 4:34 PM, Dan Kegel wrote: > I suppose you could try running the hunspell test suite itself > under valgrind. Their README tells how to do it, but > when I tried, I couldn't get it to work. (Wonder if that > means they haven't run it, either?) Hi Dan, Purify has some problems with tracking memory that the OS memory maps, and it ends up giving uninitialized memory reads for any 0xCCs that the OS memory maps (since it doesn't see the write). Does Valgrind have a similar problem? Most of the data is memory mapped. It seems unlikely to me given we didn't have this problem before, but it's worth checking. My main concern is: who is working on this? It's OK like this for a couple of days I guess, but this seems like a potentially serious problem we don't want to file a bug and "get to it" later. It also seems like Mohammed will need help, and I'll be out part of next week (still figuring out the days). If we can't fond somebody to look at this soon, we should probably back out until there is somebody. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] How do I filter CC'd code reviews in Gmail?
I added myself to some watchlists and I get a bunch of email about a lot of reviews But this has confused my Gmail filters, which automatic ally label and archive code reviews not addressed directly to me, and all of my CCd code reviews show up in my inbox. Anybody know how to reliably detect the difference between "I'm the reviewer" and "I'm CC'd on a review" in a Gmail filter? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebContents class in chromium?
On Sat, Jul 25, 2009 at 4:27 PM, n179911 wrote: > > Hi, > > For > http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code, > it said > For web content, this specialization is WebContents in > chrome/browser/web_contents.cc. There are also a few other types for > more specialized tabs. We will assume we are creating a web page. > > But I checkout chromium source code, but I can't find the file > web_contents.cc or I can't find the class WebContents anywhere. > Can you please tell me what 'tab content' are created for Web content now? Mohammed is correct, the different TabContents types have been removed, and TabContents now handles displaying web pages only. I updated this part of the document. Thanks for pointing this out. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] Using system libraries for Chromium
On Wed, Jul 22, 2009 at 2:58 PM, Adam Langley wrote: > > On Wed, Jul 22, 2009 at 9:50 PM, Darin Fisher wrote: >> Personally, I much prefer the #include approach. Is it a problem to >> wait for the GYP change that makes this possible? > > Well, I could make it #include everywhere and then add an > include directory in the case that we aren't using the system libpng. > If folks are happy with that (it goes against our usual policy of > avoid -I flags), then that's cool. Looks like you made this change in the patch, although I don't see the include rule update for chrome.gyp. I guess some obvious ones like and are fine. Some of them give me pause, like , which we also have in views and may also have in other parts of the system, and this will cause compilation problems on Windows (I think). "event.h" just isn't very clear to me either. You could also have a define USE_SYSTEM_LIBRARIES and you write: #ifdef USE_SYSTEM_LIBRARIES #include #else #include "third_party/libpng/png.h" #endif Which I find much more readable than your "magic" define for the png filename. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Please keep TOOLKIT_VIEWS green!
On Tue, Jul 21, 2009 at 8:42 AM, Nicolas Sylvain wrote: > On Tue, Jul 21, 2009 at 8:31 AM, Paweł Hajdan Jr. > wrote: >> >> Can we have a trybot with that configuration, which would just compile the >> code? I think it would really save people's time. I never build with >> TOOLKIT_VIEWS, and in case of breakage I would have to immediately revert >> and then investigate. If I got a trybot failure, I would know much more >> before committing. > > Ben: How likely is this to break? > I'm reluctant to add yet another try bot because they do take a lot of > resources. There are maybe 200-300 try changes sent every day. That means > we need enough resources to build this configuration that many times, and it > needs to answer fast enough. I don't think an automatically-running trybot is very critical for this build at the moment. Most of the things that break it are pretty simple (need to add a file to GYP, or maybe a stub for something) so the breakage won't be super complicated. Most errors will be caught by the regular trybots. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Mon, Jul 13, 2009 at 10:05 AM, Jeremy Orlow wrote: > On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher wrote: >> >> On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson wrote: >>> >>> On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlow wrote: >>> > WebCore::String has the interesting property of differentiating between >>> > an >>> > empty string and a null string. In string16, however, there is no such >>> > thing >>> > as null. >>> > The LocalStorage implementation I'm working on proxies data between the >>> > rednerer processes and browser process. Some of this data is in the >>> > form of >>> > WebCore::Strings that need to differentiate between empty and null. >>> > I could add a boolean to all IPC messages where the string could be >>> > null and >>> > then add explicit checking (rather than using the elegant and implicit >>> > type >>> > conversions that normally happen from WebCore::String <-> >>> > WebKit::WebString >>> > <-> base::string16) but that seems pretty ugly. I think a better >>> > solution is >>> > adding a new type to base, adding serializing code to >>> > common/ipc_message_utils, and adding implicit type conversions between >>> > WebKit::WebString and this new type. >>> > First of all, is that a good idea? Second of all, what would be a good >>> > name >>> > for it? NullableString16? >>> >>> What is happening with Darin's WebCore interface stuff. I remember he >>> was planning on having some kind of WebString that could be passed to >>> IPC. Is this still the case, and can we use that instead? >>> >>> Brett >> >> WebString exists (has for many moons now). It is just a wrapper for >> StringImpl, >> the same way WebCore::String is. It is not threadsafe due to the >> reference >> counting done for StringImpl. That makes it a very bad candidate for >> serializing >> via Chrome IPC. Someone might naively handle such an IPC on the IO >> thread, >> and then PostTask the WebString to another thread. We could try to solve >> that >> using assertions, but I decided instead to avoid serializing non-POD >> WebKit API >> types over Chrome IPC. >> For reference: >> >> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/api/public/WebString.h?view=markup >> -Darin > > I guess what I'm proposing is that we have a string data type that can be > safely passed across IPC but that has all the possible states a > WebCore::String does. I believe adding the null state is the only thing > missing. > In my code, I've worked around this by passing a boolean along with the > string16 which states whether the string is null. This will work, but since > AppCache, Database, and maybe others will soon be passing WebStrings through > the IPC layer to their backends in the browser process, I'd be surprised if > this doesn't come up again. Yes, I think NullableString16 is better than passing a separate bool. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlow wrote: > WebCore::String has the interesting property of differentiating between an > empty string and a null string. In string16, however, there is no such thing > as null. > The LocalStorage implementation I'm working on proxies data between the > rednerer processes and browser process. Some of this data is in the form of > WebCore::Strings that need to differentiate between empty and null. > I could add a boolean to all IPC messages where the string could be null and > then add explicit checking (rather than using the elegant and implicit type > conversions that normally happen from WebCore::String <-> WebKit::WebString > <-> base::string16) but that seems pretty ugly. I think a better solution is > adding a new type to base, adding serializing code to > common/ipc_message_utils, and adding implicit type conversions between > WebKit::WebString and this new type. > First of all, is that a good idea? Second of all, what would be a good name > for it? NullableString16? What is happening with Darin's WebCore interface stuff. I remember he was planning on having some kind of WebString that could be passed to IPC. Is this still the case, and can we use that instead? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Watchlist matching any part of a path
On Tue, Jul 7, 2009 at 6:20 PM, Andrew Scherkus wrote: > According to the watchlist file, brettw is watching "base" from /src > kylep sent me a code review that only modifies touches files in > /src/media/base, however brettw got added to the cc list. > Is this intended behavior for watchlists or should they be more explicit on > what they match? I was just wondering the same thing! Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: About hunspell
On Mon, Jul 6, 2009 at 9:14 PM, Dmitry.Skiba wrote: > > Ah yes, it's other way around. Strange that I didn't think about it :) > > By the way, what do you think about implementing NodeReader that reads > data from file, not memory? Why would you want to do that? We memory map the file so we don't have to read it in all at once. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: About hunspell
On Fri, Jul 3, 2009 at 12:00 AM, Dmitry.Skiba wrote: > > Recently I was playing with hunspell and got very displeased with its > code (which claims to be cpp, but in fact 'classified' c). I even > started to think about rewriting it in, you know, "correct" cpp. Then > I realized that Chrome also uses hunspell and went to the repository. > I saw a very useful patch to HashMgr, which in fact alters its > behaviour pretty much. And at the same time all old code were left as > is. Glad you like it! > So I have a question: why? Why didn't you just remove all that old and > unused code? It's unlikely that your patches will be merged into > hunspell. We do this so we can tell what we changed so it's easier to merge to future versions of Hunspell. Of course it should be possible to do with SVN logs only, but it makes it a little easier. I believe there are some new capabilities we would like to take advantage of in the newer ones. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Icelandic dictionary for Chrome
On Fri, Jun 19, 2009 at 1:15 PM, Sverrir Á. Berg wrote: > I'm hoping to be able to add Icelandic spelling check to Chrome Before I > invest a lot of time I have some quick questions/observations: > I found an myspell/aspell dictionary for Open Office > here: http://wiki.services.openoffice.org/wiki/Dictionaries#Icelandic_.28Iceland.29 and converted > it to bdic format using the instructions > here: http://dev.chromium.org/developers/how-tos/editing-the-spell-checking-dictionaries. > When I replace a supported bdic with this one I can spell check mostly but > seen errors such as: > Run-Time Check Failure #2 - Stack around the variable 'candidate' was > corrupted. (suggestmgr.cxx:680). > Any pointers on where to start? I don't know if the dictionary/conversion > are at fault or hunspell. Yikes! I have no good input. Most of these bugs have been caused by the code reading the custom format or in its interaction with the rest of Hunspell. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Conventions and patterns for multi-platform development
Our team has had somewhat of an ad-hoc approach to organizing code that's different across platforms. In many cases our approach has been quite good. In others, less so, and there have also been questions about what the preferred method for writing a certain component in a cross-platform way. Last night Ben and I wrote a document that tries to clarify this. It's a combination of what we're doing now that works well, and what we probably should be doing: http://dev.chromium.org/developers/design-documents/conventions-and-patterns-for-multi-platform-development This is linked to from the "Engineering design documents" page. If you're starting a new component or reorganizing an existing one, try to follow these guidelines. It can't possibly cover every case, so you'll have to use your best judgement. Feedback from people who have done a lot of this stuff would be great. Ideally it would be easy to follow and cover most cases for everybody. Thanks! Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How Render process send Image IO request to Browser process
There are a surprising number of comic characters on here. I bet you know Meryl Silverburgh! Generally this type of thing is on the dev site like here: http://dev.chromium.org/developers/design-documents/multi-process-resource-loading Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Mac painting problems
I was informed that I may have broken mac tab contents painting in 18363. I have to leave now, so if this is causing you problems you can back me out. If somebody wants to fix it instead, I'll make you chocolate chip cookies :) Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to change the cursor smoothly for a view
On Wed, Jun 10, 2009 at 9:02 PM, Brett Wilson wrote: > On Wed, Jun 10, 2009 at 8:55 PM, Daniel Cowx wrote: >> >> I've got a composite view that consists of a SkBitmap and >> views::Label. I'd like to use IDC_HAND (hand cursor) for this >> composite view so I've overridden view::GetCursorForPoint(...) >> >> Though this kinda works, it causes the cursor to jitter/flicker as it >> calls this function repeatedly based on the current cursor coordinates >> within the view. How can I implement the desired functionality without >> this flickering? >> >> I've also tried overriding view::OnMouseEntered() and >> view::OnMouseExited() and manually calling ::SetCursor() to no avail. >> Can someone please shed some light. > > I believe the "link" view (such as is used in the about box) turns the > cursor to a hand. I would check how that works. I guess you knew that from a re-reading of your email. In that case, I don't know. :) Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to change the cursor smoothly for a view
On Wed, Jun 10, 2009 at 8:55 PM, Daniel Cowx wrote: > > I've got a composite view that consists of a SkBitmap and > views::Label. I'd like to use IDC_HAND (hand cursor) for this > composite view so I've overridden view::GetCursorForPoint(...) > > Though this kinda works, it causes the cursor to jitter/flicker as it > calls this function repeatedly based on the current cursor coordinates > within the view. How can I implement the desired functionality without > this flickering? > > I've also tried overriding view::OnMouseEntered() and > view::OnMouseExited() and manually calling ::SetCursor() to no avail. > Can someone please shed some light. I believe the "link" view (such as is used in the about box) turns the cursor to a hand. I would check how that works. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about BrowserRenderProcessHost::OnPageContents() method
On Sat, Jun 6, 2009 at 11:13 PM, meryl wrote: > > Hi, > > I add debug print status in BrowserRenderProcessHost::OnPageContents > () to print out the value of 'contents' > > void BrowserRenderProcessHost::OnPageContents(const GURL& url, > int32 page_id, > const std::wstring& contents); > // original code > > // I add this: > cout << " BrowserRenderProcessHost::OnPageContents" << endl; > cout << " <" << endl; > > cout << contents; > > cout << " <" << endl; > > } > > My question is why I only see the 'Text' of the page? I tried loading > www.google.ca, but I only see these values: I'm assuming your question is why it doesn't also contain the HTML... This function is called by the renderer with the text of the page so we can index it for history search. As a result, it contains only the text, since we don't want to index the HTML. If you have code that needs to get the full HTML of the page, you need to be in the renderer process and walk the DOM yourself. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [extensions] Gleam API proposal
On Wed, Jun 3, 2009 at 1:00 PM, Aaron Boodman wrote: > > [I actually created this awhile ago, but never sent it 'round] > > It is really common for extensions to want to offer additional > contextual options for content elements. For example "Download this > movie", "edit this image", "call this phone number", etc. > > You can use content scripts for this, but since it is such a common > task, I think it deserves its own proper API. This would allow this > class of extensions to interact well with pages, with each other, and > have a nice consistent UI. > > Anyway, here's an API proposal for such a thing: > > http://dev.chromium.org/developers/design-documents/extensions/gleam-api > > Comments wanted! I think this general concept would be great. Say I have an extension that allows me to open images in Photoshop. Does that mean all images would have these things highlighting them? That seems like it would be annoying. When I read this, I first thought it was just a way to insert stuff into a context menu when the user right-clicks on that. Perhaps having both modes would be useful. The image editing or video download extension would register itself as interested in these things only from the context menu, and they'd get a chance to insert commands into that menu to do whatever they want. This could also be useful for less-intrusive extensions. I want the ability to right-click on one to open it in my favorite mapping provider, but I *don't* want all addresses glowing blue. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Question about chromium architecture
On Tue, Jun 2, 2009 at 4:57 PM, Meryl Silverburgh wrote: > > I am reading this document > "http://dev.chromium.org/developers/how-tos/getting-around-the-chrome-source-code"; > about chromium source code: > It said: > > renderer: Code for the subprocess in each tab. This embeds WebKit and > talks to browser for I/O. > > Does that mean chromium do not use the HTTP stack/library that Webkit is > using? WebKit uses different HTTP stacks depending on the port. We use a different one than any other ports. > And does that mean all the I/O of each tab (webkit renderer) will be > sent to 'browser' for I/O, and there is 1 I/O thread in the browser to > handle the I/O requests from ALL tab? Correct. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Clobber if you get V8 linker errors in the next sync
When I landed the WebKIt integration this morning a bunch of the bots needed clobbering due to linker errors. The errors were missing V8 handles while linking generate_profile. I haven't seen any of the commonly-compiled projects fail because of this, so it's possible you don't have to clobber since you probably don't care about this project. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chromium 1 process per tab architecture
On Wed, May 27, 2009 at 5:15 PM, Charles Reis wrote: > Those documents are certainly the best place to go to understand the process > architecture (since it's not strictly process-per-tab, but that is an easy > way to think about it). > I think the answers to your specific questions are (1) yes, Chromium will > prompt you if a rendering engine process becomes unresponsive to give you a > chance to kill it, and (2) I don't think there's any UI in Chromium for > placing a memory quota on a rendering engine process. The exception is that there is a global cap on the memory cache for web pages and images. This quota is distributed to the renderers so we don't waste too much space with large caches in each one. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: reminder: don't use CHECK()
On Wed, May 27, 2009 at 11:56 AM, Amanda Walker wrote: > On Tue, May 26, 2009 at 11:31 PM, Brett Wilson wrote: >> >> Don't bother doing an assertion when the next line will crash anyway: >> DCHECK(foo); >> foo->DoSomething(); >> will normally crash pretty obviously dereferencing a NULL pointer >> (even though it will be inside DoSomething). > > Well, that all depends on what DoSomething does, what happens to be in low > memory, whether or not it's also passed an index that's applied to some > component of "this", etc. If foo can be NULL at that point, for whatever > reason, not checking it before calling DoSomething is probably a recipe for > a security hole. Like I said, if there are security considerations for your code, then you need to use CHECK and not DCHECK. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: reminder: don't use CHECK()
On Tue, May 26, 2009 at 6:22 PM, Aaron Boodman wrote: > > I get different stories about this all the time from different people. > It would be great to have them as part of the style guide so that I > can refer to it. > > One that you didn't cover is the invariant case. I originally used > DCHECKs, but it seems like if you're just going to crash on the next > line anyway, a CHECK makes more sense. Here's what I do: Generally, use DCHECK(). Use CHECK when the problem indicates a potential security problem. I've also added them in cases where there are crash reports and I can't find the source of the problem. CHECK()s around the entrypoints for various conditions can help narrow this down. Don't bother doing an assertion when the next line will crash anyway: DCHECK(foo); foo->DoSomething(); will normally crash pretty obviously dereferencing a NULL pointer (even though it will be inside DoSomething). NULL pointer dereferences are usually the easiest bugs to see. DCHECK in this situation is especially useless since if you're running in a debug build in a debugger such that they are enabled, it will be even more obvious. However, use assertions when the argument is saved for later use, so the offender is obvious (this happens in class constructors most often). Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 7:24 PM, Brett Wilson wrote: > On Wed, May 13, 2009 at 6:12 PM, Greg Spencer wrote: >> On Wed, May 13, 2009 at 4:07 PM, Brett Wilson wrote: >>> >>> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker >>> wrote: >>> > >>> > Perhaps what we need is a companion to FilePath. For example: >>> > >>> > FilePath: much as it is now, lightweight, "alternative to string >>> > manipulation". >>> > FileReference: heavierweight, can talk to the file system and have >>> > carnal knowledge of platform specifics for things like resolving / >>> > canonicalizing pathnames, determining whether or not they refer to the >>> > same files, generating C strings that can be passed to 3rd party >>> > libraries, etc. >>> >>> I think this is very dangerous. >>> >>> I think Greg should not be talking to the filesystem when inserting >>> filenames into a set. We don't allow filesystem access from the UI >>> thread of Chrome, and I think other parts of our system should also >>> not do filesystem access on their critical threads, especially if they >>> want to be more part of Chrome in the future. >> >> Well, so the use I have for this in O3D at the moment is in our importer, >> which currently is a separate command-line tool that reads Collada files and >> writes out our wire format for geometry. So it isn't meant to be occuring >> in a UI thread, but I could see times when it might be useful to know for >> sure if two files reference the same file in the UI thread (dragging and >> dropping a file onto a drop zone, for instance). >> I do need to know if I have the same file more than once in a set because >> the COLLADA file might reference the same texture multiple times, or (more >> dangerous) it might reference a file that is one file on Windows, >> but (incorrectly) maps to two different files in the (Unix-path-format) .tgz >> files. To detect that, I need canonicalization. > > You can't actually canonicalize a filename on Windows, so I think it's > dangerous to write a component that claims to do it. I guess you could call GetShortPathName every time you see a name. But I think that's a crazy solution. I still think you should do my suggestion below. > I think you just need to come up with some simple rules that makes it > work most of the time. Personally I would do ASCII lowercasing and > stop worrying about it. If you use ICU to lower-case "correctly," > Windows won't necessarily agree and you won't be able to use that > file. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 6:12 PM, Greg Spencer wrote: > On Wed, May 13, 2009 at 4:07 PM, Brett Wilson wrote: >> >> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker >> wrote: >> > >> > Perhaps what we need is a companion to FilePath. For example: >> > >> > FilePath: much as it is now, lightweight, "alternative to string >> > manipulation". >> > FileReference: heavierweight, can talk to the file system and have >> > carnal knowledge of platform specifics for things like resolving / >> > canonicalizing pathnames, determining whether or not they refer to the >> > same files, generating C strings that can be passed to 3rd party >> > libraries, etc. >> >> I think this is very dangerous. >> >> I think Greg should not be talking to the filesystem when inserting >> filenames into a set. We don't allow filesystem access from the UI >> thread of Chrome, and I think other parts of our system should also >> not do filesystem access on their critical threads, especially if they >> want to be more part of Chrome in the future. > > Well, so the use I have for this in O3D at the moment is in our importer, > which currently is a separate command-line tool that reads Collada files and > writes out our wire format for geometry. So it isn't meant to be occuring > in a UI thread, but I could see times when it might be useful to know for > sure if two files reference the same file in the UI thread (dragging and > dropping a file onto a drop zone, for instance). > I do need to know if I have the same file more than once in a set because > the COLLADA file might reference the same texture multiple times, or (more > dangerous) it might reference a file that is one file on Windows, > but (incorrectly) maps to two different files in the (Unix-path-format) .tgz > files. To detect that, I need canonicalization. You can't actually canonicalize a filename on Windows, so I think it's dangerous to write a component that claims to do it. I think you just need to come up with some simple rules that makes it work most of the time. Personally I would do ASCII lowercasing and stop worrying about it. If you use ICU to lower-case "correctly," Windows won't necessarily agree and you won't be able to use that file. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 4:34 PM, Amanda Walker wrote: > On Wed, May 13, 2009 at 7:07 PM, Brett Wilson wrote: >> On Wed, May 13, 2009 at 3:51 PM, Amanda Walker wrote: >>> >>> Perhaps what we need is a companion to FilePath. For example: >>> >>> FilePath: much as it is now, lightweight, "alternative to string >>> manipulation". >>> FileReference: heavierweight, can talk to the file system and have >>> carnal knowledge of platform specifics for things like resolving / >>> canonicalizing pathnames, determining whether or not they refer to the >>> same files, generating C strings that can be passed to 3rd party >>> libraries, etc. >> >> I think this is very dangerous. >> >> I think Greg should not be talking to the filesystem when inserting >> filenames into a set. We don't allow filesystem access from the UI >> thread of Chrome, and I think other parts of our system should also >> not do filesystem access on their critical threads, especially if they >> want to be more part of Chrome in the future. > > But in context, he's passing these things to 3rd party libraries that > will be doing plenty of file system access (importing and exporting > data, for example). That's why I was suggesting something separate > from FilePath for such use. Then he doesn't need canonicalization at all. He needs to know how the third party library is going to use the string for filesystem access and then do the corresponding transformations. That does not involve filesystem access. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Changes to FilePath?
On Wed, May 13, 2009 at 3:51 PM, Amanda Walker wrote: > > Perhaps what we need is a companion to FilePath. For example: > > FilePath: much as it is now, lightweight, "alternative to string > manipulation". > FileReference: heavierweight, can talk to the file system and have > carnal knowledge of platform specifics for things like resolving / > canonicalizing pathnames, determining whether or not they refer to the > same files, generating C strings that can be passed to 3rd party > libraries, etc. I think this is very dangerous. I think Greg should not be talking to the filesystem when inserting filenames into a set. We don't allow filesystem access from the UI thread of Chrome, and I think other parts of our system should also not do filesystem access on their critical threads, especially if they want to be more part of Chrome in the future. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skia is moving
On Wed, May 13, 2009 at 12:39 PM, Darin Fisher wrote: > That is what I meant by pain > It only applies to "third party" code that conforms to the google style > guide, which says that all include paths must be relative to the root. Come > to think of it, I think this could cause problems for such projects, since > I'm sure the V8 developers don't think of V8 as a third party piece of code, > and in their world, V8 is not checked out into a directory named > third_party. We'd probably end up having to add "src/third_party" to the > include path or something like that. We already do this for all third_party code, but from chrome we include it with the third_party prefix. I think this is a good approach. In serverland, they actually change the includes in the third party files which I don't think we should do. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Skia is moving
On Tue, May 12, 2009 at 2:48 PM, Nicolas Sylvain wrote: > On Tue, May 12, 2009 at 2:22 PM, Stephen White > wrote: >> >> I'm in the process of updating chromium to use tip-of-tree skia, and in >> the same CL, moving skia to a third_party directory, >> retrieved via DEPS. What this means for you: > > Hi, > Why do you want to move it to third party? > The other projects developed at google that we fetch through DEPS like > googleurl, breakpad, gtests and courgette are all living in src, not > third_party.. > Nicolas If our repo is not the canonical representation, they should all be in thierd party. So I think that all your examples are in the wrong place. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: CIA-bot on #chromium?
On Tue, May 12, 2009 at 9:35 AM, Adam Barth wrote: > > One feature of #webkit that I find useful is that every commit is > summarized by the CIA-bot. > > http://cia.vc/ > > Should we enable this for #chromium? I think it's noise and I suspect we have even more checkin traffic than they do. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
2009/5/6 Andrew Scherkus : > On Tue, May 5, 2009 at 9:49 PM, Albert J. Wong (王重傑) > wrote: >> >> On Tue, May 5, 2009 at 9:38 PM, Amanda Walker wrote: >>> >>> Ah, I see. Hmm, going in that direction (from a GraphicsContext back >>> up to the PlatformCanvas that wraps it) is an interesting question >>> (the rest of our rendering code goes in the other direction). And as >>> Brett can attest, this isn't the first time that PLATFORM(CG) has >>> caused a headache--we just (so far) haven't been willing to >>> duplicate/fork all of the Mac rendering code that currently lives in >>> PLATFORM(CG), since there's a lot of it (especially text handling) >>> that would end up the same. >>> >>> Brett's idea (change your paint routine to take a raw pixmap (an >>> RGBA32Buffer), which we can easily draw into a GraphicsContext on any >>> platform, is basically what the ImageDecoder subclasses do (including >>> rudimentary multi-frame support for things like animated GIFs). If >>> that will work, it's probably the easiest to integrate into all 3 >>> platforms, since the dirty work has already been done. If that's too >>> many frame copies for video, we can write a function that can create, >>> say, an SkBitmap* pointing at the destination bits given a >>> GraphicsContext and a rectangle. >>> >>> Would either of those approaches work? >> >> They both sound workable, and might be the best option at this point. > > We'll ping WebKit to find out the reasoning behind passing in a > GraphicsContext. Probably for performance reasons and reducing extra > blits/copies, but still worth investigating. For some background > information... each platform implementation of MediaPlayerPrivate either > stores video frames on a platform-dependent surface (cairo_surface_t, > SkBitmap) or uses a platform-dependent context (HDC, NSGraphicsContext) to > interact with an external library (QTKit on mac, QuickTime on Windows). > > I'm a bit confused at how the SkBitmap* creation would work (mostly how to > deal with scaled elements, but I'm no Skia expert). The RGBA32Buffer sounds > like a pretty reasonable first attempt. Upstreaming our media glue code > might clean up some things as well. Any transforms will be lost when you do this, of course. But the only cross-platform way of representing that with the surface is through a GraphicsContext object. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Passing PlatformGraphicsContext from WebKit to Chrome code
On Wed, May 6, 2009 at 8:40 AM, Andrew Scherkus wrote: > WebKit's MediaPlayerPrivate interface is a bit backwards where they pass in > a GraphicsContext: > http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/WebKit/WebCore/platform/graphics/MediaPlayer.h?view=markup > We currently forward the MediaPlayerPrivate::paint(GraphicsContext* p, const > IntRect& r) call into Chrome, converting the GraphicsContext to > a PlatformContextSkia in the process. We realized today this doesn't work > on Mac since it's actually a CGContext. > Without resorting to #ifdefs everywhere, what's the best way to pass > a PlatformGraphicsContext back to Chrome? Can you just pass a pointer to the pixels and the size? I think the pixel format should be well-defined on each platform, and it should be easy to make a SkBitmap in the Chrome side that uses those pixels directly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Why are pref keys wchar_t's?
2009/5/1 Mohamed Mansour : > Why wouldn't we just use std::string ? Many places in the code uses > std::string. DictionaryValue needs to be converted as well as many others. > So what do we finally decide, go what Pink stated and use char* or use > std::string. I believe the reason is that you pass predefined constants to the pref functions. The constants are either char or wchar_t, we don't allow global objects like std::string. The caller never has to deal with these parameters, just pass the correct constant, so using string objects doesn't help anything. If we changed to std::string objects, it would require constructing a string object and making a copy through a heap allocation, so it's wasteful for no benefit to use std::strings here. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: unforking: 20% perf hit for international page cycler expected soon
On Sat, May 2, 2009 at 6:09 AM, Evan Martin wrote: > > The suggestions on that code review are good: we ought to measure how > many fonts normal users see, and then pick the cache tuning parameter > accordingly. > > Adam Barth is a good person to ask about how to do this, since he > seems to be measuring all sorts of things. I think the correct answer is # of fonts used per some unit of time. The total number of fonts will monotonically increase over time. Instead, we want to know how many fonts we should keep in the cache, which is temporal. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Suggestion for crossplatform ProcessSingleton and ChromeBrowserProcessId()
On Mon, Apr 27, 2009 at 8:05 AM, Mike Pinkerton wrote: > > On Sun, Apr 26, 2009 at 5:50 PM, Amanda Walker wrote: >> Application startup is one of the areas where we count every >> millisecond, and try to touch the disk as little as possible. I don't >> think it's safe to assume that the cost of creating and writing to a >> file is negligible in this context without actually measuring it. > > Just curious, how many files are read/written loading a profile: > history, bookmarks, cache, last session, preferences, cookies, etc? I > imagine it's non-trivial and happens at every startup. Cache is loaded synchronously on the I/O thread, along with the cookies. The history is loaded asynchronously on the history thread. The bookmarks are loaded asynchronously on the file thread and passed to the UI thread. The only things loaded synchronously are the ones we have to have to continue, which are the preferences and, when "open the last session" is set in the preferences, the session file. > I agree that the proposal just for the sake of consolidating code may > not be warranted, but to jump all over it because a file has to be > written seems like premature optimization in light of everything else > that happens on the disk at app startup. We start up significantly faster than any other browsers because we worry about this stuff. When the disk is thrashing (like right after you start your computer) there will be an even larger difference. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: DO NOT ADD DEPENDENCIES FROM CHROME/VIEWS on CHROME/COMMON
On Fri, Apr 24, 2009 at 10:10 PM, Aaron Boodman wrote: > > Is it possible to enforce these rules with code rather than capital letters? > > I don't think I've made this particular error, but it's something I > could see myself doing. From their names, "chrome/common" seems like a > reasonable thing to include from "chrome/views". > > Just a thought. Don't we have something already to enforce dependency > rules like this? The problem is that there are already some dependencies, so we can't enforce them. The dependencies are checked on a per-directory basis. I would like to prevent people from including browser from renderer_host and tab_contents but can't for the same reason. We could have some complicated exception list in the checkdeps tool, but that's much harder than shouting on the mailing list. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] WebContents is dead, long live TabContents!
I just moved the remaining methods from WebContents to TabContents. I kept the methods and data members the same, just merged the classes, so it should be easy to find what you're looking for (or to resolve conflicts if you have local changes to web_contents.cc). Hopefully this will make the complexity in this area much more manageable. We still have a shell class called WebContents (derived from TabContents) and references to it, which are temporary so I don't have to immediately change all references to it. It will hopefully soon go away. FAQ: Why did we do this? Chromium 1 used a variety of specialized tab contents types which we wrote native interfaces for. This included the history and downloads page. TabContents was the base class providing shared functionality and an external API, and there were a variety of subclasses for the different tab types. WebContents was the TabContents specialization for web pages. There were several problems with this. The original idea is that our native UI would be more awesome than a web page could ever be. But it turned out to be teh suck because a variety of things didn't work (find in page, printing, selection) and because we didn't end up doing anything fancy in there anyway. With native UI, we would have to write it again for every platform, which nobody was excited about doing. There were also very difficult bugs associated with switching tab contents types. For example, in Chromium 1, if you go to the history page, navigate to a regular web page, go back, then navigate to a different regular web page, you would see a flash of the first web page during the second transition. This was the tab contents types being switched between a HistoryContents and a previously-used WebContents. So now we only display web pages inside tabs. This makes the switching problem go away. Glen rewrote history and downloads we be special web pages with additional permissions, and I did a whole heckuva lof of refactoring to delete all the old TabContents switching. We still swap RenderViewHosts inside the TabContents when we need to switch processes. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: question on profiles & ChromeThread
On Mon, Apr 13, 2009 at 11:01 AM, Tim Steele wrote: > > I don't know of a reason we need more than 1 history thread, but I can't say > for sure. > HistoryService is responsible today for starting/stopping/destroying the > history thread, so if we have multiple services then we need to be smarter > about that... Anyone opposed to moving history_thread to BrowserProcess and > mimic what is done for the other threads? HistoryService::Cleanup does > some fancy footwork and ultimately joins on it's thread, but afaict it > doesn't need to [join]. I can think of other options but they feel much > less cool, like saying that the default profile's history service manges the > history thread, or having a refcountable HistoryThread type, ... We need the UI thread to Join with the history thread to ensure that all the data is written. If it doesn't join, the history thread will be force-terminated when the UI thread exits. However, the BrowserProcess destructor should do this join for you when it deletes the thread. I don't think there's any reason other than completeness that the history thread needs a name, so just removing that is the easiest thing. As you can see, history shutdown is tricky. But I don't have an objection if you want to move it to BrowserProcess, either, as long as you fix any problems that arise :) Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] GTK and multi-threading
On Fri, Apr 10, 2009 at 12:42 PM, Evan Stade wrote:
> a) wrap the clipboard calls in gtk_threads_{enter,leave}(). This makes
> the calls thread safe, but it does so by locking a process-wide mutex,
> which will block our UI thread's main loop.
I personally think this is OK. These calls "should" be on the UI
thread and we'd put them there if we could. So having them on another
thread blocking the UI thread seems equivalent. We just need to be
careful to limit the locking to just that.
Brett
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [Extensions] New API specs: bookmarks, history, downloads
On Wed, Apr 8, 2009 at 7:48 PM, Nick Baum wrote: > Hi all, > > I fleshed out a few more APIs. I've put them in separate documents since the > API pattern doc was getting a bit long. Below are some notes, feedback > appreciated. > > In particular, I'd love feedback from Scott on history and from Paul on > downloads. > > -Nick > > Bookmarks > > Do we want to distinguish removeBookmark from removeFolder, or is that > unnecessary? > Should changes to the contents of a folder trigger eventbookmarkupdated for > that folder? How about the folders above it? > In BookmarkItem, should fields that don't apply be null or simply not > present? > In BookmarksQuery, do the root and bookmarksBar booleans make sense? > How does returning the children recursively work with updates? Can you > update all these items at the same time? > > Downloads > > Should getDownloads take a DownloadsQuery object? The current downloads page > includes search. > What kind of events does clearAllDownloads trigger? do we need a separate > event for this? Do we even need this in the first place? > How should we deal with progress updates? It seems like overkill to trigger > an event for each change in percentage, but on the other hand extensions > should be able to track this. > > History > > I'm assuming HistoryItems are immutable, so there is no update. > The internal history structure is split between visits and urls. Visits > don't contain the actual url, so we have to fetch the url object either way. > I therefore merged the visit and url objects into one. Is this reasonable? > There are a number of stats (timeSpent, fromId, totalVisitCount, > totalTypedCount). Do we want to expose those for v1? I would recommend doing as little as possible for history. I worked on a fancy querying system for Firefox history which has not really been used for great effect. We should add features as necessary for things we want to enable. The visits and URLs are split out for space reasons. The URL record has a couple of strings and a bunch of numbers, and the results will contain many copies of the URL (for example, imagine the URL, favicon URL, and title (many common titles are actually quite long) for your homepage being duplicated hundreds of times for a longish history query. If the results are limited to 100, space doesn't matter, but splitting them makes some things easier. Say I want to display only URLs, it keeps me from having to go through every one and uniquing them. So I guess either way is OK with me. I like the idea of limiting the result set to 100. It's too easy to shoot yourself in the foot. I also think you should not be able to do a query over too much time. For full text search results, we've spent a lot of time doing these in chunks. Doing a search for something over all time can easily churn through hundreds of megabytes of data. Our history code does it incrementally by month, so I think this would be a good thing to "encourage" in the API design that you can't do a query over more than one month. int timeSpent: we don't know the time you spent on the page, so remove this. optional int[] ids: I don't understand what this is. int totalPages: I assume you mean the total number of result sets of 100? This number is not possible for us to compute for queries with full text searches, and is merely very impractical for other ones. optional int page: We can not efficiently do full text queries by count "give me the 30-40th results" since it must find every match for the text before it can do any such computation. Given my suggestion to keep it simple, I think the query API should more closely reflect the current C++ API, which was carefully designed to be efficient. Instead of asking for individual pages, you do a query over a time range for "up to 100 results". If you want more results, you start at the last date and continue to go back in time, getting more results. This requires some more work by extension authors, but not a lot more. If we see there are many applications with certain needs, we should design better APIs for those specific needs. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to fix check deps failure?
On Mon, Mar 30, 2009 at 10:12 AM, Jian Li wrote: > I got another failure for checkdeps: > ERROR in > C:/b/slave/chromium-rel-builder/build/src\chrome\test\worker\test_webworker.cc > Illegal include: "webkit/tools/test_shell/test_webworker_helper.h" > Because of "-webkit" from chrome's include_rules. > Should I relocate test_worker project from chrome\test\worker to > webkit\tools\test_worker? Thanks. We already have webkit/tools/test (it just has the reference build in it). How about putting it there? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: How to fix check deps failure?
On Sun, Mar 29, 2009 at 8:44 PM, Jian Li wrote: > I got the following check deps failure with try job in Linux: > ERROR in > /b/slave/linux/build/src/webkit/tools/test_shell/test_webworker_helper.h > Illegal include: "chrome/test/worker/test_worker_main.h" > Because of no rule applying > Anyone knows how to fix this? Thanks. The "fix" is to not include that file. You can't have webkit depend on chrome, which is what the checkdeps program is verifying. The dependencies must go only from Chrome to WebKit. I hope it's easy for you to fix. Let me know if you have any questions. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Sandbox Interception Design
On Fri, Mar 27, 2009 at 1:50 PM, Book'em Dano wrote: > > At the top of sandbox\src\interception.h, it refers the reader to: > http://wiki/Main/ChromeSandboxInterceptionDesign. Does anyone know > where this document can be found? > > The sandbox info on > http://dev.chromium.org/developers/design-documents/sandbox > is too high level...I want to find out more details about the > interception framework and design. The internal doc is the same as the external one you found, so there probably isn't one more detailed (but I don't know for sure). Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 11:37 AM, Aaron Boodman wrote: > On Thu, Mar 26, 2009 at 11:22 AM, Brett Wilson wrote: >> Those are exposed, but I wonder which cases an extension needs to >> refer to them. They are internal IDs generated by sqlite. If you clear >> your history, you'll get re-used ones. This could also theoretically >> possible happen if you delete a single item, but I don't know if this >> happens in practice. So they are often persistent, but the way you ask >> makes me nervous. > > I'm thinking of a use case where somebody wanted to synchronize > browser history between machines. It would be more convenient to do > this if there was a unique client side ID that didn't change for each > visit. I'm OK exposing this as long as we set expectations correctly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 10:09 AM, Aaron Boodman wrote: > > On Thu, Mar 26, 2009 at 9:52 AM, Brett Wilson wrote: >> What would IDs refer to in history? > > I've only barely looked into the history data model, but I was hoping > it would be a persistent ID for each visit, which is unique across the > profile. It appears that there is such an ID in the visit table. Could > I use that? Those are exposed, but I wonder which cases an extension needs to refer to them. They are internal IDs generated by sqlite. If you clear your history, you'll get re-used ones. This could also theoretically possible happen if you delete a single item, but I don't know if this happens in practice. So they are often persistent, but the way you ask makes me nervous. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Should all automatable browser APIs have per-object unique IDs?
On Thu, Mar 26, 2009 at 9:41 AM, Aaron Boodman wrote: > I'm starting to dig into implementing the tab and window API as a > first example of all the other browser-automation type APIs we > eventually want to implement for extensions. > > One of my early assumptions was that the APIs we exposed would be > service-style, where we pass dumb json data structures back and forth > between the extension process and the browser process. As such, it > seems intuitive that each object must have a unique identifier. For > example, each tab should have a tab ID and each window should have a > window ID. (For more detail, see here: > http://dev.chromium.org/developers/design-documents/extensions/api-pattern) > > The automation system already maintains such a list of IDs for tabs, > browsers, and windows for a similar reason. But they are maintained in > the automation class hierarchy and not particularly useful to me. > > I was wondering what people thought of the idea of changing these > objects to have built-in IDs for automation purposes. So, for example, > each Browser would have an ID, and there'd be a map of ID to instance > maintained in BrowserList. Clients (the automation system and the > extension system) then wouldn't have to maintain their own mappings, > but could call BrowserList::GetBrowserById(), or something. Same with > Tabs, Downloads, Bookmarks*, and History*. What would IDs refer to in history? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: ScrollBar Implementation
As Peter said, the ScrollBar object is not responsible for drawing scroll bars on pages, which is what the bug is about. Brett On Wed, Mar 25, 2009 at 1:15 PM, Mohamed Mansour wrote: > > There is no context menu for the ScrollBar. > > -m0 > > > > On Wed, Mar 25, 2009 at 3:55 PM, Ben Goodger (Google) > wrote: >> No. >> >> What's not working? >> >> -Ben >> >> On Wed, Mar 25, 2009 at 12:54 PM, Mohamed Mansour >> wrote: >>> Do you recommend me to refactor the Context Menu code from >>> BitmapScrollBar into ScrollBar so that both will have context menu >>> implementations? >>> >>> Currently, the context menu is the page context menu that has "reload, >>> print, view page info, etc". Would that be the best approach fixing >>> this "feature" bug. >>> http://code.google.com/p/chromium/issues/detail?id=7231 >>> >>> -m0 >>> >>> >>> On Wed, Mar 25, 2009 at 3:49 PM, Ben Goodger (Google) >>> wrote: There are different kinds of scrollbar supported by views... that native scrollbar and the bitmap scrollbar. bitmap scrollbar isn't used right now but likely will be again. ScrollBar is the base class of both NativeScrollbar and Bitmapscrollbar. Scrollview has a ScrollBar* so it doesn't have to care about the particular implementation. -Ben On Tue, Mar 24, 2009 at 6:36 PM, Mohamed Mansour wrote: > Hi chromium, > > I cc'd Ben cause he seems to be working on UI on chrome alot :x Sorry > Ben! I am working on a "feature" > http://code.google.com/p/chromium/issues/detail?id=7231 which requires > context menu support for Chromium scroll bars. While searching the > code I have come up with these classes: > > - NativeScrollBar > - ScrollBar > - ScrollView > - BitmapScrollBar > > The context menu functionality should have the following (system wide > in windows, every window that has scrollbar, has that context menu) > > Horizontal: > 1) Scroll Here > 2) Left Edge > 3) Right Edge > 4) Page Left > 5) Page Right > 6) Scroll Left > 7) Scroll Right > > Vertical: > 1) Scroll Here > 2) Top > 3) Bottom > 4) Page Up > 5) Page Down > 6) Scroll Up > 7) Scroll Down > > > So my question is as follows, Chromium uses ScrollView as its main > scroll bar. It doesn't use NativeScrollBar, nor BitmapScrollBar. So > why do those exist? Why do we have a ScrollBar class? Why can't we > just use ScrollView and instead of passing in a ScrollBar, are we > assuming Chromium will have *many* different types of scrollbars? > > Why are we not using native windows scrollbar support, since chromium > is creating different views in every operating system, why not just > use the standard windows components? > > There are many functionality within the scrollbar, how would you guys > advice me to continue? Should I create a separate class called > ScrollBarContextMenu and implement the horizontal and vertical context > menu for scroll bars? > > There must be an easier way, to just use windows/gtk/mac controls for > scrollbar support, instead of recreating it from scratch. > > Ideas? > >>> >> > > > > --~--~-~--~~~---~--~~ 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: Including Droid font in Chrome?
On Wed, Mar 25, 2009 at 10:16 AM, Alex Russell wrote: > > MSFT did a new set of fonts to take specific advantage of ClearType: > > http://www.microsoft.com/typography/ClearTypeFonts.mspx > > The "Core Fonts" are still available and installed by default on all > windows versions that I can find information on, but they were > designed for a simpler time when sub-pixel hinting was still rare. I'm > not sure that implies that we should do anything in particular WRT > Droid, though. I have them on my Windows box. They are nice fonts, but I think they are optimized for the antialiasing algorithm on Andorid: I don't find that they look quite as good on Windows using ClearType. For a while, I was interested in including their fallback font which we could use to guarantee that glyphs are available for most characters. But (I assume) for space reasons on the phone, this font is not hinted, so looks pretty ugly. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Omnibox q around Mac+Chromium best-practices.
I would do the thin Objective C mode, partially since all Chrome developers know C++. I could debug that code or make changes to it if I was doing something that affected it, but I would have a much harder time with Objective-C. Brett On Thu, Mar 19, 2009 at 4:00 PM, Scott Hess wrote: > > I'm refactoring my Omnibox code towards something I'm willing to put > up for review, and am realizing that I need to find a way to rule on > whether I should have thick Objective-C helpers or thin ones. Say for > instance that I have an NSTableView, I'll need a data source for that, > which needs to be an Objective-C object. At the thin extreme, I can > put the minimum amount of code in that object to fulfill the data > source protocol, plus anything I need for handling delegation or > target/action type things, which leaves setup and wiring in the C++ > code. At the thick extreme I would push most of the Objective-C code > into the Objective-C object, and have the C++ code call into that. Or > there's something in the middle. > > WDYT? > > Right now it's somewhere in the middle. I don't create Objective-C > methods solely to be called from C++, nor C++ methods solely to be > called from Objective-C, except for cases where either would need to > poke through the encapsulation boundary. > > Thanks, > scott > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Trying to link to code in chrome from webkit/glue ?
On Tue, Mar 17, 2009 at 7:27 PM, Rafael Weinstein wrote: > I've created a class (SecurityOriginWhitelist) in webkit/glue that > implements a delegate interface that I created in WebKit/WebCore > (SecurityOriginWhitelistDelegate). > I'd like to use URLPattern, which lives in chrome/extensions, in > implementing the concrete class, but I'm getting a link error. > Now I notice that nothing in webkit/glue seems to include chrome/*. Is there > some other way to do this, or would the code I need have to move to base/*? You definitely can't do this. check_deps will turn the tree red if you do. Let's talk tomorrow about this Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: rev 11763 removes frame pointer from ResourceRequest
On Mon, Mar 16, 2009 at 4:25 PM, Marshall Greenblatt wrote: > My needs in this case are related to the Chromium Embedded Framework (CEF). > The code currently works as follows: > > 1. Retrieve our custom WebViewDelegate instance pointer via the WebFrame > pointer passed to ResourceLoaderBridge::Create(). > 2. Pass a CefBrowser pointer retrieved from our custom WebViewDelegate > instance into the new ResourceLoaderBridgeImpl. > 3. During the execution of RequestProxy::AsyncStart() access callbacks > provided by CefHandler (retrieved from CefBrowser) to optionally provide > alternate data streams, transparently redirect requests, etc. > > You can view the source code here: > > http://code.google.com/p/chromiumembedded/source/browse/trunk/libcef/browser_resource_loader_bridge.cc > > Does chromium currently maintain the relationship between the 'routing_id' > parameter and the WebFrame pointer somewhere within the code base, or will > we need to add this mapping capability ourselves? Or is there perhaps a > completely different approach that CEF should be using to provide this > capability? Routing IDs and frames are different things. If I recall correctly, there can be many frames on a page that would share the same routing ID, or in the case that John mentioned, there can be routing IDs but no frame. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Doing some research with views and GTK.
On Sun, Mar 15, 2009 at 10:09 AM, Adam Langley wrote: > On Sun, Mar 15, 2009 at 8:55 AM, Dean McNamee wrote: >> UI elements like buttons are different, my understanding is that (at >> least in theory) it should be possible for all of those images of the >> different states to live on the X server, so they don't need to be >> sent over the network for every expose. I'm not sure how we would do >> this with a Skia based drawing pipeline. > > Although a displaylist like interface would be very nice, it's > basically not going to happen. > > However, I wouldn't worry about drawing the UI elements as a bitmap > too much. Firstly, the number of pixels isn't that large. The > TabStrip, Omnibox, buttons etc probably take up < 5% of the screen, This is a good point. It probably doesn't matter what we do with the tabstrip and toolbar when the page is rendered to a giant DIB. While I would like to do a displaylist-like painting for the page, I don't see this happening in a way that can be reasonably remotable on X. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Doing some research with views and GTK.
On Sun, Mar 15, 2009 at 7:37 AM, Dean McNamee wrote: > > I had a discussion about Views with Scott. I think I am on the side > of the fence that porting views it not a good idea. One of the things > that came up is remote X, would it be possible to ever have good > remote X performance with the Views panting model? I wouldn't want to > paint ourselves into a corner (dum dum dum). It was my understanding we were already using Skia for a lot of this drawing, so the existing approach wasn't going to make remote X too happy either. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: SVG tests and sanity
On Fri, Mar 13, 2009 at 11:25 AM, Dimitri Glazkov wrote: > > Team, > > We have many brains working the layout test puzzle. And that's a good > thing. We've got this Rubik's cube nearly all finished. However, it > somewhat pains me seeing lots of engineers spending countless hours > trying to fix the SVG tests. Perhaps we shouldn't be doing that? I > mean, based on my experience, SVG accounts for a tiny fraction of the > Web and very (very!) few pages will be broken even if we completely > ignore SVG. > > IMHO, a better approach will be deferring these tests and trying to > tackle them later as a smaller, more focused effort. Identify the > experts in drawing and SVG markup, WebKit implementation, and let them > fix it. > > WDYT? I agree we should stop working on SVG tests. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 10:11 AM, Amanda Walker wrote: > On Wed, Mar 11, 2009 at 2:07 PM, Brett Wilson wrote: >> Do you mean when you click on the menu, blocking the browser until the >> renderer responds with whether the menus can be enabled? I would be >> opposed to that. > > So are we, but that's what WebKit currently assumes. That's why we've > been trying to brainstorm a way around it. This seems like it is not worth worrying about until the mac browser is as good as the Windows one. We have this "bug" on Windows, and it's not held anything up so far. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Wed, Mar 11, 2009 at 10:01 AM, Avi Drissman wrote: > Most platforms (meaning not Chrome) have the ability, when the user pulls > down a menu, to adjust the states of the menu items within. For them, when > the user selects the Edit menu, they're OK calling into WebCore and asking > the Editor canCopy(), canPaste(), etc. Do you mean when you click on the menu, blocking the browser until the renderer responds with whether the menus can be enabled? I would be opposed to that. > We're pretty much the only ones decoupling the UI from WebCore to the extent > that we disallow blocking. With that design, we're forced to have WebCore > (or at least glue/) bubble up state changes. Compared to just asking WebCore > at the time of need, having state change notifications is more inefficient. > I think it's worth paying the price. But it might be a harder sell to > upstream. State changes won't fix the problem either. There is no way in the browser to know about the current state of the renderer without one or the other one blocking. State change notifications don't address this problem. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Thoughts on copy/paste
On Tue, Mar 10, 2009 at 7:44 AM, Avi Drissman wrote: > I actually don't know. It seems like just simple state gathering but it > might be more. > > The big concern is that it fits our model but no one else's. Everyone else > is OK with the UI asking the renderer questions directly, and as that's more > efficient than doing status updates that are going to be ignored 99.44% of > the time, I'm not sure they have incentive. I'm not sure what you mean by this. What is everyone OK with? Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
