On Jan 15, 2010, at 10:37 AM, Peter Kasting wrote:
One thing to note is that Chromium uses neither a distributed VC
system nor Bugzilla, so your development process will look a little
different than with Mozilla patches.
Actually you can work on Chrome using git; it just takes a bit more
On Fri, Jan 15, 2010 at 10:20 AM, Rryk rryk...@gmail.com wrote:
I am implementing 3D rendering engine for Chromium and I need to
download huge scenes via Ajax. However I've noticed that asyncronous
Ajax requests are limited to 7-8 MB in size. If I try to download more
-- tab crashes (and in
I filed a bug on this, including a proposal for how to improve build
times by breaking DerivedSourcesAllInOne into four pieces (with a
workaround to keep it building all-in-one for configurations that
require that.)
https://bugs.webkit.org/show_bug.cgi?id=32128
I'll do it, if people think
On Mac* the WebCore Xcode project has a separate build target
webcore_bindings that contains DerivedSourcesAllInOne.cpp and a
handful of other files. This setup is really slowing down the build
process on my Mac Pro, because DerivedSourcesAllInOne takes much
longer to compile than any of
On Nov 30, 2009, at 12:31 PM, Dave MacLachlan wrote:
To turn on whitespace cleanup:
1) Go to XcodePreferences... and choose the Google panel.
2) Check the Correct Whitespace on Save checkbox, and you should
be good to go.
This feature is terrific for Google code, but bad for WebKit.
On Nov 21, 2009, at 10:40 AM, Drew Wilson wrote:
Can anyone explain (or point me at some docs) for how the
gcPrologue/gcEpilogue stuff should work, wrt the state of the underlying
handles (what assumptions does that code make)? I guess I don't really
understand when objects are taken out
On Nov 21, 2009, at 10:19 AM, Evan Martin wrote:
We should whitelist known compiler versions that build successfully
with -Werror, and then turn it off for the rest.
I did something in this spirit, though in kludgy form, a few weeks ago. After I
fixed all the current GCC warnings in WebCore,
On Nov 13, 2009, at 1:05 PM, Chase Phillips wrote:
Thanks for the feedback. gcl no longer requires --force to create CL in a
read-only checkout.
It wasn't actually a read-only checkout. WebKit doesn't use a separate URL for
the writeable repo; after you get commit privileges, your repo is
A few days ago I started getting an error when using gcl to create
changelists in my WebKit tree:
$ pwd
/Volumes/Yttrium/src/third_party/WebKit
$ gcl change foo
This is a read-only checkout. Retry in a read-write checkout or use --
force to override.
I don't get the error if I use gcl in the
On Nov 6, 2009, at 10:09 AM, mrossetti wrote:
1) Exclude individual database files. Journal files would still be
backed up.
2) Move the database files into a new, excluded directory. Both the
database files and their journals would not be backed up.
By 'journal' do you mean the temporary
On Nov 7, 2009, at 3:10 PM, Erik Corry wrote:
V8 strings get moved by the garbage collector so it's probably
unrealistic to access the internal strings externally.
Yes. Using V8 to back a StringImpl would require doing something about
the API call that returns a direct pointer to the
On Nov 9, 2009, at 2:22 PM, Erik Corry wrote:
How big are the strings we are talking about here on average?
In Dromaeo? I haven't checked; I was focusing on other metrics when I
ran those tests. You could run the four DOM Core benchmarks and
instrument the code to find out.
The DOM Query
On Nov 3, 2009, at 9:56 AM, Paweł Hajdan Jr. wrote:
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)
With the normal Mac key bindings it's Cmd-leftarrow, Shift-downarrow,
delete. If you want
On Oct 28, 2009, at 7:21 AM, Mark Mentovai wrote:
When I benchmarked this a few months ago on a fairly ordinary Mac, it
took nearly 100ms from the time that the browser started a renderer to
the time that the renderer was ready to service requests. A decent
chunk of that is load time and
On Oct 27, 2009, at 9:10 PM, Mike Belshe wrote:
From a performance perspective, it may be critical to use tcmalloc
to match safari performance. It was literally a 50% speedup on most
of the DOM perf when running on WinXP.
Yeah, I've profiled some of the Dromaeo benchmarks, and the DOM-
On Oct 28, 2009, at 11:08 AM, Mark Mentovai wrote:
My proposal is to fork a new process, exec the renderer, and then let
it bring itself up. That's exactly how we start renderers now. The
only difference is that I'm suggesting we should always keep a spare
one warmed up and ready to go,
On Oct 28, 2009, at 11:29 AM, Mark Mentovai wrote:
You could use this argument to shoot down keeping a spare warmed-up
renderer ready to go at other times, but I don't think it's relevant
to the startup case.
We weren't just talking about startup — f'rinstance, Darin mentioned
new-tab
Do we plan to switch the Mac build of Chromium to use tcmalloc instead
of the system malloc? I thought this was the case, but I can't find
any bug covering the task to do that. I'm on the memory task force,
and this decision could definitely have an impact (one direction or
the other) on
I spent some time this morning looking at Chrome's memory usage (on OS
X 10.5.8) while viewing flickr.com. First I simply started at my photo-
stream page and hit Reload over and over. Next I tried going through
all of my photos one by one. I used the RPRVT column in 'top', and the
'heap'
A big V8/DOM memory leak I was chasing down turns out to be not a real
leak, it's just that it takes five full GCs after closing a document
for its resources to be freed. I'd been getting bored after two GCs,
so it wasn't till Ivan mentioned the stickiness of the generated-
function caches
On Sep 29, 2009, at 10:31 AM, Anton Muhin wrote:
This 5 number looks really odd. Do you have a simple way to reproduce
it? I'd love to have a look.
Ivan suggested to me that it might take five to ten GCs; he said
something about cached generated (JITted?) functions that have a
context
tab. In memory, multiple DOMWindow objects are hanging around, likely because of reference
loops between WebCore and V8. In support of this theory, disabling JS entirely makes the problem go away.
--Jens Alfke, Sept. 2009
Google
Yahoo
Apple
Are there any utilities that can be used to see which native (DOM)
objects are being referenced by JavaScript objects, and to follow
references between JS objects to understand what's keeping an object
from being GCd?
(I'm working on reducing Chrome memory usage. One thing I've
On Sep 22, 2009, at 2:54 PM, Mikhail Naganov wrote:
I'm working on showing JS objects retainers. But this only works for
objects that live inside V8's heap.
That would still be useful — I'd love to be able to look at all the
'Window' objects in the heap and what ref chain is keeping them
Just for fun I turned on -Wall -Werror when building webcore on my
Mac. The majority of the warnings were from our own code, actually —
nothing serious, but several reports of unused variables/functions and
class member initialization order mismatches, mostly in the V8 glue.
Seems like
On Sep 2, 2009, at 10:36 AM, Mike Mammarella wrote:
Actually the Linux version already had the dialog, and the OS X
version doesn't need it (at the moment) since there is no built-in
password manager
Yeah, password management on Mac OS is done through the system
Keychain Access app; we
The use of blue-underlined links for actions, as opposed to
navigation, is unfortunately common in a number of Google's web UIs
(like Sites and Docs.) I'm not sure what the official position is on
it at Google, or among the web UI design community at large, but I
personally think it's a
On Aug 7, 2009, at 5:25 PM, Peter Kasting wrote:
Yep. You MUST have the depot_tools svn ahead of the cygwin svn and
use only that to check out Chromium. I thought we noted this
somewhere...
Thanks for the tip. I'm just going through this setup right now,
though it sounds like I'll be
I just submitted r21551, which simply turns off ENABLE(DATAGRID) in
WebCore. This CL produced build errors on the Linux and Windows try
bots until I told them to --clobber; then it succeeded. Could be
something to do with stale generated V8 bindings.
So there's a chance that your local
On Jul 16, 2009, at 9:48 AM, darrel karisch wrote:
I've produced a proposal for a CSS Scripting Layout specification.
I've extended Chrome as a sample implementation.
Embedding arbitrary JavaScript expressions inside CSS turns out to be
pretty dangerous from a security standpoint. MSIE has
On Jul 15, 2009, at 3:50 PM, Albert J. Wong (王重傑) wrote:
Since you built it, you should be able to fire it up in a debugger
and see where it's dying. That's what I'd try first.
More precisely:
* Open chrome.xcodeproj
* Make sure the chrome executable is active
* Choose Run Activate
On Jul 9, 2009, at 11:44 AM, PhistucK wrote:
It seems like status is a reserved word (so it does not give you
the HTMLObject you wanted, but something internal that cannot be
reached), try to use some other name.
Try declaring it with var on first usage and see if that helps. (You
32 matches
Mail list logo
