[chromium-dev] Re: Compile base_unittests fails
On Sun, Jul 12, 2009 at 10:18 PM, Evan Martine...@chromium.org wrote: On Sun, Jul 12, 2009 at 8:38 PM, empriserxueyunl...@gmail.com wrote: third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan (dmg_fp::U*, const char**)': third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type 'char' The line in question is: if (!hexdig['0']) So yes, the warning is correct. What compiler are you using? I am curious why this hasn't affected us already. I guess it's suspicious to subscript an array with a character constant because if chars are signed they can go negative. In this case it's obvious that the character involved is positive regardless of the type of chars, so perhaps that's why other compilers don't complain. We could use something like -Wno-char-subscripts for this code or maybe a cast in the array subscript but perhaps it'd be simpler to just turn off warnings for third-party code. --~--~-~--~~~---~--~~ 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: Compile base_unittests fails
Hi I thought none of the hex stuff was supposed be compiled. Line 183 does #define NO_HEX_FP but there is some interesting interaction between INFNAN_CHECK, No_Hex_NaN and Need_Hexdig which might result in it compiling for you. Hmmm Try adding #define No_Hex_Nan after #define NO_HEX_FP perhaps? --Craig On Mon, Jul 13, 2009 at 7:18 AM, Evan Martine...@chromium.org wrote: On Sun, Jul 12, 2009 at 8:38 PM, empriserxueyunl...@gmail.com wrote: third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan (dmg_fp::U*, const char**)': third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type 'char' The line in question is: if (!hexdig['0']) So yes, the warning is correct. What compiler are you using? I am curious why this hasn't affected us already. It looks like we've already patched around some warnings in this code, so maybe we need to do more of that. http://src.chromium.org/viewvc/chrome/trunk/src/base/third_party/dmg_fp/README.chromium (BTW, I also looked into whether our copy of this file is old, but we match the newest version linked from the author's home page.) --~--~-~--~~~---~--~~ 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: Compile base_unittests fails
On Mon, Jul 13, 2009 at 8:34 AM, Craig Schlentercraig.schlen...@gmail.com wrote: Hi I thought none of the hex stuff was supposed be compiled. Line 183 does #define NO_HEX_FP but there is some interesting interaction between INFNAN_CHECK, No_Hex_NaN and Need_Hexdig which might result in it compiling for you. Hmmm Try adding #define No_Hex_Nan Whoops, wrong case .. that should be #define No_Hex_NaN --Craig after #define NO_HEX_FP perhaps? --Craig On Mon, Jul 13, 2009 at 7:18 AM, Evan Martine...@chromium.org wrote: On Sun, Jul 12, 2009 at 8:38 PM, empriserxueyunl...@gmail.com wrote: third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan (dmg_fp::U*, const char**)': third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type 'char' The line in question is: if (!hexdig['0']) So yes, the warning is correct. What compiler are you using? I am curious why this hasn't affected us already. It looks like we've already patched around some warnings in this code, so maybe we need to do more of that. http://src.chromium.org/viewvc/chrome/trunk/src/base/third_party/dmg_fp/README.chromium (BTW, I also looked into whether our copy of this file is old, but we match the newest version linked from the author's home page.) --~--~-~--~~~---~--~~ 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: changing chrome_exe to chrome, converting chrome.exe to gyp
There are a certainly performance bugaboos at the moment (I've been keeping your email in my inbox as a reminder :-) )One thing just jumped out at me though, the environment variable we're checking for cores on windows in NUMBER_OF_PROCESSORS, not NUM_CPUS (at least for the makefile step in webcore). -BradN On Fri, Jul 3, 2009 at 6:38 AM, Dean McNamee de...@chromium.org wrote: Hey Bradley, Thanks, I can build again from the command line. My CPU utilization is still annoying low. I made sure and NUM_CPUS is 4. Compare this to the Linux make build, which keeps my 4 cores at 100% cpu all the way through. Thanks -- dean On Sun, Jun 28, 2009 at 2:06 AM, Bradley Nelsonbradnel...@google.com wrote: Hi Dean, So I've dropped in a change that switches directories to have name like: (base) (test_shell) This will allow you to run things at the command line again. I don't find this choice particularly ascetic myself. But the options where limited, because the following characters cannot appear in solution folder names: / ? : \ *| # % Let me know if you run into any more problems with this. Also definitely let me know if someone thinks of something less ugly. -BradN On Fri, Jun 19, 2009 at 3:10 AM, Dean McNamee de...@chromium.org wrote: This also broke building from the command line. I usually never open Visual Studio as an IDE. I build on the command line with something like: devenv chrome\\chrome.sln /Build release /Project test_shell It looks like project names like test_shell now have complicated names like test_shell (webkit\tools\test_shell\test_shell), and I haven't been able to manage supplying those on the command line. Is there a way we can get back our nice project names test_shell, chrome, etc? On Fri, Jun 19, 2009 at 1:30 AM, Andrew Scherkusscher...@chromium.org wrote: Here's a quick example: 1) Delete whole Debug directory 2) gclient runhooks --force 3) Set test_shell as startup project 4) Hit F5 Sample output of things that shouldn't be dependencies (mostly because they're other executables) sandbox (sandbox\sandbox) - Debug Win32 chrome_dll - Debug Win32 net_perftests - Debug Win32 base_unittests - Debug Win32 net_unittests - Debug Win32 v8_shell - Debug Win32 mini_installer - Debug Win32 test_support_unit - Debug Win32 test_support_ui - Debug Win32 codesighs (third_party\codesighs\codesighs) - Debug Win32 automated_ui_tests - Debug Win32 memory_test - Debug Win32 activex_test_control - Debug Win32 On Thu, Jun 18, 2009 at 4:08 PM, Bradley Nelson bradnel...@google.com wrote: Andrew, can you give an example of something that built that shouldn't have for test_shell? Maybe we have some overspecified dependencies as well. -BradN On Thu, Jun 18, 2009 at 3:49 PM, Andrew Scherkus scher...@chromium.org wrote: I'll see if I can repro this again before filing a bug, but similar to what Daniel and John reported, when I right click on test_shell and say Build it builds the minimal set required to fully build+link test_shell.exe However when I set test_shell as the start-up project and launch the debugger, Visual Studio warns that every other project in chrome.sln must be built before running (not true!). Is there a difference in build vs. runtime dependencies? Andrew On Thu, Jun 18, 2009 at 3:25 PM, Steven Knight s...@chromium.org wrote: All-- When you notice missing dependencies, pleased add them to the necessary .gyp file(s)! One of the main reasons we've been trying to land all this stuff is so that tracking down all these pieces isn't single-threaded through one person (or two). If you're not comfortable making the change yourself, then please file a bug so the dependency problems get tracked and fixed in an organized fashion. Re: unnecessary rebuilds: please file bugs so they don't get lost. Please include the target you were building, and the the libs/targets that were rebuilt unnecessarily. You don't have to be exhaustive about the list, it's more important here that at least some information gets collected and doesn't languish on the ML or get dropped on the floor. I'm working on a buildbot script that will test for missing dependencies by building every target from scratch individually, and will then test for unnecessary rebuilds by rebuilding each target after no updates. That's been taking a back seat to just getting the conversion completed, but I've accelerated my work on it as we wind down to the last few targets. --SK On Thu, Jun 18, 2009 at 3:11 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Jun 18, 2009 at 3:10 PM, John Abd-El-Malek j...@chromium.org wrote:
[chromium-dev] Re: Compile base_unittests fails
Hi If your compiler is that old btw, then it may help to poke at the list below and see what else you need to update: http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites Hopefully all those warnings will go away with something a bit more modern ... --Craig On Mon, Jul 13, 2009 at 7:43 AM, lawrence suexueyunl...@gmail.com wrote: Thanks, my gcc version is out. I need update it. chrome[24-18:18:59]/home/chrome/src/basegcc --version gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. On Jul 13, 1:18 pm, Evan Martin e...@chromium.org wrote: On Sun, Jul 12, 2009 at 8:38 PM, empriserxueyunl...@gmail.com wrote: third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan (dmg_fp::U*, const char**)': third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type 'char' The line in question is: if (!hexdig['0']) So yes, the warning is correct. What compiler are you using? I am curious why this hasn't affected us already. It looks like we've already patched around some warnings in this code, so maybe we need to do more of that.http://src.chromium.org/viewvc/chrome/trunk/src/base/third_party/dmg_... (BTW, I also looked into whether our copy of this file is old, but we match the newest version linked from the author's home page.) --~--~-~--~~~---~--~~ 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: some questions about chrome's layout-test
hi, dave. I think you're right. I ran the layout-test, and got the same result as yours. I mean, I also got a lot of ERRORs as you described. And I think most of these ERRORs are expected. To your situation, the 9 unexpected + sum of expected = the sum of ERRORs you get in your DOS. 2009/7/9 David Jones ds...@163.com Ok, let me make question simple. I get some ERRORs on my DOS while running layout-test, such as : 090706 15:37:19 __init__.py:1032 ERROR LayoutTests/fast/backgrounds/svg-as-mask.html failed: Text diff mismatch Image mismatch These ERRORs are made of two kinds: expected and unexpected, the unexpected ERRORs will be counted as the final number in : 090706 15:44:24 __init__.py:1032 INFO Exit status: 9 right?? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] New path service constants
If you are adding new path service constants as part of a new feature (ie-adding new directories to the install footprint or a new data dir for storing things in), please make sure you include someone for each platform in the review and call out what the path is for. We've had a few paths added over time that on the Mac that were trying to write directly into the apps install tree, which is not something we can do. TVL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Improving power usage
Hello, I'm a Summer of Code student working with Dean. My interests are the Linux port, specifically ensuring Chromium behaves well on low spec machines. So far I've spent my 'summer' (it's winter here in Australia) on the ARM port of Chromium. As of the recent v8 gyp changes, the tree can build for ARM (and thumb, for a binary that's around ~25% smaller) and I've used it to browse on real hardware; the Beagleboard, an OMAP3 based ARM board with 128MB of RAM. I've been looking into what to work on next. I'd like to investigate the possibility of reducing the amount of work being done when running on battery. On my laptop I send SIGSTOP to Firefox when I'm not using it, to save battery without losing state. This saves me 1 Watt when running Gmail in Firefox 3, or around 8% of the system power draw on my Thinkpad X300. As we're multi process with Chrome we could instead suspend any background renderers, plugin and extension processes without affecting the foreground tabs. Some obvious gotchas - when tabs share renderers, we can't indiscriminately stop background tabs - we can't just sigstop the renderer process, as the browser will think it has crashed Other things to look at would be timers that fire 'too often', and pausing animated content such as gifs and flash. Wakeups are not too bad, but any savings will mean longer lasting batteries: 28.4% (187.4) firefox-3.5 : hrtimer_start_range_ns (hrtimer_wakeup) 4.1% ( 26.9)chrome : hrtimer_start_range_ns (hrtimer_wakeup) 2.3% ( 15.0)chrome : ep_poll (process_timeout) (Powertop output of Firefox 3 vs Chromium trunk, one tab running Gmail, on Ubuntu Karmic) Perhaps we could run a powertop bot, that monitors an idle session with a few tabs opened to catch any regressions with timers. I plan to spend some time looking into this. Feedback and suggestions would be appreciated. Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlowjor...@chromium.org 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 -~--~~~~--~~--~--~---
Fwd: [chromium-dev] Improving power usage
-- Forwarded message -- From: Ryosuke Niwa rn...@google.com Date: Mon, Jul 13, 2009 at 8:34 AM Subject: Re: [chromium-dev] Improving power usage To: j...@jms.id.au Hi, I think there was a recent discussion regarding performance, in which someone suggested to suspend inactive renderer processes. I think the problems pointed by others were that we need to have some threshold for suspending a process because users may switch between tabs frequently (e.g. comparing websites), and we also need to consider users who want to keep websites alive background (e.g. AJAX chat service). Ryosuke Niwa On Mon, Jul 13, 2009 at 8:19 AM, Joel Stanley j...@jms.id.au wrote: Hello, I'm a Summer of Code student working with Dean. My interests are the Linux port, specifically ensuring Chromium behaves well on low spec machines. So far I've spent my 'summer' (it's winter here in Australia) on the ARM port of Chromium. As of the recent v8 gyp changes, the tree can build for ARM (and thumb, for a binary that's around ~25% smaller) and I've used it to browse on real hardware; the Beagleboard, an OMAP3 based ARM board with 128MB of RAM. I've been looking into what to work on next. I'd like to investigate the possibility of reducing the amount of work being done when running on battery. On my laptop I send SIGSTOP to Firefox when I'm not using it, to save battery without losing state. This saves me 1 Watt when running Gmail in Firefox 3, or around 8% of the system power draw on my Thinkpad X300. As we're multi process with Chrome we could instead suspend any background renderers, plugin and extension processes without affecting the foreground tabs. Some obvious gotchas - when tabs share renderers, we can't indiscriminately stop background tabs - we can't just sigstop the renderer process, as the browser will think it has crashed Other things to look at would be timers that fire 'too often', and pausing animated content such as gifs and flash. Wakeups are not too bad, but any savings will mean longer lasting batteries: 28.4% (187.4) firefox-3.5 : hrtimer_start_range_ns (hrtimer_wakeup) 4.1% ( 26.9)chrome : hrtimer_start_range_ns (hrtimer_wakeup) 2.3% ( 15.0)chrome : ep_poll (process_timeout) (Powertop output of Firefox 3 vs Chromium trunk, one tab running Gmail, on Ubuntu Karmic) Perhaps we could run a powertop bot, that monitors an idle session with a few tabs opened to catch any regressions with timers. I plan to spend some time looking into this. Feedback and suggestions would be appreciated. Cheers, Joel --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson bre...@chromium.org wrote: On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlowjor...@chromium.org 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 --~--~-~--~~~---~--~~ 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: middle click on home
On Fri, Jun 26, 2009 at 8:22 PM, Peter Kastingpkast...@google.com wrote: Given that there are a large number of ways to open the home page in a new foreground tab (e.g. ctrl-t + click, shift-middle click, etc.), there are a very large number of other places in the UI where middle-click opens a new background tab (including other toolbar buttons), there are no places I can think of offhand where middle-click opens a new foreground tab, and this behavior matches other browsers, I'm opposed to changing this. On the other hand, other browsers open links in foreground tabs when you right-click on a link and select open in new tab, which we do not. This inconsistency drives me batty (since I generally navigate depth-first rather than breadth-first, and want a stack, not a queue. --Amanda --~--~-~--~~~---~--~~ 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: Improving power usage
On Mon, Jul 13, 2009 at 9:22 AM, Evan Martine...@chromium.org wrote:
As we're multi process with Chrome we could instead suspend any
background renderers, plugin and extension processes without affecting
the foreground tabs.
One piece to look at is the code that calls SetProcessBackgrounded(),
which on Windows marks the process as one that can be paged out but on
Linux is not implemented. I don't know how it decides it's ok to do
that, but it'd be good logic to examine.
Sorry, bad tip. Try looking at
void BrowserRenderProcessHost::SetBackgrounded(bool backgrounded) {
instead.
--~--~-~--~~~---~--~~
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: Improving power usage
On Mon, Jul 13, 2009 at 9:22 AM, Evan Martin e...@chromium.org wrote: I think it'd be pretty interesting to fully suspend background tabs, but doing it safely is likely tricky. For example, imagine a page that has Javascript that is driving a Flash plugin playing background music. For a common real-life example people want to work, imagine having Pandora open in a background tab. People expect it to keep playing music. Other things to look at would be timers that fire 'too often', and pausing animated content such as gifs and flash. Even for stuff like gifs that don't have audio, you could imagine a page with a very long animated gif, where I might switch away from the tab and expect it to be farther along when I come back. In fact GIFs do not animate when they're not visible (i.e. in background tabs), they simply check how much time has elapsed since their last paint when they become visible again, and spin the GIF forward as necessary to simulate having been animating the whole time. (This code went in last fall.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: middle click on home
On Mon, Jul 13, 2009 at 9:21 AM, Amanda Walker ama...@chromium.org wrote: --Amanda (who still prefers foreground tabs, but will just resort to open in new window instead) Shift-middle or shift-control click. (All browsers I've tested support this.) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: middle click on home
Actually, I take that back. I could swear they did, but I am evidently wrong (after just checking a few). Never mind :-). I believe some used to - the context menu entry was going to be our foreground-opening UI, but lots of people use it and expect background-opening. --~--~-~--~~~---~--~~ 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: middle click on home
On Mon, Jul 13, 2009 at 9:55 AM, Glen Murphyg...@chromium.org wrote: Actually, I take that back. I could swear they did, but I am evidently wrong (after just checking a few). Never mind :-). I believe some used to - the context menu entry was going to be our foreground-opening UI, but lots of people use it and expect background-opening. We could measure this: see how frequently people immediately switch to a tab after opening it in the background. --~--~-~--~~~---~--~~ 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 8:59 AM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson bre...@chromium.org wrote: On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlowjor...@chromium.org 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. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Mon, Jul 13, 2009 at 10:05 AM, Jeremy Orlowjor...@chromium.org wrote: On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson bre...@chromium.org wrote: On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlowjor...@chromium.org 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: Improving power usage
On Mon, Jul 13, 2009 at 10:05 AM, Scott Hess sh...@chromium.org wrote: On Mon, Jul 13, 2009 at 9:37 AM, Peter Kastingpkast...@chromium.org wrote: For a common real-life example people want to work, imagine having Pandora open in a background tab. People expect it to keep playing music. Is it using Flash to play the music? Yes, Pandora uses Flash. Note that even if you don't suspend the Flash process, you have to be careful since Flash may interact with script, and thus you (probably) can't safely suspend any renderers embedding Flash. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Mon, Jul 13, 2009 at 10:08 AM, Brett Wilson bre...@chromium.org wrote: On Mon, Jul 13, 2009 at 10:05 AM, Jeremy Orlowjor...@chromium.org wrote: On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 13, 2009 at 8:20 AM, Brett Wilson bre...@chromium.org wrote: On Fri, Jul 10, 2009 at 5:04 PM, Jeremy Orlowjor...@chromium.org 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. Can anyone think of a better name for it? --~--~-~--~~~---~--~~ 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:10 AM, Jeremy Orlowjor...@chromium.org wrote: On Mon, Jul 13, 2009 at 10:08 AM, Brett Wilson bre...@chromium.org wrote: Yes, I think NullableString16 is better than passing a separate bool. Can anyone think of a better name for it? What's wrong with NullableString16? Writing string code which assumes the input is non-NULL is a really common source of bugs. We shouldn't encourage people to pass null-capable fields unless the API really really does want actual null-capable fields. This isn't something you can address generally by encapsulating it in the wrapper, because the NULL has meaning (it IS a separate bool, regardless of how you dress it up). -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: Improving power usage
On Mon, Jul 13, 2009 at 6:22 PM, Evan Martine...@chromium.org wrote: [snip] One piece to look at is the code that calls SetProcessBackgrounded(), which on Windows marks the process as one that can be paged out but on Linux is not implemented. I don't know how it decides it's ok to do that, but it'd be good logic to examine. I've mentioned this to Joel off-list but in case anyone else is interested, I have code that runs background tabs at lower scheduling priorities on linux. Tweaks to /etc/security/limits.conf are necessary to make it work though (to grant priority raising abilities). --Craig --~--~-~--~~~---~--~~ 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
All right. NullableString16 it is. :-) And, in case it's not clear, this will only be for strings that have a valid null state. The common case should still be using string16. J On Mon, Jul 13, 2009 at 10:23 AM, Scott Hess sh...@chromium.org wrote: On Mon, Jul 13, 2009 at 10:10 AM, Jeremy Orlowjor...@chromium.org wrote: On Mon, Jul 13, 2009 at 10:08 AM, Brett Wilson bre...@chromium.org wrote: Yes, I think NullableString16 is better than passing a separate bool. Can anyone think of a better name for it? What's wrong with NullableString16? Writing string code which assumes the input is non-NULL is a really common source of bugs. We shouldn't encourage people to pass null-capable fields unless the API really really does want actual null-capable fields. This isn't something you can address generally by encapsulating it in the wrapper, because the NULL has meaning (it IS a separate bool, regardless of how you dress it up). -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] running layout_tests on vista and windows 7
Hi all, (If you don't ever care to run the webkit layout tests, you can skip this note). As most of you are no doubt aware, we currently can only run the webkit layout_tests on windows XP. For some of us who primarily develop on 64-bit Vista, this is inconvenient at best, and this is only going to get worse over time as more of migrate to 64-bit machines and (eventually) Windows 7. So, I'm working on porting the layout tests to Vista. This note is a writeup of the approach I'm thinking of taking, and I'm looking for feedback and suggestions, especially since most of you have been on this code base a lot longer than me. My basic approach is to try and get something up as quickly as possible as a proof of concept, and then work to try and reduce the maintenance over time. So, I've started by cloning the chromium-win port over to vista, and modifying the test scripts to be aware of the new set of test expectations. I will then tweak the tests to get roughly the same list of tests passing on Vista as on Windows. The main differences will have to do with how the theming renders scroll bars and a few other native controls. I have most of this now, and should have the rest of this in a day or two, but this is not a maintainable solution without a lot of manual overhead. Next, we'll get a buildbot setup to run on Vista. While we're doing this, I'll start working on reducing the test set duplication between XP and Vista. The best way to do this (we currently think) will be to modify test_shell to *not* draw the native controls, but rather stub them out in a platform-independent way for test purposes (e.g., just painting a grey box instead of a real scroll bar). Then we can write a few platform-specific unit tests to ensure that the widgets do work correctly, but the bulk of the tests will become (more) platform-independent. My hope is that we'll have something that I can demonstrate here in a week or two, and that it will extend trivially to Win 7. A stretch hope is that we can even get the rendering to be platform-independent enough that we may even be able to leverage them across the linux and mac ports. I don't know if this is realistic or not, as many of the tests may differ just due to font rendering and other minor differences. An alternative strategy is to start looking at more and more of the tests and making sure they are written to be as platform-independent as possible. First we'd this by making sure that we don't rely on pixel-based tests where text-based tests would do. Another option would be to switch to writing two tests just to ensure that page A renders the same way as page B (where A and B use two different sets of layout but should produce the same output). Both of these options are significantly more work up front, but will payoff in much less maintenance down the line. Also, all of this work will also overlap with the webkit test suites, so it'll need to be coordinated with our upstream buddies. Comments? Thoughts? -- Dirk --~--~-~--~~~---~--~~ 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 12:29 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Jul 13, 2009 at 12:20 PM, David Levin le...@google.com wrote: On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher da...@chromium.org wrote: 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. fwiw, I've checked in all the mechanics to do cheaply use StringImpl's across threads. You have to call a method (to be named) and then you'll get back a new StringImpl which uses the *same underlying buffer *and can be passed to another thread. (Right now, webkit code calls StringImpl::copy() for this purpose but that allocates a new buffer and copies the contents there. I can't modify that method due to the fact that it is currently a threadsafe call and that is relied on in some places in webkit.) Let me know if you want/need more details about it. Dave Would it be better to revisit allowing WebStrings to be transported across the IPC barrier (with this new code) or should we go the NullableString16 route? I'm now leaning towards the latter because the common case is that we _don't_ want to allow null strings. Also it will be similar to string16, so it should be more familiar to Chromium developers. Wrapping WebStrings might be a bit faster though, since it won't require an additional string copy from string16 to and from StringImpl. Hmm... I'd probably go with NullableString16. If we find the copy overhead to matter, then we could always optimize later. Another issue: Do we want to add conversion methods on WebString? My first reaction is to try to avoid it... -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: base::string16 / WebCore::String incompatibility
On Mon, Jul 13, 2009 at 12:54 PM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 13, 2009 at 12:29 PM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Jul 13, 2009 at 12:20 PM, David Levin le...@google.com wrote: On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher da...@chromium.orgwrote: 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. fwiw, I've checked in all the mechanics to do cheaply use StringImpl's across threads. You have to call a method (to be named) and then you'll get back a new StringImpl which uses the *same underlying buffer *and can be passed to another thread. (Right now, webkit code calls StringImpl::copy() for this purpose but that allocates a new buffer and copies the contents there. I can't modify that method due to the fact that it is currently a threadsafe call and that is relied on in some places in webkit.) Let me know if you want/need more details about it. Dave Would it be better to revisit allowing WebStrings to be transported across the IPC barrier (with this new code) or should we go the NullableString16 route? I'm now leaning towards the latter because the common case is that we _don't_ want to allow null strings. Also it will be similar to string16, so it should be more familiar to Chromium developers. Wrapping WebStrings might be a bit faster though, since it won't require an additional string copy from string16 to and from StringImpl. Hmm... I'd probably go with NullableString16. If we find the copy overhead to matter, then we could always optimize later. Another issue: Do we want to add conversion methods on WebString? My first reaction is to try to avoid it... Hm. I actually thought we should have implicit conversion methods like we do for string16. What's the problem with doing so besides a little bit of bloat? If we're not doing implicit conversion, I'm actually not sure if there's a point to adding NullableString16's since the code will be equally ugly as explicitly having a boolean. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: running layout_tests on vista and windows 7
Yup, I've already adopted that. Thanks! On Mon, Jul 13, 2009 at 12:55 PM, Thomas Van Lententhoma...@chromium.org wrote: Quick skimmed reply: Mac already has expectations per OS where we need them, so you might be able to follow that basic model (and maybe small tweaks to the scripts to use it). It looks for version specific and then falls back to generic platform files so we only have to dup the ones that are os version specific. TVL On Mon, Jul 13, 2009 at 3:50 PM, Dirk Pranke dpra...@google.com wrote: Hi all, (If you don't ever care to run the webkit layout tests, you can skip this note). As most of you are no doubt aware, we currently can only run the webkit layout_tests on windows XP. For some of us who primarily develop on 64-bit Vista, this is inconvenient at best, and this is only going to get worse over time as more of migrate to 64-bit machines and (eventually) Windows 7. So, I'm working on porting the layout tests to Vista. This note is a writeup of the approach I'm thinking of taking, and I'm looking for feedback and suggestions, especially since most of you have been on this code base a lot longer than me. My basic approach is to try and get something up as quickly as possible as a proof of concept, and then work to try and reduce the maintenance over time. So, I've started by cloning the chromium-win port over to vista, and modifying the test scripts to be aware of the new set of test expectations. I will then tweak the tests to get roughly the same list of tests passing on Vista as on Windows. The main differences will have to do with how the theming renders scroll bars and a few other native controls. I have most of this now, and should have the rest of this in a day or two, but this is not a maintainable solution without a lot of manual overhead. Next, we'll get a buildbot setup to run on Vista. While we're doing this, I'll start working on reducing the test set duplication between XP and Vista. The best way to do this (we currently think) will be to modify test_shell to *not* draw the native controls, but rather stub them out in a platform-independent way for test purposes (e.g., just painting a grey box instead of a real scroll bar). Then we can write a few platform-specific unit tests to ensure that the widgets do work correctly, but the bulk of the tests will become (more) platform-independent. My hope is that we'll have something that I can demonstrate here in a week or two, and that it will extend trivially to Win 7. A stretch hope is that we can even get the rendering to be platform-independent enough that we may even be able to leverage them across the linux and mac ports. I don't know if this is realistic or not, as many of the tests may differ just due to font rendering and other minor differences. An alternative strategy is to start looking at more and more of the tests and making sure they are written to be as platform-independent as possible. First we'd this by making sure that we don't rely on pixel-based tests where text-based tests would do. Another option would be to switch to writing two tests just to ensure that page A renders the same way as page B (where A and B use two different sets of layout but should produce the same output). Both of these options are significantly more work up front, but will payoff in much less maintenance down the line. Also, all of this work will also overlap with the webkit test suites, so it'll need to be coordinated with our upstream buddies. Comments? Thoughts? -- Dirk --~--~-~--~~~---~--~~ 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 layout_tests on vista and windows 7
On Mon, Jul 13, 2009 at 1:16 PM, Dirk Pranke dpra...@google.com wrote: Yup, I've already adopted that. Thanks! On Mon, Jul 13, 2009 at 12:55 PM, Thomas Van Lententhoma...@chromium.org wrote: Quick skimmed reply: Mac already has expectations per OS where we need them, so you might be able to follow that basic model (and maybe small tweaks to the scripts to use it). It looks for version specific and then falls back to generic platform files so we only have to dup the ones that are os version specific. TVL On Mon, Jul 13, 2009 at 3:50 PM, Dirk Pranke dpra...@google.com wrote: Hi all, (If you don't ever care to run the webkit layout tests, you can skip this note). As most of you are no doubt aware, we currently can only run the webkit layout_tests on windows XP. For some of us who primarily develop on 64-bit Vista, this is inconvenient at best, and this is only going to get worse over time as more of migrate to 64-bit machines and (eventually) Windows 7. So, I'm working on porting the layout tests to Vista. This note is a writeup of the approach I'm thinking of taking, and I'm looking for feedback and suggestions, especially since most of you have been on this code base a lot longer than me. My basic approach is to try and get something up as quickly as possible as a proof of concept, and then work to try and reduce the maintenance over time. So, I've started by cloning the chromium-win port over to vista, and modifying the test scripts to be aware of the new set of test expectations. I will then tweak the tests to get roughly the same list of tests passing on Vista as on Windows. The main differences will have to do with how the theming renders scroll bars and a few other native controls. I have most of this now, and should have the rest of this in a day or two, but this is not a maintainable solution without a lot of manual overhead. Next, we'll get a buildbot setup to run on Vista. While we're doing this, I'll start working on reducing the test set duplication between XP and Vista. The best way to do this (we currently think) will be to modify test_shell to *not* draw the native controls, but rather stub them out in a platform-independent way for test purposes (e.g., just painting a grey box instead of a real scroll bar). Then we can write a few platform-specific unit tests to ensure that the widgets do work correctly, but the bulk of the tests will become (more) platform-independent. My hope is that we'll have something that I can demonstrate here in a week or two, and that it will extend trivially to Win 7. A stretch hope is that we can even get the rendering to be platform-independent enough that we may even be able to leverage them across the linux and mac ports. I don't know if this is realistic or not, as many of the tests may differ just due to font rendering and other minor differences. An alternative strategy is to start looking at more and more of the tests and making sure they are written to be as platform-independent as possible. First we'd this by making sure that we don't rely on pixel-based tests where text-based tests would do. We started doing this for all of the editing tests, but got pushback from WebKit, because they were concerned that we may inadvertantly lose some of the subtle things that a pixel test can test that a text based test can't. I still think it is a good idea (less platform specific results to check out, tests run faster, etc), but just an FYI that you might hit some pushback in this area, so be sure to run it by webkit-dev before doing too much work. Another option would be to switch to writing two tests just to ensure that page A renders the same way as page B (where A and B use two different sets of layout but should produce the same output). Both of these options are significantly more work up front, but will payoff in much less maintenance down the line. Also, all of this work will also overlap with the webkit test suites, so it'll need to be coordinated with our upstream buddies. Comments? Thoughts? -- Dirk --~--~-~--~~~---~--~~ 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: Let's make build system history!
bump. On Wed, Feb 25, 2009 at 2:27 PM, Mark Mentovaim...@chromium.org wrote: Over the past month, some of us have been working on a not-so-well-kept secret project to create a build system system. Our goal is to have something Generate Your Projects (GYP) in a variety of formats, all from the same source. Today, we're ready to allow Mac developers to begin testing this experimental system. If you're on a Mac, I encourage you to try this out. From the src/build directory in a Chromium working copy, run: ../tools/gyp/gyp and in less than 10 seconds, a whole bunch of new Xcode projects will be generated for you. For the most part, they follow the same structure as the existing Xcode projects you're familiar with, so if you've been working with chrome.xcodeproj or test_shell.xcodeproj, you'll have no problem finding and using chrome_gyp.xcodeproj and test_shell_gyp.xcodeproj. Similarly, build results go into xcodebuild_gyp. The _gyp suffix is temporary, and keeps us from clobbering the old checked-in project files. Right now, Generating Your Projects is voluntary and manual. If a .gyp file changes because you've edited it or because of a sync, you'll need to re-run the above command to regenerate your project files. Before we go live, we'll add a hook to gclient to Generate Your Projects automatically when .gyp files change during a sync. I believe that the generated projects are now at parity with the old checked-in project files, but the .gyp files do suffer from becoming outdated pretty quickly. If you're adding or removing files from the tree, I'd appreciate it if you could help me out by making the appropriate modifications to our .gyp files. For the time being, please Cc me on all reviews involving a .gyp file. I think you'll all find that maintaining .gyp files is far easier than working with Xcode projects. We have some work-in-progress documentation available at http://code.google.com/p/gyp/w/list to help orient yourself. I'll be working more on the documentation in the days to come. We've also made significant progress on gyp-based Visual Studio, SCons, and Makefile generation, so those of you who aren't using Macs won't miss out for too long. Have fun! Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Minor proposed changes to page actions API
I'd like to close on some mumbling we've been doing about changes to the page actions API. What: * Make it not required to pre-specify this icon list in the manifest. This will require some refactoring to the utility process to be able to use it to decode images at any time, not just install time. * Rename enableForTab and disableForTab to show and hide Why: Increased awesomeness, shorter, more descriptive method names. Also it seems like having a utility function lying around that can decode a user-supplied image would be really useful for a variety of applications in the future. Yay? Nay? - 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: Moving LayoutTests to src/third_party/WebKit
Hi, LayoutTests has been moved from webkit/data to third_party/WebKit. You should sync your client and do the following after sync: -. If your client excludes LayoutTests, remove the following line from .gclient file after sync. No need to have the old one anymore. src/webkit/data/layout_tests/LayoutTests: None, You still need this line: src/third_party/WebKit/LayoutTests: None, -. If your client includes LayoutTests, manually remove directory src/webkit/data/layout_tests/LayoutTests to save space. I also updated the developer docs that will be affected by this change. If I miss any docs, feel free to change them from webkit/data/layout_tests/LayoutTests to third_party/WebKit/LayoutTests. Let me know if you have any questions. Thanks, Victor On Fri, Jul 10, 2009 at 1:31 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Right. Victor is just switching the tests to reside where they needed to be, not dealing with test results. Test results is somewhat of a longer story and we're not tackling this yet. :DG On Fri, Jul 10, 2009 at 12:07 PM, Victor Wangvict...@chromium.org wrote: On Fri, Jul 10, 2009 at 11:11 AM, Ryosuke Niwa rn...@google.com wrote: On Thu, Jul 9, 2009 at 3:09 PM, Victor Wang vict...@chromium.org wrote: If you DO NOT check out chromium source code, you can stop reading. What's the change? To reduce people's confusion about the LayoutTests directory, I am moving it from src/webkit/data/layout_tests/LayoutTests to src/third_party/WebKit/LayoutTests. For details of this request, see issue: http://code.google.com/p/chromium/issues/detail?id=8765 Does this mean that in the future, all expected results will be in WebKit? i.e. we no longer need to update Chromium tree whenever WebKit changes expected results. I think eventually we will get rid of chrome and upstream platform. For now, I just move the LayoutTests directory. Ojan or Dimitri can correct me if I am wrong. Ryosuke --~--~-~--~~~---~--~~ 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: Minor proposed changes to page actions API
On Mon, Jul 13, 2009 at 1:46 PM, Evan Martine...@chromium.org wrote: On Mon, Jul 13, 2009 at 1:44 PM, Aaron Boodmana...@chromium.org wrote: Increased awesomeness, shorter, more descriptive method names. Also it seems like having a utility function lying around that can decode a user-supplied image would be really useful for a variety of applications in the future. Unless people are forced to use this function (perhaps by not providing an alternative) it seems unlikely extension developers will use it. I think I've confused you. Sorry, I should have been more detailed. Right now developers must specify a list of all icons their page action will use ahead of time, in the manifest. Then, at runtime, they specify which icon to switch to. The doc is here: http://dev.chromium.org/developers/design-documents/extensions/page-actions-api The reason the API is like this is that we must decode these images in a sandboxed process, and we currently do all the work at install time. So we need to know the list of images to decode at install time. What I'm proposing is generalizing the sandboxed process we use to do this decoding, so that it can be used at anytime -- not just at install time. Callers, including the page actions UI could say get me image foo/bar/gaz.gif from extension xyz and not care whether this entails a sandboxed decoding or not. We could then get rid of the pre-specified list of images for the page actions API, and it seems like we'd probably want to do similar sorts of things in the future with other extensions UI, so this capability may be reused. - 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: Minor proposed changes to page actions API
On Mon, Jul 13, 2009 at 1:44 PM, Aaron Boodman a...@chromium.org wrote: I'd like to close on some mumbling we've been doing about changes to the page actions API. What: * Make it not required to pre-specify this icon list in the manifest. This will require some refactoring to the utility process to be able to use it to decode images at any time, not just install time. * Rename enableForTab and disableForTab to show and hide Why: Increased awesomeness, shorter, more descriptive method names. Also it seems like having a utility function lying around that can decode a user-supplied image would be really useful for a variety of applications in the future. Yay? Nay? It seems reasonable, but I have some questions / concerns: - How/where are the resulting images cached? We don't want each request to have to be reencoded. In the current install model, they're simply encoded in place. - It seems like there may be related issues if multiple requesters ask for the image at the same time. - What's the increased latency for requesting a single image? I imagine it's not much, but at installation time, an extra 100ms would be no big deal, while in response to UI actions, it would be noticeable jank. - One benefit of having domain-specific image lists is that we could do other validation that was not just for security reasons. For example, we could enforce that page action images were of a particular size and not 2000x2000 (although I don't think we're doing this now). Erik --~--~-~--~~~---~--~~ 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: Minor proposed changes to page actions API
On Mon, Jul 13, 2009 at 2:09 PM, Erik Kayerik...@chromium.org wrote: It seems reasonable, but I have some questions / concerns: - How/where are the resulting images cached? We don't want each request to have to be reencoded. In the current install model, they're simply encoded in place. Yes, they would be written back into the extension. We already do this for page actions so I presumed it would be some generalization of that (we'd have some shadow directory somewhere containing the sanitized/decoded versions of images in the extension). - It seems like there may be related issues if multiple requesters ask for the image at the same time. Yeah, I guess you'd have to keep a map of outstanding requests on the UI thread and queue them. - What's the increased latency for requesting a single image? I imagine it's not much, but at installation time, an extra 100ms would be no big deal, while in response to UI actions, it would be noticeable jank. An extra file read and write the first time. I think it would be tolerable, but we'd have to build it to be sure. - One benefit of having domain-specific image lists is that we could do other validation that was not just for security reasons. For example, we could enforce that page action images were of a particular size and not 2000x2000 (although I don't think we're doing this now). Good point. We could still do this validation at processing time no matter when we do it. We just wouldn't be able to have a validation error at install time. But that doesn't seem like a big loss. - 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: running layout_tests on vista and windows 7
(This time using a reply-all) We used to do this for things like faking font metrics. It resulted in lots of if (webkit_glue::IsLayoutTestMode()) code. We moved away from it because it made it made the code more complicated and meant we weren't shipping the code we were testing. I've heard it proposed before that instead of adding code to check for layout test mode, that maybe we can intercept the system calls and return controlled values (maybe the XP theme?) when in layout test mode. I'm not sure how feasible this is on Windows. On Mon, Jul 13, 2009 at 12:50 PM, Dirk Prankedpra...@google.com wrote: Hi all, (If you don't ever care to run the webkit layout tests, you can skip this note). As most of you are no doubt aware, we currently can only run the webkit layout_tests on windows XP. For some of us who primarily develop on 64-bit Vista, this is inconvenient at best, and this is only going to get worse over time as more of migrate to 64-bit machines and (eventually) Windows 7. So, I'm working on porting the layout tests to Vista. This note is a writeup of the approach I'm thinking of taking, and I'm looking for feedback and suggestions, especially since most of you have been on this code base a lot longer than me. My basic approach is to try and get something up as quickly as possible as a proof of concept, and then work to try and reduce the maintenance over time. So, I've started by cloning the chromium-win port over to vista, and modifying the test scripts to be aware of the new set of test expectations. I will then tweak the tests to get roughly the same list of tests passing on Vista as on Windows. The main differences will have to do with how the theming renders scroll bars and a few other native controls. I have most of this now, and should have the rest of this in a day or two, but this is not a maintainable solution without a lot of manual overhead. Next, we'll get a buildbot setup to run on Vista. While we're doing this, I'll start working on reducing the test set duplication between XP and Vista. The best way to do this (we currently think) will be to modify test_shell to *not* draw the native controls, but rather stub them out in a platform-independent way for test purposes (e.g., just painting a grey box instead of a real scroll bar). Then we can write a few platform-specific unit tests to ensure that the widgets do work correctly, but the bulk of the tests will become (more) platform-independent. My hope is that we'll have something that I can demonstrate here in a week or two, and that it will extend trivially to Win 7. A stretch hope is that we can even get the rendering to be platform-independent enough that we may even be able to leverage them across the linux and mac ports. I don't know if this is realistic or not, as many of the tests may differ just due to font rendering and other minor differences. An alternative strategy is to start looking at more and more of the tests and making sure they are written to be as platform-independent as possible. First we'd this by making sure that we don't rely on pixel-based tests where text-based tests would do. Another option would be to switch to writing two tests just to ensure that page A renders the same way as page B (where A and B use two different sets of layout but should produce the same output). Both of these options are significantly more work up front, but will payoff in much less maintenance down the line. Also, all of this work will also overlap with the webkit test suites, so it'll need to be coordinated with our upstream buddies. Comments? Thoughts? -- Dirk --~--~-~--~~~---~--~~ 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 12:59 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Jul 13, 2009 at 12:54 PM, Darin Fisher da...@chromium.org wrote: On Mon, Jul 13, 2009 at 12:29 PM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Jul 13, 2009 at 12:20 PM, David Levin le...@google.com wrote: On Mon, Jul 13, 2009 at 8:59 AM, Darin Fisher da...@chromium.orgwrote: 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. fwiw, I've checked in all the mechanics to do cheaply use StringImpl's across threads. You have to call a method (to be named) and then you'll get back a new StringImpl which uses the *same underlying buffer *and can be passed to another thread. (Right now, webkit code calls StringImpl::copy() for this purpose but that allocates a new buffer and copies the contents there. I can't modify that method due to the fact that it is currently a threadsafe call and that is relied on in some places in webkit.) Let me know if you want/need more details about it. Dave Would it be better to revisit allowing WebStrings to be transported across the IPC barrier (with this new code) or should we go the NullableString16 route? I'm now leaning towards the latter because the common case is that we _don't_ want to allow null strings. Also it will be similar to string16, so it should be more familiar to Chromium developers. Wrapping WebStrings might be a bit faster though, since it won't require an additional string copy from string16 to and from StringImpl. Hmm... I'd probably go with NullableString16. If we find the copy overhead to matter, then we could always optimize later. Another issue: Do we want to add conversion methods on WebString? My first reaction is to try to avoid it... Hm. I actually thought we should have implicit conversion methods like we do for string16. What's the problem with doing so besides a little bit of bloat? If we're not doing implicit conversion, I'm actually not sure if there's a point to adding NullableString16's since the code will be equally ugly as explicitly having a boolean. J Yeah, that's a good point. Implicit conversion methods it is then. -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] area:webkit fixit week!
This week is fixit week for bugs in area:webkit. Normally, a fixit week is about getting around to fixing all of the various P3 bugs that have accumulated, but this week we're also including the crash bugs, because frankly... there are a lot of them, and I think we could use the extra focus on stability. Here's the complete list: http://code.google.com/p/chromium/issues/list?q=area:webkit%20label:fixit If you have a fixit bug assigned to you, then the assumption is that you are working on it this week. Please take a moment to review that list to ensure that it reflects reality. If you don't have a fixit bug to work on, please look at the list and grab an available bug. Thanks! -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Minor proposed changes to page actions API
On Mon, Jul 13, 2009 at 2:20 PM, Aaron Boodman a...@chromium.org wrote: On Mon, Jul 13, 2009 at 2:09 PM, Erik Kayerik...@chromium.org wrote: It seems reasonable, but I have some questions / concerns: - How/where are the resulting images cached? We don't want each request to have to be reencoded. In the current install model, they're simply encoded in place. Yes, they would be written back into the extension. We already do this for page actions so I presumed it would be some generalization of that (we'd have some shadow directory somewhere containing the sanitized/decoded versions of images in the extension). We'd probably need to store the list of sanitized images in prefs to avoid the extra stat for every image, but OK. - It seems like there may be related issues if multiple requesters ask for the image at the same time. Yeah, I guess you'd have to keep a map of outstanding requests on the UI thread and queue them. - What's the increased latency for requesting a single image? I imagine it's not much, but at installation time, an extra 100ms would be no big deal, while in response to UI actions, it would be noticeable jank. An extra file read and write the first time. I think it would be tolerable, but we'd have to build it to be sure. - One benefit of having domain-specific image lists is that we could do other validation that was not just for security reasons. For example, we could enforce that page action images were of a particular size and not 2000x2000 (although I don't think we're doing this now). Good point. We could still do this validation at processing time no matter when we do it. We just wouldn't be able to have a validation error at install time. But that doesn't seem like a big loss. The other loss here is that we could have caught those problems at package time. Without the declarative list, we can't do that either. Erik --~--~-~--~~~---~--~~ 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: Minor proposed changes to page actions API
On Mon, Jul 13, 2009 at 4:08 PM, Erik Kayerik...@chromium.org wrote: We'd probably need to store the list of sanitized images in prefs to avoid the extra stat for every image, but OK. There's on extra stat, read, and write the first time an image is used. This does not seem like a big deal to me (not worth piling more state into preferences for). These images are not used to draw the main UI, and startup doesn't block on them. If we ever add the magical file cache thing that would be used generally for extension resources, it would presumably help with this too. But it doesn't feel like something that needs optimizing by itself. The other loss here is that we could have caught those problems at package time. Without the declarative list, we can't do that either. True. You know I'm big on error handling, but I feel like ease-of-use wins here. - 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: Minor proposed changes to page actions API
On Mon, Jul 13, 2009 at 4:12 PM, Aaron Boodman a...@chromium.org wrote: On Mon, Jul 13, 2009 at 4:08 PM, Erik Kayerik...@chromium.org wrote: We'd probably need to store the list of sanitized images in prefs to avoid the extra stat for every image, but OK. There's on extra stat, read, and write the first time an image is used. This does not seem like a big deal to me (not worth piling more state into preferences for). These images are not used to draw the main UI, and startup doesn't block on them. If we ever add the magical file cache thing that would be used generally for extension resources, it would presumably help with this too. But it doesn't feel like something that needs optimizing by itself. The other loss here is that we could have caught those problems at package time. Without the declarative list, we can't do that either. True. You know I'm big on error handling, but I feel like ease-of-use wins here. As I said originally, I think the proposal sounds reasonable. It'a always worth going through the downsides. Erik --~--~-~--~~~---~--~~ 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: Moving LayoutTests to src/third_party/WebKit
On Mon, Jul 13, 2009 at 1:45 PM, Victor Wang vict...@chromium.org wrote: LayoutTests has been moved from webkit/data to third_party/WebKit. You should sync your client and do the following after sync: Reminder: if you don't have layout tests in your client, *before sync* you need to add: src/third_party/WebKit/LayoutTests: None, ...to your custom_deps section. There isn't some kind of system that does this for you automatically. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Moving LayoutTests to src/third_party/WebKit
Since Subversion checkouts are hermetic, you can save yourself a ton time if you manually move your LayoutTest directory to the new location before running gclient sync. On Mon, Jul 13, 2009 at 5:05 PM, Peter Kasting pkast...@google.com wrote: On Mon, Jul 13, 2009 at 1:45 PM, Victor Wang vict...@chromium.org wrote: LayoutTests has been moved from webkit/data to third_party/WebKit. You should sync your client and do the following after sync: Reminder: if you don't have layout tests in your client, *before sync* you need to add: src/third_party/WebKit/LayoutTests: None, ...to your custom_deps section. There isn't some kind of system that does this for you automatically. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Working on a new feature? Add extensions support.
What is the review process for new extension APIs? -Darin On Mon, Jul 13, 2009 at 5:17 PM, Erik Kay erik...@chromium.org wrote: If you're not working on any new features or new UI, you can probably skip the rest of this email. If you are, then please take the time to think about whether your feature should be accessible from extensions. Hopefully, no should be more of the exception than the rule. It turns out that adding extensions support is pretty easy. Here's a recent sample CL that adds a getLanguage() function that uses compact language detection: http://codereview.chromium.org/150062 (it's a fair number of files, but the changes are small and easy to understand) Feel free to send questions to the list. We're happy to help with everything from basic how-to questions, to API design, etc. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
