[chromium-dev] Re: Next dev release
On Thu, Nov 5, 2009 at 10:18 AM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Just wanted to know when will the next dev release be? Hi Marcos, We usually try to do dev channel releases once a week, but it varies depending on the state of the tree. Releases (even dev channel ones) take time to create and test. Currently we are a few weeks behind, but we hope to get something out by early next week. - 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] Ensuring that all destructors of ref counted objects are private
I've gone through the code and made all destructors of objects that derive from base::RefCounted or base::RefCountedThreadSafe private. This helps to catch corruption bugs at compile time. For classes that are derived from refcounted, make the destuctor protected and ensure that all derived classes have private destructors. The reason I have gone through and changed all classes is to ensure that new code always has correct examples to copy from. From now on, please ensure that you follow this pattern in code that you write and review. I've updated the wiki and the headers as well. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Large commit - update your .gclient files to avoid
This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ 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: Next dev release
Ok, thanks a lot. I was asking because I am testing the Notifications API and only got it working on the latest nightly build of chromium, but devtools for it doesn't work. Thanks for your help. On Thu, Nov 5, 2009 at 1:11 PM, Aaron Boodman a...@chromium.org wrote: On Thu, Nov 5, 2009 at 10:18 AM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Just wanted to know when will the next dev release be? Hi Marcos, We usually try to do dev channel releases once a week, but it varies depending on the state of the tree. Releases (even dev channel ones) take time to create and test. Currently we are a few weeks behind, but we hope to get something out by early next week. - a -- Marcos Aruj Alvarez Ingeniero de Software --- http://www.marcosaruj.com marcos.a...@gmail.com - --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Next dev release
Hi all, Just wanted to know when will the next dev release be? Thanks -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ 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: Next dev release
On Thu, Nov 5, 2009 at 10:18 AM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Just wanted to know when will the next dev release be? Don't spam this list with questions like this. If you look at the timeline of past dev releases you can probably estimate how long it is between each one. 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: Large commit - update your .gclient files to avoid
Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org wrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] history.back always fires onload in chromium - is it expected?
Hi chromium developers, I've been looking into a layout-test bug 20341 ( http://code.google.com/p/chromium/issues/detail?id=20341) and found that in chromium history.back always fires onload() even if WebKit's page cache is enabled (== WebKitUsePageCachePreferenceKey is set true). This makes running this test ( LayoutTests/loader/go-back-to-different-window-size.html) cause an infinite loop both in test_shell and chromium. In a quick glance FrameLoaderClientImpl::canCachePage() and ApplicationCacheHost::canCacheInPageCache() are hard-coded to return false (with a comment saying that we manage the cache so reporting the page as non-cacheable), making FrameLoader always go through all the page-loading steps. Seems like this behavior (calls onload on history.back or not) differs across browsers: FireFox 3: NO Safari: NO IE8: YES Is it an expected behavior or do we need some fix 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: Large commit - update your .gclient files to avoid
In general, it might be interesting to document how to get a more lean checkout of Chromium. On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth aba...@chromium.org wrote: Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org wrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
it'd be nice to have a gclient config lean or something like that. -Ben On Thu, Nov 5, 2009 at 11:42 AM, Jeremy Orlow jor...@google.com wrote: In general, it might be interesting to document how to get a more lean checkout of Chromium. On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth aba...@chromium.org wrote: Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org wrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
See the Reducing the size of your checkout section of this page for a place to mention it: http://dev.chromium.org/developers/how-tos/get-the-code (gclient config lean would also be nice) Charlie On Thu, Nov 5, 2009 at 11:44 AM, Ben Goodger (Google) b...@chromium.orgwrote: it'd be nice to have a gclient config lean or something like that. -Ben On Thu, Nov 5, 2009 at 11:42 AM, Jeremy Orlow jor...@google.com wrote: In general, it might be interesting to document how to get a more lean checkout of Chromium. On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth aba...@chromium.org wrote: Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org wrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
And have the tarball generated from this lean configuration. On Thu, Nov 5, 2009 at 11:44 AM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. -Ben On Thu, Nov 5, 2009 at 11:42 AM, Jeremy Orlow jor...@google.com wrote: In general, it might be interesting to document how to get a more lean checkout of Chromium. On Thu, Nov 5, 2009 at 11:34 AM, Adam Barth aba...@chromium.org wrote: Can we note this on dev.chromium.org somewhere? Adam On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.org wrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [Chrome-team] Re: [MEMORY] Counting committed bytes
On Thu, Nov 5, 2009 at 7:32 AM, Anton Muhin ant...@chromium.org wrote:
On Wed, Nov 4, 2009 at 3:39 AM, Ricardo Vargas rvar...@google.com wrote:
I don't see the post to chromium-dev so...
Sorry, responding to chromium-dev.
Playing with your code the only delta that I see is one page (for each 2
MB). This ratio works well when the allocation size increases (and drops
to
zero for small allocations), and as far as I can see corresponds to the
memory needed to keep an extra page table for the memory that you reserve
(the cost of reserved memory is small, but not zero).
Yes, I understand it now. I wonder if you (or anyone else) knows
details like when it goes out (and why it happens for tcmalloc which
doesn't frees memory), is there a way to keep it smaller or it just
proportional to amount of reserved memory, is it the same for all
Windows (XP, Vista, 7).
To be fair, the page table is not supposed to be created just for reserved
memory, only for commited, and in fact the page directory entry is empty
until commit. But still, either the page is reserved (for lack of a better
word) or the process is just charged for it.
I don't see a reason for the system doing something different for tcmalloc.
Are you sure that this test really represents the difference that you see
with the actual browser?. The amount of memory will always be a preset
percentage of the requested memory, but it changes slightly with the cpu
mode (32/PAE/64).
One caveat: initialize the message buffers before the first call to
GetProcessMemoryInfo to avoid seeing a ws increase if the stack has to
grow.
Thanks a lot, very good point.
yours,
anton.
On Tue, Nov 3, 2009 at 10:57 AM, Anton Muhin ant...@chromium.org
wrote:
Resending to chromium-dev.
yours,
anton.
On Tue, Nov 3, 2009 at 9:43 PM, Anton Muhin ant...@google.com wrote:
Dear colleagues,
That looks like common idiom (in both tcmalloc and V8) to count amount
of committed/allocated bytes just adding amount of requested size
(modulo alignment) is not quite correct.
At least on my Vista box the following code sometimes reports
overcommitted bytes:
HANDLE ph = GetCurrentProcess();
PROCESS_MEMORY_COUNTERS pmc;
GetProcessMemoryInfo(ph, pmc, sizeof(pmc));
size_t before = pmc.PagefileUsage;
int size = 1 21;
void* p0 = VirtualAlloc(0, size/2, MEM_RESERVE, PAGE_READWRITE);
void* p1 = VirtualAlloc(0, size/2, MEM_RESERVE, PAGE_READWRITE);
GetProcessMemoryInfo(ph, pmc, sizeof(pmc));
size_t after = pmc.PagefileUsage;
int delta = after - before;
char msg[1024] = {0};
sprintf_s(msg, sizeof(msg), delta: %d, size: %d, ratio: %.3f\n,
delta, size, double(size)/double(delta));
OutputDebugStringA(msg);
VirtualAlloc(p0, size/2, MEM_COMMIT, PAGE_READWRITE);
VirtualAlloc(p1, size/2, MEM_COMMIT, PAGE_READWRITE);
GetProcessMemoryInfo(ph, pmc, sizeof(pmc));
delta = pmc.PagefileUsage - before;
char msg2[1024] = {0};
sprintf_s(msg2, sizeof(msg2), after commit delta: %d, size: %d,
ratio: %.3f\n, delta, size, double(size)/double(delta));
OutputDebugStringA(msg2);
VirtualFree(p0, 0, MEM_DECOMMIT);
VirtualFree(p1, 0, MEM_DECOMMIT);
GetProcessMemoryInfo(ph, pmc, sizeof(pmc));
delta = pmc.PagefileUsage - before;
char msg3[1024] = {0};
sprintf_s(msg3, sizeof(msg3), after decommit delta: %d, size: %d,
ratio: %.3f\n, delta, size, double(size)/double(delta));
OutputDebugStringA(msg3);
VirtualFree(p0, 0, MEM_RELEASE);
VirtualFree(p1, 0, MEM_RELEASE);
GetProcessMemoryInfo(ph, pmc, sizeof(pmc));
delta = pmc.PagefileUsage - before;
char msg4[1024] = {0};
sprintf_s(msg4, sizeof(msg4), after release delta: %d, size: %d,
ratio: %.3f\n, delta, size, double(size)/double(delta));
OutputDebugStringA(msg4);
(the code was injected into the very beginning of wWinMain in
chrome_exe_main.cc and there seems no other threads that might commit
something in between).
The problem is actually with reserving (and releasing) bytes: from
time to time reserving bytes commits some amount of memory (probably
for windows-internal structures). The ratios are 0.1--0.4%. If I
make size twice as big, overcommitment happens each run.
This amount seems relatively small, but at least in some cases this
happens very often and allocated sizes are big, so this .3% sum up to
very big values (but see below).
Another problem is I do not know when those system committed bytes get
released. In the snippet above it happens in VirtualFree(*,
MEM_RELEASE), but in tcmalloc we never do MEM_RELEASE, but still the
delta between WinAPI reported committed bytes and tcmalloc reported
bytes sometimes drops and drops notably. I tried to grep for all
VirtualFree's, but looks like the only one operational resides in v8's
platform_win32.cc and tcmalloc is by all means
[chromium-dev] Re: Extensions performance data
Adam, all, I've got http://codereview.chromium.org/355047/ which should speed up accessing isolated worlds (it at least passes layout tests). Could someone either see if it helps or give me instructions how to bench it? yours, anton. On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin ant...@chromium.org wrote: On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth aba...@chromium.org wrote: On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin ant...@chromium.org wrote: if we're sure accessing hidden property is a bottleneck, it should be easily solvable: for long time I was toying idea to compile this code into native, but didn't see compelling enough reason to do that. The easy way to measure it would be to hack stuff a bit and put data as in internal field or just add another getter to context. If you like, I can try to do something like that, but I need a simplistic benchmark to estimate performance gain. I suspect you'll see a performance gain on any simple DOM benchmark that runs in the isolated world. That code path is hit on every wrapper lookup. Ok, I will try to have a look at it this week. yours, anton. --~--~-~--~~~---~--~~ 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: history.back always fires onload in chromium - is it expected?
It sounds like the test depends on the page cache being enabled so we won't be able to pass it until we support the page cache ( http://code.google.com/p/chromium/issues/detail?id=2879 ). There are a couple options: 1) Try to implement the page cache-- abarth probably has some thoughts on this. 2) Skip the test for now and mention in the bug that it depends on the page cache. 3) Try to fix the test so it at least doesn't timeout if we don't support the page cache (I guess layoutTestController.overridePreference should return an error?). We would still fail the test, but it wouldn't slow down the layout tests. I would probably just do 2 for now. On Wed, Nov 4, 2009 at 3:26 AM, Kinuko Yasuda kin...@google.com wrote: Hi chromium developers, I've been looking into a layout-test bug 20341 (http://code.google.com/p/chromium/issues/detail?id=20341) and found that in chromium history.back always fires onload() even if WebKit's page cache is enabled (== WebKitUsePageCachePreferenceKey is set true). This makes running this test (LayoutTests/loader/go-back-to-different-window-size.html) cause an infinite loop both in test_shell and chromium. In a quick glance FrameLoaderClientImpl::canCachePage() and ApplicationCacheHost::canCacheInPageCache() are hard-coded to return false (with a comment saying that we manage the cache so reporting the page as non-cacheable), making FrameLoader always go through all the page-loading steps. Seems like this behavior (calls onload on history.back or not) differs across browsers: FireFox 3: NO Safari: NO IE8: YES Is it an expected behavior or do we need some fix 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: Large commit - update your .gclient files to avoid
On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Explaining to users how to enable logging
If you want to ask a user for their chrome_debug.log in a bug report, you can just paste them this URL: http://dev.chromium.org/for-testers/enable-logging I got tired of writing these steps repeatedly in bug reports, so collected them into a document. I am still unhappy with how complicated this is, and have written some suggestions into http://crbug.com/26161. --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
On Thu, Nov 5, 2009 at 1:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. As long as we're on wishlists, it would be nice to have some dependencies be default-DENY rather than default-ALLOW. So rather than having to suppress things you often don't want, you have to enable things you sometimes do want. -scott [who has no patch lined up to implement this :-).] --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
I started a new thread about a lite version of the checkout. Might be good to move discussion there. On Thu, Nov 5, 2009 at 12:44 PM, Scott Hess sh...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. As long as we're on wishlists, it would be nice to have some dependencies be default-DENY rather than default-ALLOW. So rather than having to suppress things you often don't want, you have to enable things you sometimes do want. -scott [who has no patch lined up to implement this :-).] --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
+1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 1:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. That should move all the way upstream to WebKit... Real Soon Now, I'm sure! :) - Pam I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
+1. I also wonder if it might be useful to have a names file/service for configs so I don't have to remember the full URL when doing a gclient config ... -- Dirk On Thu, Nov 5, 2009 at 12:50 PM, Ben Goodger (Google) b...@chromium.org wrote: +1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 1:50 PM, Ben Goodger (Google) b...@chromium.orgwrote: +1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). chrome/tools/test/smoketests.py Runs all the available unit tests, layout tests, page-cycler tests, etc. for a build of Chrome, imitating a buildbot. - Pam I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
We should include a VM image that these tests get run inside of. ;D -Ben On Thu, Nov 5, 2009 at 12:56 PM, Pam Greene p...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:50 PM, Ben Goodger (Google) b...@chromium.org wrote: +1. This would be fab. There are so many test executables now it's not practical to run them all (unless we have a script... which is sort of what the trybot is like you say). chrome/tools/test/smoketests.py Runs all the available unit tests, layout tests, page-cycler tests, etc. for a build of Chrome, imitating a buildbot. - Pam I like the idea of having full/lean configs. That way you don't need to remember to set up the right .gclient when you set up a new machine. -Ben On Thu, Nov 5, 2009 at 12:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) --~--~-~--~~~---~--~~ 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: Lean Chromium checkout (WAS: Large commit - update your .gclient files to avoid)
On Thu, Nov 5, 2009 at 1:38 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:33 PM, Antoine Labour pi...@google.com wrote: On Thu, Nov 5, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: it'd be nice to have a gclient config lean or something like that. It'd be nice for it to be the default in fact. I know we've avoided this in the past because we wanted everyone to run tests before committing. But realistically, I think we all use the try bots to run tests and only run them locally for triaging a failure. Thus it probably does make sense to not include hundreds if not thousands of megs of test files and such for the default checkout. Do others agree? If so, then we may need to move some of the bulky test data into DEPS so that they can be turned off in gclient. An example is webkit/data/layout_tests which has platform specific test expectations. I think this would make a lot of people on slow internet connections happy. :-) +1 I don't think it's realistic to expect people to run the layout tests at every check-in, so I'd think it is a good candidate. I use git, with git-new-workdir, which lets me share the git repo, including branches, across several directories. Each of them has a separate .gclient, which lets me have different deps for each of them. In particular I can have n-1 lean working dirs, plus one full (where I can run tests). Everytime a new big component is added, I need to add exclusions to each of the lean ones (which I forget to do of course). Antoine --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] test_shell performance is bad compared to Chromium
For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ 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 Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.org wrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread This is really cool and a great idea, but I'm a little concerned about what happens when the thread has already been torn down. It seems that it calls DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper. PostTaskHelper deletes the task if the thread is shut down. This works fine if something is only supposed to touch 2 threads. But what if 2 threads simultaneously delete something which is supposed to be deleted on a third thread that's already been shut down? And what if they both call a method on another class that's not thread safe? I ask because this scenario is going to prevent me from using this for DOM Storage. A possible solution would be to guarantee that, if the thread is dead, destruction happens on the UI thread. At least in this case, I think it would work. Thoughts? 4: I've removed all the special casing and always made the objects in the browser code behave in one way. If you're writing a unit test and need to use an object that goes to a file thread (where before it would proceed synchronously), you just need: ChromeThread file_thread(ChromeThread::FILE, MessageLoop::current()); foo-StartAsyncTaskOnFileThread(); MessageLoop::current()-RunAllPending(); There are plenty of examples now in the tests. *Gotchas* -PostTask will silently delete a task if the thread doesn't exist. This is done to avoid having all the code that uses it have special cases if the target thread exists or not, and to make Valgrind
[chromium-dev] Re: test_shell performance is bad compared to Chromium
I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Tech talk topics
About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: Changes to using threads in the browser process
On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread This is really cool and a great idea, but I'm a little concerned about what happens when the thread has already been torn down. It seems that it calls DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper. PostTaskHelper deletes the task if the thread is shut down. This works fine if something is only supposed to touch 2 threads. But what if 2 threads simultaneously delete something which is supposed to be deleted on a third thread that's already been shut down? I'm not sure which object that you're referring to? The PostTaskHelper will delete the task. But if you have a DeleteSoon task, deleting the task (i.e. because the target thread is gone) doesn't delete the object. As for simultaneously deleting an object, if more than 1 thread are accessing an object, they should each have a reference to it. They can't ensure that releasing their reference will cause deletion, since there could be other refences. And what if they both call a method on another class that's not thread safe? If they use NewRunnableMethod on an object that's not thread safe, then the result task would only execute on the target thread. If the task couldn't execute because the target thread is gone, then the method won't be invoked. I ask because this scenario is going to prevent me from using this for DOM Storage. A possible solution would be to guarantee that, if the thread
[chromium-dev] Re: Changes to using threads in the browser process
On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread This is really cool and a great idea, but I'm a little concerned about what happens when the thread has already been torn down. It seems that it calls DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper. PostTaskHelper deletes the task if the thread is shut down. This works fine if something is only supposed to touch 2 threads. But what if 2 threads simultaneously delete something which is supposed to be deleted on a third thread that's already been shut down? I'm not sure which object that you're referring to? The PostTaskHelper will delete the task. But if you have a DeleteSoon task, deleting the task (i.e. because the target thread is gone) doesn't delete the object. So this means the memory will just be leaked? That won't work for DOM Storage since the backing database is shut down in destructors. As for simultaneously deleting an object, if more than 1 thread are accessing an object, they should each have a reference to it. They can't ensure that releasing their reference will cause deletion, since there could be other refences. Sure, but what if the ref count is not thread safe? Or they access an object that's not thread safe. I often do this because I only touch those members on specific threads, but if I can't guarantee that only one thread could be deleting an
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? Yes, I perceive the scolling, CSS scale-transformations on the iframes, and moving the iframes around as the biggest performance problems. All of these issues might be related to that? On Thu, Nov 5, 2009 at 10:47 PM, Adam Langley a...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. test_shell doesn't implement the fast painting for one. Is the scrolling performance the problem that you're seeing? AGL -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: Large commit - update your .gclient files to avoid
Apologies, this will only apply to committers from Google. -- Steve On Thu, Nov 5, 2009 at 11:16 AM, Steve VanDeBogart vand...@chromium.orgwrote: This afternoon I will update DEPS to pull in 170MB of profile data for memory_test. Unless you run memory_test, you probably want to add the following line to the custom_deps section of your .gclient file. src/data/memory_test/membuster: None, -- Steve --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. On Thu, Nov 5, 2009 at 1:58 PM, Alexander Teinum atei...@gmail.com wrote: This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: Explaining to users how to enable logging
On Thu, Nov 5, 2009 at 2:10 PM, Chase Phillips ch...@chromium.org wrote: On Thu, Nov 5, 2009 at 12:34 PM, Eric Roman ero...@chromium.org wrote: If you want to ask a user for their chrome_debug.log in a bug report, you can just paste them this URL: http://dev.chromium.org/for-testers/enable-logging I got tired of writing these steps repeatedly in bug reports, so collected them into a document. I am still unhappy with how complicated this is, and have written some suggestions into http://crbug.com/26161. Awesome, thanks for writing this up. As part of some changes I've been making I discovered the CHROME_LOG_FILE environment variable. I updated the doc to mention this, too. Oh sweet, I didn't know about that environment variable either! --~--~-~--~~~---~--~~ 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 Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow jor...@chromium.org wrote: On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread This is really cool and a great idea, but I'm a little concerned about what happens when the thread has already been torn down. It seems that it calls DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper. PostTaskHelper deletes the task if the thread is shut down. This works fine if something is only supposed to touch 2 threads. But what if 2 threads simultaneously delete something which is supposed to be deleted on a third thread that's already been shut down? I'm not sure which object that you're referring to? The PostTaskHelper will delete the task. But if you have a DeleteSoon task, deleting the task (i.e. because the target thread is gone) doesn't delete the object. So this means the memory will just be leaked? That won't work for DOM Storage since the backing database is shut down in destructors. If the object doesn't need to be closed on a specific thread, and you want to ensure that it's deleted on any thread, then ReleaseSoon and ChromeThread::DeleteOnIOThread aren't going to serve your need. You'll probably want to have either a singleton or an object like ResourceDispatcherHost that BrowserProcess can delete directly. As for simultaneously deleting an object, if more than 1 thread are
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. Done! :) Alexander On Thu, Nov 5, 2009 at 11:02 PM, Nico Weber tha...@chromium.org wrote: Maybe star http://crbug.com/23145 to express your interest. That might motivate mhm to get this ready for checkin. On Thu, Nov 5, 2009 at 1:58 PM, Alexander Teinum atei...@gmail.com wrote: This is exactly what i want. Thanks! I'll see if I can make it work. Alexander On Thu, Nov 5, 2009 at 10:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Alexander On Thu, Nov 5, 2009 at 10:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. 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: Explaining to users how to enable logging
On Thu, Nov 5, 2009 at 12:34 PM, Eric Roman ero...@chromium.org wrote: If you want to ask a user for their chrome_debug.log in a bug report, you can just paste them this URL: http://dev.chromium.org/for-testers/enable-logging I got tired of writing these steps repeatedly in bug reports, so collected them into a document. I am still unhappy with how complicated this is, and have written some suggestions into http://crbug.com/26161. Awesome, thanks for writing this up. As part of some changes I've been making I discovered the CHROME_LOG_FILE environment variable. I updated the doc to mention this, too. --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Is there some reason you're not just using Chromium in full screen mode? -- Dirk On Thu, Nov 5, 2009 at 1:18 PM, Alexander Teinum atei...@gmail.com wrote: For a personal project (well, an OS -- check out www.brevityos.org if you're interested), I need something like test_shell in fullscreen mode. The UI is basically an HTML-file with an iframe for every document. CSS-classes are used to describe what application is active, what documents are active etc. The problem is that for my project, test_shell performs bad compared to Chromium. I have compiled with mode set to release, but it's still noticeably slower. I've watched Darin Fisher and Brett Wilson's presentations about the Chromium architecture on YouTube. If I've got it right, then test_shell is below the layer that implements multi-processes. Brett says that test_shell is based on WebKit glue. What needs to be done to make test_shell perform as good as Chromium? I'm not suggesting that test_shell needs to be changed. I'll probably do this in a separate directory under chromium-dir/src, or as a Linux port of Chromium Embedded Framework, if Marshall wants CEF to be multi-processed. -- Best regards, Alexander Teinum --~--~-~--~~~---~--~~ 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: Tech talk topics
It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:56 PM, Alexander Teinum atei...@gmail.com wrote: Yes, I perceive the scolling, CSS scale-transformations on the iframes, and moving the iframes around as the biggest performance problems. All of these issues might be related to that? You could try reading chrome/renderer/render_widget.cc, which contains the painting code. You need to implement fast scrolling in at least (ScrollRect) and possible some other things before test_shell will be usable. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Sorry Dirk, I could have said why I don't think it's an optimal solution. I think it's fine to have components that are not used, as long as they don't eat resources or get in the way. The status bar gets in the way for my project while in fullscreen. There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. A --fullscreen switch could also work. Without being a kiosk computer expert, I'd think that kiosk mode communicates that the program should be restricted. It might prevent the user from going back from fullscreen or exiting Chromium. On Thu, Nov 5, 2009 at 11:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: Tech talk topics
Sure...we definitely have some in-house expertise on this. I could even see if any of the Apple guys would be interested in this...but I wouldn't hold my breath. :-) What types of WebKit topics? On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: Tech talk topics
A general big picture talk would be a great starter. How the DOM is modeled, how the render tree works, the interesting objects ... -Scott On Thu, Nov 5, 2009 at 2:22 PM, Jeremy Orlow jor...@chromium.org wrote: Sure...we definitely have some in-house expertise on this. I could even see if any of the Apple guys would be interested in this...but I wouldn't hold my breath. :-) What types of WebKit topics? On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: test_shell performance is bad compared to Chromium
Whops, I'm saying sorry to Dirk and replying to Peter. Sorry to both of you. ;) On Thu, Nov 5, 2009 at 11:24 PM, Alexander Teinum atei...@gmail.com wrote: Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Sorry Dirk, I could have said why I don't think it's an optimal solution. I think it's fine to have components that are not used, as long as they don't eat resources or get in the way. The status bar gets in the way for my project while in fullscreen. There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. A --fullscreen switch could also work. Without being a kiosk computer expert, I'd think that kiosk mode communicates that the program should be restricted. It might prevent the user from going back from fullscreen or exiting Chromium. On Thu, Nov 5, 2009 at 11:06 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:44 PM, Alexander Teinum atei...@gmail.com wrote: I could probably hack it so that it went into fullscreen, and then disable F11, but that's dirty. All the UI stuff from Chromium would still be there, although it would be hidden. Why is that dirty? This is basically kiosk mode, which other people have asked for too. The last time, that ballooned into an enormous unwieldy patch, but just adding a --fullscreen switch wouldn't be so bad. Definitely do not attempt to use test_shell for anything other than testing purposes. It is not, and should not be, a usable or performant product, and as Dirk mentioned, we may eliminate it completely in the future. PK -- Best regards/Med vennlig hilsen, Alexander Teinum -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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 Thu, Nov 5, 2009 at 2:01 PM, John Abd-El-Malek j...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:42 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:34 PM, John Abd-El-Malek j...@chromium.orgwrote: On Thu, Nov 5, 2009 at 1:15 PM, Jeremy Orlow jor...@chromium.orgwrote: On Mon, Nov 2, 2009 at 9:50 PM, John Abd-El-Malek j...@chromium.orgwrote: Over the last week, I've been making some changes to how threads are used in the browser process, with the goal of simplifying cross-thread access and improving stability. *The problem* We were using a number of patterns that were problematic: 1) using ChromeThread::GetMessageLoop -this isn't safe, since it could return a valid pointer, but since the caller isn't holding on to a lock anymore, the target MessageLoop could be destructed while it's being used 2) caching of MessageLoop pointers in order to use them later for PostTask and friends -this was more efficient previously (more on that later) since using ChromeThread::GetMessageLoop involved a lock -but it spread logic about the order of thread destruction all over the code. Code that moved from the IO thread to the file thread and back, in order to avoid doing disk access on the IO thread, ended up having to do an extra hop through the UI thread on the way back to the IO thread since the file thread outlives the Io thread. Of course, most code learnt this the hard way, after doing the straight forward IO-file-IO thread hop and updating the code after seeing reliability or user crashes -it made the browser shutdown fragile and hence difficult to update 3) file thread hops using RefCountedThreadSafe objects which have non-trivial destructors -to reduce jank, frequently an object on the UI or IO thread would execute some code on the file thread, then post the result back to the original thread. We make this easy using RefCountedThreadSafe and NewRunnableMethod so this pattern happened often, but it's not always safe: NewRunnableMethod holds an extra reference on the object to ensure that it doesn't invoke a method on a deleted object. But it's quite possible that before the file thread's stack unwinds and it releases the extra reference, that the response task on the original thread executed and released its own additional reference. The file thread is then left with the remaining reference and the object gets destructed there. While for most objects this is ok, many have non-trivial destructors, with the worst being ones that register with the per-thread NotificationService. Dangling pointers would be left behind and tracking these crashes from ChromeBot or the crash dumps has wasted several days at least for me. 4) having browser code take different code paths if a thread didn't exist -this could be either deceptively harmless (i.e. execute synchronously when it was normally asynchronous), when in fact it makes shutdown slower because disk access is moved to the UI thread -it could lead to data loss, if tasks are silently not posted because the code assumes this only happens in unit tests, when it could occur on browser shutdown as well *The solution* 1+2: Use ChromeThread::PostTask and friends (i.e. PostDelayedTask, DeleteSoon, ReleaseSoon) which are safe and efficient: no locks are grabbed if the target thread is known to outlive the current thread. The four static methods have the same signature as the ones from MessageLoop, with the addition of the first parameter to indicate the target thread. ChromeThread::PostTask(ChromeThread::FILE, FROM_HERE, task); 3: If your object must be destructed on a specific thread, use a trait from ChromeThread: class Foo : public base::RefCountedThreadSafeFoo, ChromeThread::DeleteOnIOThread This is really cool and a great idea, but I'm a little concerned about what happens when the thread has already been torn down. It seems that it calls DeleteSoon which calls PostNonNestableTask which calls PostTaskHelper. PostTaskHelper deletes the task if the thread is shut down. This works fine if something is only supposed to touch 2 threads. But what if 2 threads simultaneously delete something which is supposed to be deleted on a third thread that's already been shut down? I'm not sure which object that you're referring to? The PostTaskHelper will delete the task. But if you have a DeleteSoon task, deleting the task (i.e. because the target thread is gone) doesn't delete the object. So this means the memory will just be leaked? That won't work for DOM Storage since the backing database is shut down in destructors. If the object doesn't need to be closed on a specific thread, and you want to ensure that it's deleted on any thread, then ReleaseSoon and ChromeThread::DeleteOnIOThread aren't going to serve your need. You'll probably want to have either a singleton or an object like ResourceDispatcherHost that BrowserProcess
[chromium-dev] Re: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. On Thu, Nov 5, 2009 at 2:24 PM, Alexander Teinum atei...@gmail.com wrote: There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. 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: Large commit - update your .gclient files to avoid
On Thu, Nov 5, 2009 at 2:03 PM, Steve VanDeBogart vand...@chromium.orgwrote: Apologies, this will only apply to committers from Google. For clarity: If you added this line to your .gclient, you can remove it. 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Good question, and I didn't actually know the answer, so that provoked an interesting but short discussion between Ojan and Dimitri and myself. At the moment we're leaning to keeping test_shell and DumpRenderTree both. The latter would be the driver for the layout test harness (as it is upstream), and test_shell would get all of the layout test code ripped out of it and become more like an actual shell that can be used to embed webkit for interactive work (and upstreamed, as you say). The exact functionality and distinctions between the two (and the justification of the existence of both) probably still needs some edges smoothed. -- 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: test_shell performance is bad compared to Chromium
What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. On Thu, Nov 5, 2009 at 11:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. On Thu, Nov 5, 2009 at 2:24 PM, Alexander Teinum atei...@gmail.com wrote: There's also a 1 pixel border on top that I don't want. I don't want the user to trigger any of the Chromium UI with the keyboard. What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: It's in the Linux-version. You should have mentioned the platform. You have an awful lot of work to get the Linux test_shell up to Chromium speeds. There's a lot of raw Xlib calls to keep the image of the page in video memory and to try and use accelerated blits to scroll. AGL --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: test_shell performance is bad compared to Chromium
Sure. I'm not into the patching process yet, but give me a couple of days, and I'll try to get it fixed. Alexander On Thu, Nov 5, 2009 at 11:48 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.com wrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about this? PK -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 2:51 PM, Adam Langley a...@chromium.org wrote: You have an awful lot of work to get the Linux test_shell up to Chromium speeds. I'm really opposed to doing work like this on test_shell. It's not just that it's a waste of time. One of the reasons we have test_shell is to be as simple an app as possible, so that it's easy to test things and obvious where the problems are when things go wrong. Making test_shell more optimized and performant pretty much necessarily means making it less braindead-obvious. That's bad. 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: test_shell performance is bad compared to Chromium
-- Evan Stade On Thu, Nov 5, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 2:46 PM, Alexander Teinum atei...@gmail.comwrote: What? What OS? There shouldn't be any 1 pixel border in our fullscreen mode. It's in the Linux-version. In BrowserWindowGtk::InitWidgets() there’s this line: gtk_widget_set_size_request(toolbar_border_, -1, 1); I changed it into: gtk_widget_set_size_request(toolbar_border_, -1, -1); That got rid of it, but that also removes it from the normal mode, where it should be. It's the line between the web browser view and the toolbars above. ah, this is my fault. Of course that is not the intended behavior... I'll fix. If you can provide a patch to do the right thing (no line in fullscreen mode), that'd be awesome, otherwise can you file a bug about 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] The future for test shell (WAS: test_shell performance is bad compared to Chromium)
On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Good question, and I didn't actually know the answer, so that provoked an interesting but short discussion between Ojan and Dimitri and myself. At the moment we're leaning to keeping test_shell and DumpRenderTree both. The latter would be the driver for the layout test harness (as it is upstream), and test_shell would get all of the layout test code ripped out of it and become more like an actual shell that can be used to embed webkit for interactive work (and upstreamed, as you say). The exact functionality and distinctions between the two (and the justification of the existence of both) probably still needs some edges smoothed. Features like AppCache and WebDatabase depend on code that will probably never be unstreamed to WebKit's repo. So either we need to always run at least some tests under test shell or we'll need to be content with not running these layout tests. Note that we have a somewhat hacky way of running layout tests in the UI test framework that might suffice for this stuff. Right now, I run LocalStorage tests in both test_shell and the ui_test framework. --~--~-~--~~~---~--~~ 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: Tech talk topics
IMHO it would be immensely valuable to give a talk explaining what Layout tests are and how they work in a *simple* enough manner to allow web developers to create tests for bugs that affect them. I haven't found any easily discoverable introductory material on this topic. Best regards, Jeremy On Fri, Nov 6, 2009 at 12:30 AM, Scott Violet s...@chromium.org wrote: A general big picture talk would be a great starter. How the DOM is modeled, how the render tree works, the interesting objects ... -Scott On Thu, Nov 5, 2009 at 2:22 PM, Jeremy Orlow jor...@chromium.org wrote: Sure...we definitely have some in-house expertise on this. I could even see if any of the Apple guys would be interested in this...but I wouldn't hold my breath. :-) What types of WebKit topics? On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: Tech talk topics
That's an excellent idea! Do you think you'd be able to give it? If not, do you have any suggestions on who would be good? Maybe Pam? On Thu, Nov 5, 2009 at 3:08 PM, Jeremy Moskovich jer...@chromium.orgwrote: IMHO it would be immensely valuable to give a talk explaining what Layout tests are and how they work in a *simple* enough manner to allow web developers to create tests for bugs that affect them. I haven't found any easily discoverable introductory material on this topic. Best regards, Jeremy On Fri, Nov 6, 2009 at 12:30 AM, Scott Violet s...@chromium.org wrote: A general big picture talk would be a great starter. How the DOM is modeled, how the render tree works, the interesting objects ... -Scott On Thu, Nov 5, 2009 at 2:22 PM, Jeremy Orlow jor...@chromium.org wrote: Sure...we definitely have some in-house expertise on this. I could even see if any of the Apple guys would be interested in this...but I wouldn't hold my breath. :-) What types of WebKit topics? On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: [chromium-extensions] Re: Desktop Notifications
Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Quick question, how is the Notifications API going for the release of 4.0? Are there any news on this? Any sample code? Just wanted to know if we can rely on it now or if we should wait. Thanks! Marcos On Tue, Oct 20, 2009 at 11:04 AM, Darin Fisher da...@chromium.org wrote: OK, that sounds reasonable to me. -Darin On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote: Not precisely embedding a TabContents; I'm drawing a custom toast using views and putting a RenderViewHost+RenderWidgetHostView in it. -John On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.orgwrote: Is this accomplished by embedding a TabContents in a custom drawn (using Views) toast? -Darin On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.orgwrote: To be clear - our priority is to support HTML notifications on all platforms *before* investigating support for native notification platforms (like Growl/libnotify). -atw On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.org wrote: We're trying to come up with a way to display html notifications on these platforms, once we get the windows one checked in. (Likely code that we will have to write.) 2009/10/19 Evan Martin e...@chromium.org On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com wrote: The implementation of notifications is nearly complete for Windows chromium with the final pieces being reviewed right now. Hopefully it will be available on the dev channel very soon behind a command-line switch for developers to start using. If you have questions about the specifics of the API, let me know, I'm happy to answer them and/or provide more documentation. I had alluded to this before, but I don't still see a good answer: what is the plan on Mac/Linux when the API is called with HTML? -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ 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: The future for test shell (WAS: test_shell performance is bad compared to Chromium)
Yeah, we would have to work out a way of handling these sorts of features. -- Dirk On Thu, Nov 5, 2009 at 3:01 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Good question, and I didn't actually know the answer, so that provoked an interesting but short discussion between Ojan and Dimitri and myself. At the moment we're leaning to keeping test_shell and DumpRenderTree both. The latter would be the driver for the layout test harness (as it is upstream), and test_shell would get all of the layout test code ripped out of it and become more like an actual shell that can be used to embed webkit for interactive work (and upstreamed, as you say). The exact functionality and distinctions between the two (and the justification of the existence of both) probably still needs some edges smoothed. Features like AppCache and WebDatabase depend on code that will probably never be unstreamed to WebKit's repo. So either we need to always run at least some tests under test shell or we'll need to be content with not running these layout tests. Note that we have a somewhat hacky way of running layout tests in the UI test framework that might suffice for this stuff. Right now, I run LocalStorage tests in both test_shell and the ui_test framework. --~--~-~--~~~---~--~~ 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-extensions] Re: Desktop Notifications
Creating a bug with a small sample attached would be great. On Thu, Nov 5, 2009 at 3:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, Quick question, how is the Notifications API going for the release of 4.0? Are there any news on this? Any sample code? Just wanted to know if we can rely on it now or if we should wait. Thanks! Marcos On Tue, Oct 20, 2009 at 11:04 AM, Darin Fisher da...@chromium.org wrote: OK, that sounds reasonable to me. -Darin On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote: Not precisely embedding a TabContents; I'm drawing a custom toast using views and putting a RenderViewHost+RenderWidgetHostView in it. -John On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.org wrote: Is this accomplished by embedding a TabContents in a custom drawn (using Views) toast? -Darin On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.org wrote: To be clear - our priority is to support HTML notifications on all platforms *before* investigating support for native notification platforms (like Growl/libnotify). -atw On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.org wrote: We're trying to come up with a way to display html notifications on these platforms, once we get the windows one checked in. (Likely code that we will have to write.) 2009/10/19 Evan Martin e...@chromium.org On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com wrote: The implementation of notifications is nearly complete for Windows chromium with the final pieces being reviewed right now. Hopefully it will be available on the dev channel very soon behind a command-line switch for developers to start using. If you have questions about the specifics of the API, let me know, I'm happy to answer them and/or provide more documentation. I had alluded to this before, but I don't still see a good answer: what is the plan on Mac/Linux when the API is called with HTML? -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ 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-extensions] Re: Desktop Notifications
Thanks for the bug report, I am currently working on getting Notifications working for extensions and I'm familiar with this issue, although I don't think there is a bug for it yet. If you would create one I can update it as I get the fix checked in (which will hopefully be tomorrow, I think it's a fairly easy fix). -John On Thu, Nov 5, 2009 at 6:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj marcos.a...@gmail.comwrote: Hi all, Quick question, how is the Notifications API going for the release of 4.0? Are there any news on this? Any sample code? Just wanted to know if we can rely on it now or if we should wait. Thanks! Marcos On Tue, Oct 20, 2009 at 11:04 AM, Darin Fisher da...@chromium.orgwrote: OK, that sounds reasonable to me. -Darin On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote: Not precisely embedding a TabContents; I'm drawing a custom toast using views and putting a RenderViewHost+RenderWidgetHostView in it. -John On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.orgwrote: Is this accomplished by embedding a TabContents in a custom drawn (using Views) toast? -Darin On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.orgwrote: To be clear - our priority is to support HTML notifications on all platforms *before* investigating support for native notification platforms (like Growl/libnotify). -atw On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.org wrote: We're trying to come up with a way to display html notifications on these platforms, once we get the windows one checked in. (Likely code that we will have to write.) 2009/10/19 Evan Martin e...@chromium.org On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com wrote: The implementation of notifications is nearly complete for Windows chromium with the final pieces being reviewed right now. Hopefully it will be available on the dev channel very soon behind a command-line switch for developers to start using. If you have questions about the specifics of the API, let me know, I'm happy to answer them and/or provide more documentation. I had alluded to this before, but I don't still see a good answer: what is the plan on Mac/Linux when the API is called with HTML? -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 5:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. Not entirely abandoned, true it was getting out of control and that is why I stopped to take a step back. Technically it should be what I did for patch set one, which is just fullscreen + no statusbar. That is basically what the functionality is. I will continue working on it tonight. - Mohamed Mansour --~--~-~--~~~---~--~~ 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: The future for test shell (WAS: test_shell performance is bad compared to Chromium)
On Thu, Nov 5, 2009 at 3:01 PM, Jeremy Orlow jor...@chromium.org wrote: On Thu, Nov 5, 2009 at 2:46 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Nov 5, 2009 at 1:59 PM, Marshall Greenblatt magreenbl...@gmail.com wrote: On Thu, Nov 5, 2009 at 4:32 PM, Dirk Pranke dpra...@chromium.org wrote: test_shell being a test shell used mostly for non-interactive testing, we haven't given a lot of concern to its perfomance AFAIK. I'm not even sure how long of a lifespan it'll have since we aim to merge/replace it with WebKit's DumpRenderTree at some point soon. So is the plan now for test_shell to go away completely? #3 under *Next steps:* in this email seemed to suggest that it would be up-streamed: http://groups.google.com/group/chromium-dev/browse_thread/thread/5352c2facb46f309 Wouldn't merging/replacing test_shell with DRT eliminate the ability to test the Chromium WebKit API in a simplified environment? Good question, and I didn't actually know the answer, so that provoked an interesting but short discussion between Ojan and Dimitri and myself. At the moment we're leaning to keeping test_shell and DumpRenderTree both. The latter would be the driver for the layout test harness (as it is upstream), and test_shell would get all of the layout test code ripped out of it and become more like an actual shell that can be used to embed webkit for interactive work (and upstreamed, as you say). The exact functionality and distinctions between the two (and the justification of the existence of both) probably still needs some edges smoothed. Features like AppCache and WebDatabase depend on code that will probably never be unstreamed to WebKit's repo. Because it depends on base, net, etc. So either we need to always run at least some tests under test shell Or we need to do some GYP hackery so that we can compile in their implementation or our implementation...and be sure that we run our implementation on at least some of our bots. or we'll need to be content with not running these layout tests. Note that we have a somewhat hacky way of running layout tests in the UI test framework that might suffice for this stuff. Right now, I run LocalStorage tests in both test_shell and the ui_test framework. --~--~-~--~~~---~--~~ 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: Which editor do you recommend on Mac OS X?
So I've officially switched to carbon emacs, and I'm loving it. Is there a way to launch a second instance - double-clicking the executable seems to just bring the original instance to the foreground. Feel free to tell me I'm Doing It Wrong, but when working on two trees simultaneously I like to open them in separate emacs instances so I don't accidentally make edits in the wrong tree. -atw On Tue, Nov 3, 2009 at 10:16 AM, Kenneth Russell k...@chromium.org wrote: There's a Carbon-based, non-Aquamacs Emacs available for Mac OS X. Recommended. http://www.emacswiki.org/emacs/EmacsForMacOS http://www.emacswiki.org/emacs/CarbonEmacsPackage -Ken On Tue, Nov 3, 2009 at 10:08 AM, Drew Wilson atwil...@chromium.org wrote: I've been using Aquamacs, although I don't like the fact that it has *so many* modes built-in and turned-on by default, and I also don't like the fact that it doesn't lend itself well to customization (it has its own set of initialization files it keeps hidden off). It's decent, though (but again, I've devolved over the years to using almost vanilla emacs bindings to allow moving to new platforms easier). I've also been known to use the built-in GNU emacs from a terminal shell (especially when working remotely/SSH-ing). I see no reason why you can't have the same experience that you do with your Linux box, although you'd have to find a way to drag the google3 elisp over. -atw On Tue, Nov 3, 2009 at 9:56 AM, Paweł Hajdan Jr. phajdan...@chromium.org wrote: Recently I started working more and more on Mac OS X, and I'm trying to find an editor that would work the best for me. On Linux I used GNU Emacs with many customizations. Some of the most handy ones for working on Chromium were Google Style script and launching the compilation from the editor. I also used Vim keybindings (Viper) a lot. On Mac, I tried Aquamacs, but some of my customizations broke. Also, the Vim emulation seems to be only half-working (selecting text in Vim visual mode isn't working). I also tried Xcode, but it seems that the editor isn't powerful enough. I don't know how to quickly remove an entire line (2 keystrokes in Vim), or a few lines (3 keystrokes). However, the Open Quickly option (cmd-shift-d) is very nice. I also couldn't find an easy solution to automatically remove trailing whitespace in Xcode. Do you have any tips about effective editing on Mac? Which solution would you recommend? --~--~-~--~~~---~--~~ 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: Tech talk topics
+1 on the WebKit tech talks. And maybe on on the WebKitAPI infrastructure that darin organized. - Mohamed Mansour On Thu, Nov 5, 2009 at 5:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: Tech talk topics
I'd be happy to give a talk about layout tests. It would help me if people could suggest subtopics, or more simply, ask questions they'd like answered. I've been working with the things for so long, it's hard for me to know what's confusing or unclear anymore. - Pam On Thu, Nov 5, 2009 at 4:10 PM, Jeremy Orlow jor...@chromium.org wrote: That's an excellent idea! Do you think you'd be able to give it? If not, do you have any suggestions on who would be good? Maybe Pam? On Thu, Nov 5, 2009 at 3:08 PM, Jeremy Moskovich jer...@chromium.orgwrote: IMHO it would be immensely valuable to give a talk explaining what Layout tests are and how they work in a *simple* enough manner to allow web developers to create tests for bugs that affect them. I haven't found any easily discoverable introductory material on this topic. Best regards, Jeremy On Fri, Nov 6, 2009 at 12:30 AM, Scott Violet s...@chromium.org wrote: A general big picture talk would be a great starter. How the DOM is modeled, how the render tree works, the interesting objects ... -Scott On Thu, Nov 5, 2009 at 2:22 PM, Jeremy Orlow jor...@chromium.org wrote: Sure...we definitely have some in-house expertise on this. I could even see if any of the Apple guys would be interested in this...but I wouldn't hold my breath. :-) What types of WebKit topics? On Thu, Nov 5, 2009 at 2:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: Tech talk topics
Something that would have been immensely helpful to me when I started was a talk explaining the interaction between the javascript bindings, HTMLFooElement classes and RenderFoo classes. I'd volunteer, but I still don't know enough about this stuff myself -- other than when Foo == Media :) Andrew On Thu, Nov 5, 2009 at 3:24 PM, Mohamed Mansour m...@chromium.org wrote: +1 on the WebKit tech talks. And maybe on on the WebKitAPI infrastructure that darin organized. - Mohamed Mansour On Thu, Nov 5, 2009 at 5:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: test_shell performance is bad compared to Chromium
I want to make it clear, and it might be obvious by now, but test_shell isn't interesting to me. I just want the fastest browser engine that I can get. What makes Chromium different than WebKitGTK+ for my project, is that Chromium renders the GTK stuff correctly with CSS transformations. It's also snappier. Making the rendering part of Chromium easier to use for open source project would benefit projects such as mine or uzbl for instance. uzbl is a WebKitGTK+ browser that is controlled similar to Vim. I realize that CEF is an effort at making it easier to embed Chromium, but if it's based on test_shell, then well... what about the platform optimalizations? Are they easy to get into CEF, or does it have to play catch-up? On Fri, Nov 6, 2009 at 12:21 AM, Mohamed Mansour m...@chromium.org wrote: On Thu, Nov 5, 2009 at 5:33 PM, Peter Kasting pkast...@google.com wrote: On Thu, Nov 5, 2009 at 1:51 PM, Nico Weber tha...@chromium.org wrote: http://codereview.chromium.org/244003/show might be what you want. I thought this was intentionally abandoned because it was growing out of control. That's what I was alluding to before. Not entirely abandoned, true it was getting out of control and that is why I stopped to take a step back. Technically it should be what I did for patch set one, which is just fullscreen + no statusbar. That is basically what the functionality is. I will continue working on it tonight. - Mohamed Mansour -- Best regards/Med vennlig hilsen, Alexander Teinum --~--~-~--~~~---~--~~ 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: Tech talk topics
Thanks for the suggestions so far! Here's what I've seen so far: WebKit API - Darin? Eric's WebKit talk LayoutTests - Pam? Bindings - Andrew? Keep the ideas coming. If we get more than we want to tackle we can always vote on which would be most helpful to the community, but all the ones I've heard so far sound very valuable. J On Thu, Nov 5, 2009 at 3:29 PM, Andrew Scherkus scher...@chromium.orgwrote: Something that would have been immensely helpful to me when I started was a talk explaining the interaction between the javascript bindings, HTMLFooElement classes and RenderFoo classes. I'd volunteer, but I still don't know enough about this stuff myself -- other than when Foo == Media :) Andrew On Thu, Nov 5, 2009 at 3:24 PM, Mohamed Mansour m...@chromium.org wrote: +1 on the WebKit tech talks. And maybe on on the WebKitAPI infrastructure that darin organized. - Mohamed Mansour On Thu, Nov 5, 2009 at 5:17 PM, Scott Violet s...@chromium.org wrote: It's not Chromium, but how about some WebKit tech talks? Such talks would be incredibly valuable to those helping out now and then with WebKit. -Scott On Thu, Nov 5, 2009 at 1:35 PM, Jeremy Orlow jor...@chromium.org wrote: About 6 months ago, we had a series of tech talks on various bits of Chromium's architecture. (They're listed here: http://dev.chromium.org/developers/tech-talk-videos) The youtube ratings are pretty high, they've all had over a thousand views, and I've seen them mentioned in a couple chromium-dev threadsso it seems like they've been helpful. So here's my question: are there any Chromium-internals related topics you guys/gals would really like to hear more on? If so, I'll see if we can't find speakers, schedule some tech talks, get them recorded, and posted. And this time, we'll make sure the audio and video quality is much higher. :-) 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: test_shell performance is bad compared to Chromium
On Thu, Nov 5, 2009 at 3:34 PM, Alexander Teinum atei...@gmail.com wrote: Making the rendering part of Chromium easier to use for open source project would benefit projects such as mine or uzbl for instance. uzbl is a WebKitGTK+ browser that is controlled similar to Vim. This is one of the reasons we are trying to upstream our WebKit API embedding layer. See a recent post by Darin Fisher on webkit-dev. 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: [chromium-extensions] Re: Desktop Notifications
Ok, done: http://www.crbug.com/26859 I attached a crx to the report that triggers the bug. Thanks! On Thu, Nov 5, 2009 at 5:19 PM, John Gregg john...@google.com wrote: Thanks for the bug report, I am currently working on getting Notifications working for extensions and I'm familiar with this issue, although I don't think there is a bug for it yet. If you would create one I can update it as I get the fix checked in (which will hopefully be tomorrow, I think it's a fairly easy fix). -John On Thu, Nov 5, 2009 at 6:11 PM, Marcos Aruj marcos.a...@gmail.com wrote: Hi all, We've been testing the Notifications API and have shown them successfully on a regular page. We are trying to use it from within an extension, but Chromium crashes when calling requestPermission. It correctly asks to allow notifications for chrome-extension://XX/, but after allowing or denying, it crashes. Let me know if a bug needs to be created, if it's a known issue or if we are missing something. Thanks, Marcos On Fri, Oct 30, 2009 at 3:57 PM, Marcos Aruj marcos.a...@gmail.comwrote: Hi all, Quick question, how is the Notifications API going for the release of 4.0? Are there any news on this? Any sample code? Just wanted to know if we can rely on it now or if we should wait. Thanks! Marcos On Tue, Oct 20, 2009 at 11:04 AM, Darin Fisher da...@chromium.orgwrote: OK, that sounds reasonable to me. -Darin On Tue, Oct 20, 2009 at 9:51 AM, John Gregg john...@google.com wrote: Not precisely embedding a TabContents; I'm drawing a custom toast using views and putting a RenderViewHost+RenderWidgetHostView in it. -John On Tue, Oct 20, 2009 at 12:27 AM, Darin Fisher da...@chromium.orgwrote: Is this accomplished by embedding a TabContents in a custom drawn (using Views) toast? -Darin On Mon, Oct 19, 2009 at 2:17 PM, Drew Wilson atwil...@chromium.orgwrote: To be clear - our priority is to support HTML notifications on all platforms *before* investigating support for native notification platforms (like Growl/libnotify). -atw On Mon, Oct 19, 2009 at 11:25 AM, Ian Fette i...@chromium.orgwrote: We're trying to come up with a way to display html notifications on these platforms, once we get the windows one checked in. (Likely code that we will have to write.) 2009/10/19 Evan Martin e...@chromium.org On Mon, Oct 19, 2009 at 11:16 AM, John Gregg john...@google.com wrote: The implementation of notifications is nearly complete for Windows chromium with the final pieces being reviewed right now. Hopefully it will be available on the dev channel very soon behind a command-line switch for developers to start using. If you have questions about the specifics of the API, let me know, I'm happy to answer them and/or provide more documentation. I had alluded to this before, but I don't still see a good answer: what is the plan on Mac/Linux when the API is called with HTML? -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - -- Marcos Aruj Alvarez Ingeniero de Software --- marcos.a...@gmail.com - --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Preventing keypress after accellerator?
We have code to suppress the keypress event if keydown triggered a browser accelerator both inside and outside of WebKit. I don't understand why we want to prevent a keypress after a Ctrl+A or Ctrl+B keydown? -- 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: Circular relationship in NaCl .gyp files - this is bad!
Some further info on this topic: There are circular dependencies in nacl, but the reason this does not afflict the buildbots is that xcode will handle this correctly IF you CMD-Q out of xcode before regenerating the project file. We should nonetheless fix the circularity and then have gyp complain. -BradN On Thu, Nov 5, 2009 at 3:33 PM, Mark Mentovai mmento...@google.com wrote: Robert Muth wrote: I am looking into it. Thanks. I have a change for GYP ready to detect these cases and raise an exception. Once you get your fix in, I'll check my fix into GYP so that we can catch these early before they start causing problems. PS: Hope we will be sitting close to each other soon. Definitely! Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Preventing keypress after accellerator?
You may refer to following bug reports: http://crbug.com/21624 http://crbug.com/21471 2009/11/6 Erik Arvidsson a...@chromium.org We have code to suppress the keypress event if keydown triggered a browser accelerator both inside and outside of WebKit. I don't understand why we want to prevent a keypress after a Ctrl+A or Ctrl+B keydown? Because Ctrl+A and Ctrl+B are special key accelerators which will be handled by the WebKit or the Browser. For example, Ctrl+B is for toggling bookmark bar. When pressing Ctrl+B, the key down event will be sent to the WebKit first, then it'll be forwarded to the Browser if the WebKit didn't handle or prevent it. Then the Browser will handle it and open or close the bookmark bar. Then if we still send the key press event of Ctrl+B to the WebKit, it might be handled by some javascript code in the web page and perform a specified action. Then the user will notice that two actions were triggered by pressing Ctrl+B. In most time, such behavior will confuse the user. Especially if the key triggers tab switching or other dramatic UI change. -- 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: Compiling error after I did a 'gclient sync'
On Thu, Nov 5, 2009 at 9:23 AM, Evan Martin e...@chromium.org wrote: On Wed, Nov 4, 2009 at 11:55 PM, Chase Phillips ch...@chromium.org wrote: FWIW I see the same error you see when I try to git clone the WebKit git repository again locally while git fetch on an existing repository works fine. I see you've mailed webkit-dev already, and I'm hoping someone there will be able to diagnose the problem. In the meantime, I recommend you use gclient sync to check out the WebKit source over Subversion so you're unblocked at least. Another option is to clone WebKit from some other git host. For example: git clone git://repo.or.cz/webkit.git You can then edit .git/config and change the origin URL to point at the canonical git.webkit.org, and run git fetch again, and it'll grab any newer data that didn't make it out to the mirror. Thanks. Chase, Evan. After webkit dev fixes their server problem, I try again using 'tools/sync-webkit-git.py', But I am getting a different error this time. And I have tried using 'git://repo.or.cz/webkit.git instead. That does not solve my problem either. $ tools/sync-webkit-git.py Desired revision: r50584. r50584 not available; fetching. remote: Counting objects: 948, done. remote: Compressing objects: 100% (350/350), done. remote: Total 731 (delta 469), reused 614 (delta 361) Receiving objects: 100% (731/731), 1011.18 KiB | 170 KiB/s, done. Resolving deltas: 100% (469/469), completed with 97 local objects. From git://git.webkit.org/WebKit 5af4058..968141f master - origin/master ERROR: Couldn't map r50584 to a git revision. --~--~-~--~~~---~--~~ 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: Compiling error after I did a 'gclient sync'
seems git.webkit.org/WebKit.git is out of sync? it only has r50565, but should have r50584 or later to build chromium. On Fri, Nov 6, 2009 at 11:42 AM, n179911 n179...@gmail.com wrote: On Thu, Nov 5, 2009 at 9:23 AM, Evan Martin e...@chromium.org wrote: On Wed, Nov 4, 2009 at 11:55 PM, Chase Phillips ch...@chromium.org wrote: FWIW I see the same error you see when I try to git clone the WebKit git repository again locally while git fetch on an existing repository works fine. I see you've mailed webkit-dev already, and I'm hoping someone there will be able to diagnose the problem. In the meantime, I recommend you use gclient sync to check out the WebKit source over Subversion so you're unblocked at least. Another option is to clone WebKit from some other git host. For example: git clone git://repo.or.cz/webkit.git You can then edit .git/config and change the origin URL to point at the canonical git.webkit.org, and run git fetch again, and it'll grab any newer data that didn't make it out to the mirror. Thanks. Chase, Evan. After webkit dev fixes their server problem, I try again using 'tools/sync-webkit-git.py', But I am getting a different error this time. And I have tried using 'git://repo.or.cz/webkit.git instead. That does not solve my problem either. $ tools/sync-webkit-git.py Desired revision: r50584. r50584 not available; fetching. remote: Counting objects: 948, done. remote: Compressing objects: 100% (350/350), done. remote: Total 731 (delta 469), reused 614 (delta 361) Receiving objects: 100% (731/731), 1011.18 KiB | 170 KiB/s, done. Resolving deltas: 100% (469/469), completed with 97 local objects. From git://git.webkit.org/WebKit 5af4058..968141f master - origin/master ERROR: Couldn't map r50584 to a git revision. --~--~-~--~~~---~--~~ 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 performance data
Try running a DOM benchmark while there is a content script that's waiting for a message from a background page. Adam On Thu, Nov 5, 2009 at 12:12 PM, Anton Muhin ant...@chromium.org wrote: Adam, all, I've got http://codereview.chromium.org/355047/ which should speed up accessing isolated worlds (it at least passes layout tests). Could someone either see if it helps or give me instructions how to bench it? yours, anton. On Tue, Oct 27, 2009 at 8:04 PM, Anton Muhin ant...@chromium.org wrote: On Tue, Oct 27, 2009 at 8:00 PM, Adam Barth aba...@chromium.org wrote: On Tue, Oct 27, 2009 at 9:52 AM, Anton Muhin ant...@chromium.org wrote: if we're sure accessing hidden property is a bottleneck, it should be easily solvable: for long time I was toying idea to compile this code into native, but didn't see compelling enough reason to do that. The easy way to measure it would be to hack stuff a bit and put data as in internal field or just add another getter to context. If you like, I can try to do something like that, but I need a simplistic benchmark to estimate performance gain. I suspect you'll see a performance gain on any simple DOM benchmark that runs in the isolated world. That code path is hit on every wrapper lookup. Ok, I will try to have a look at it this week. yours, anton. --~--~-~--~~~---~--~~ 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: history.back always fires onload in chromium - is it expected?
We might or might not decide to implement page cache (Darin is in the might not camp). In either case, this LayoutTest shouldn't drive that decision. Adam On Thu, Nov 5, 2009 at 12:17 PM, Tony Chang t...@chromium.org wrote: It sounds like the test depends on the page cache being enabled so we won't be able to pass it until we support the page cache ( http://code.google.com/p/chromium/issues/detail?id=2879 ). There are a couple options: 1) Try to implement the page cache-- abarth probably has some thoughts on this. 2) Skip the test for now and mention in the bug that it depends on the page cache. 3) Try to fix the test so it at least doesn't timeout if we don't support the page cache (I guess layoutTestController.overridePreference should return an error?). We would still fail the test, but it wouldn't slow down the layout tests. I would probably just do 2 for now. On Wed, Nov 4, 2009 at 3:26 AM, Kinuko Yasuda kin...@google.com wrote: Hi chromium developers, I've been looking into a layout-test bug 20341 (http://code.google.com/p/chromium/issues/detail?id=20341) and found that in chromium history.back always fires onload() even if WebKit's page cache is enabled (== WebKitUsePageCachePreferenceKey is set true). This makes running this test (LayoutTests/loader/go-back-to-different-window-size.html) cause an infinite loop both in test_shell and chromium. In a quick glance FrameLoaderClientImpl::canCachePage() and ApplicationCacheHost::canCacheInPageCache() are hard-coded to return false (with a comment saying that we manage the cache so reporting the page as non-cacheable), making FrameLoader always go through all the page-loading steps. Seems like this behavior (calls onload on history.back or not) differs across browsers: FireFox 3: NO Safari: NO IE8: YES Is it an expected behavior or do we need some fix 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] A question regarding to the keyboard event flow in the browser process.
(Ask this question again, in case you know the answer but missed this thread.) Thanks for your clear explanation. Now I have some questions regarding to the keyboard event flow: As I understand, a keyboard event will firstly be sent to the RenderWidgetHostView object, which will forward the event to the renderer. And then if the event was not handled by the renderer, it'll be sent to the TabContentsView object through RenderViewHostDelegate::View interface. And I find that there is a HandleKeyboardEvent method in TabContentsDelegate interface, so seems that the keyboard event should be sent to the delegate object through this method and handled there. But the current implements are: 1. In windows and Linux toolkit_views implementations, the focus manager will be called directly inside TabContentsView's HandleKeyboardEvent method to handle the keyboard event. And TabContentsDelegate::HandleKeyboardEvent method only gets called in windows implementation. 2. In Linux gtk implementation, the keyboard event is delivered to the BrowserWindowGtk object directly in TabContentsViewGtk::HandleKeyboardEvent method. TabContentsDelegate::HandleKeyboardEvent never gets called. 3. The Mac implementation is just similar than the Linux gtk code, which never calls TabContentsDelegate::HandleKeyboardEvent method. The logic here looks a little messy to me. So I'm wondering which is the most apporpriate logic here. As you said, a TabContents might not always be attached to a browser window, so should the TabContentsDelegate object always take charge of the unhandled keyboard event? Is it appropriate for the TabContentsView object to handle the event instead (like the current code does)? Regards James Su 2009/11/5 Ben Goodger (Google) b...@chromium.org - 隐藏引用文字 - As Mohammed notes, there are several diagrams in design docs under dev.chromium.org I use Omnigraffle for all my diagrams, it's fab. I use the same template for everything so the line styles etc all mean something. Lacking a collaborative web based version of Omnigraffle, I simply attach the graffle files to the docs so they can be edited later. A TabContentsView is the view portion of a TabContents. A TabContents is not necessarily always associated with a Browser. This is a mistake many people make - it's actually wrong to include browser.h etc in TabContents. TabContents communicates with Browser via the TabContentsDelegate interface which Browser implements. But sometimes the delegate is different... e.g. when you detach a tab and drag it around on screen the TabContentsDelegate is actually the DraggedTabController. And in ChromeFrame (which embeds a TabContents), the TabContentsDelegate is the ExternalTabContainer I think. -Ben On Wed, Nov 4, 2009 at 8:54 PM, James Su su...@chromium.org wrote: Hi, Recently, I'm studying the source code under chrome/browser and trying to understand the overall architecture, especially the relationship among those important classes, such as Browser, BrowserWindow, TabContents, TabContentsDelegate, TabContentsView, TabStripModel, RenderWidgetHost, RenderWidgetHostView, ExternalTabContainer, etc. Though I already have a rough picture of the architecture, there are still many aspects that I don't understand very well, such as: 1. The ownership among these classes. 2. The relationship between Browser and ExternalTabContainer classes, which both implement TabContentsDelegate interface. And how does an external tab work? 3. Does a TabContentsView always associate to a Browser? I'm wondering if there is any document to help me understand these aspects? I searched on dev.chromium.org but found nothing related. Thanks James Su --~--~-~--~~~---~--~~ 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: history.back always fires onload in chromium - is it expected?
Thanks for the replies, for now I'm going to do 2), i.e. mark the test SKIP, add a comment and wait for the decision for the page cache. (of course I don't think the test should determine the future of the page cache... :)) Kinuko On Fri, Nov 6, 2009 at 1:47 PM, Adam Barth aba...@chromium.org wrote: We might or might not decide to implement page cache (Darin is in the might not camp). In either case, this LayoutTest shouldn't drive that decision. Adam On Thu, Nov 5, 2009 at 12:17 PM, Tony Chang t...@chromium.org wrote: It sounds like the test depends on the page cache being enabled so we won't be able to pass it until we support the page cache ( http://code.google.com/p/chromium/issues/detail?id=2879 ). There are a couple options: 1) Try to implement the page cache-- abarth probably has some thoughts on this. 2) Skip the test for now and mention in the bug that it depends on the page cache. 3) Try to fix the test so it at least doesn't timeout if we don't support the page cache (I guess layoutTestController.overridePreference should return an error?). We would still fail the test, but it wouldn't slow down the layout tests. I would probably just do 2 for now. On Wed, Nov 4, 2009 at 3:26 AM, Kinuko Yasuda kin...@google.com wrote: Hi chromium developers, I've been looking into a layout-test bug 20341 (http://code.google.com/p/chromium/issues/detail?id=20341) and found that in chromium history.back always fires onload() even if WebKit's page cache is enabled (== WebKitUsePageCachePreferenceKey is set true). This makes running this test (LayoutTests/loader/go-back-to-different-window-size.html) cause an infinite loop both in test_shell and chromium. In a quick glance FrameLoaderClientImpl::canCachePage() and ApplicationCacheHost::canCacheInPageCache() are hard-coded to return false (with a comment saying that we manage the cache so reporting the page as non-cacheable), making FrameLoader always go through all the page-loading steps. Seems like this behavior (calls onload on history.back or not) differs across browsers: FireFox 3: NO Safari: NO IE8: YES Is it an expected behavior or do we need some fix 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] Google URL as KURL
Why we use Google URL as KURL in WebCore? Google URL and the default KURL implementation have some differences on validation rule, and they make a layout test failure of LayoutTests/fast/forms/ValidityState-typeMismatch-url.html . (See https://bugs.webkit.org/show_bug.cgi?id=29913 for the detail) Why we introduced GoogleURL-as-KURL instead of adding features to the default KURL? -- TAMURA Kent Software Engineer, Google --~--~-~--~~~---~--~~ 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: Google URL as KURL
On Thu, Nov 5, 2009 at 9:47 PM, TAMURA, Kent tk...@chromium.org wrote: Why we use Google URL as KURL in WebCore? brettw is the man you want. IIRC the main issues are that we need to have consistent validity enforcement throughout our entire browser stack, and modifying KURL to make it act like GURL was both harder and perhaps not as kosher with Apple (I don't really remember). 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: Preventing keypress after accellerator?
On Thu, Nov 5, 2009 at 17:58, James Su su...@chromium.org wrote: You may refer to following bug reports: http://crbug.com/21624 http://crbug.com/21471 2009/11/6 Erik Arvidsson a...@chromium.org We have code to suppress the keypress event if keydown triggered a browser accelerator both inside and outside of WebKit. I don't understand why we want to prevent a keypress after a Ctrl+A or Ctrl+B keydown? Because Ctrl+A and Ctrl+B are special key accelerators which will be handled by the WebKit or the Browser. For example, Ctrl+B is for toggling bookmark bar. When pressing Ctrl+B, the key down event will be sent to the WebKit first, then it'll be forwarded to the Browser if the WebKit didn't handle or prevent it. Then the Browser will handle it and open or close the bookmark bar. Then if we still send the key press event of Ctrl+B to the WebKit, it might be handled by some javascript code in the web page and perform a specified action. Then the user will notice that two actions were triggered by pressing Ctrl+B. In most time, such behavior will confuse the user. Especially if the key triggers tab switching or other dramatic UI change. I don't really agree with that argument. Neither Firefox nor Safari prevents the keypress after a command. IE just don't fire keypress events for Ctrl+Key with some exceptions. We don't send Ctrl+n, Ctrl+t nor Ctrl+w to the render view which I'm not considering changing. These should not be sent to the current view since they all remove or moves the user to a new view. -- erik -- 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: Preventing keypress after accellerator?
On Thu, Nov 5, 2009 at 10:49 PM, Erik Arvidsson a...@chromium.org wrote: On Thu, Nov 5, 2009 at 17:58, James Su su...@chromium.org wrote: if we still send the key press event of Ctrl+B to the WebKit, it might be handled by some javascript code in the web page and perform a specified action. Then the user will notice that two actions were triggered by pressing Ctrl+B. In most time, such behavior will confuse the user. Especially if the key triggers tab switching or other dramatic UI change. I don't really agree with that argument. Neither Firefox nor Safari prevents the keypress after a command. In what way do you disagree? Just saying Firefox and Safari do x alone doesn't mean x is right or sensical. You didn't actually give a reason why James' description is illogical. In the abstract it seems correct to me that if the browser handles something, it should not then also send it to the webpage. 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: Preventing keypress after accellerator?
You might want to read http://crbug.com/21624 first. It's the root cause for this change. I chose to fix that issue in such a generic way, because it's much more elegant than dealing with specific key bindings. If you encountered any issues caused by this change, please report them then let's think about how to deal with them. Regards James Su 2009/11/6 Erik Arvidsson a...@chromium.org On Thu, Nov 5, 2009 at 17:58, James Su su...@chromium.org wrote: You may refer to following bug reports: http://crbug.com/21624 http://crbug.com/21471 2009/11/6 Erik Arvidsson a...@chromium.org We have code to suppress the keypress event if keydown triggered a browser accelerator both inside and outside of WebKit. I don't understand why we want to prevent a keypress after a Ctrl+A or Ctrl+B keydown? Because Ctrl+A and Ctrl+B are special key accelerators which will be handled by the WebKit or the Browser. For example, Ctrl+B is for toggling bookmark bar. When pressing Ctrl+B, the key down event will be sent to the WebKit first, then it'll be forwarded to the Browser if the WebKit didn't handle or prevent it. Then the Browser will handle it and open or close the bookmark bar. Then if we still send the key press event of Ctrl+B to the WebKit, it might be handled by some javascript code in the web page and perform a specified action. Then the user will notice that two actions were triggered by pressing Ctrl+B. In most time, such behavior will confuse the user. Especially if the key triggers tab switching or other dramatic UI change. I don't really agree with that argument. Neither Firefox nor Safari prevents the keypress after a command. IE just don't fire keypress events for Ctrl+Key with some exceptions. Why don't you consider it's an issue of firefox and Safari? And actually, Safari on Windows does prevent the keypress after a command. We don't send Ctrl+n, Ctrl+t nor Ctrl+w to the render view which I'm not considering changing. These should not be sent to the current view since they all remove or moves the user to a new view. -- erik -- erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
