On Fri, Nov 20, 2009 at 3:00 PM, Mark Mentovai m...@chromium.org wrote:
James Robinson wrote:
What's the benefit of omitting the virtual destructor?
The benefit is that the destructor stays out of the vtable, which will
potentially reduce the vtable size and save a layer of indirection. I
Now from the right account.
yours,
anton.
On Mon, Nov 23, 2009 at 3:00 PM, Anton Muhin ant...@google.com wrote:
On Sun, Nov 22, 2009 at 1:45 AM, Drew Wilson atwil...@chromium.org wrote:
I guess I don't really understand why gcPrologue has that
ASSERT(wrapper.IsWeak()) then, unless there's
On Sat, Nov 21, 2009 at 1:52 PM, Chris Bentzel cbent...@google.com wrote:
Have there been any thoughts about adding gcl patch and unpatch commands
which will grab the file diffs as well as duplicate the CL metadata in
src/.svn/gcl_info?
There's the gcl metadata and the svn metadata. Webkit
On Fri, Nov 20, 2009 at 23:34, Darin Fisher da...@chromium.org wrote:
We could define a function that must be called before you can use code in
base/. You could add a call to this everywhere that we currently create the
AtExitManager. Or, maybe we could combine those somehow.
Thanks for
You could also try adding swap. It isn't ideal, but it might at least
let you build until you can add more RAM. It can take about 4GB to
link a debug build. Another option is to build in release mode, which
should require less RAM.
Michael
On Mon, Nov 23, 2009 at 12:12 AM, Craig Schlenter
I would like to add that I am having the same problem when I try to
build Chromium from the tarball. I have searched through my documents,
the un-extracted tarball, and even the online source code and could
not find the file. On the same note, if you just want to run Chromium
OS (like I do), the
Just an update. The guy to blame was CreateDIBSection used in
skia/ext/bitmap_platform_win.cc
According to http://msdn.microsoft.com/en-us/library/dd183494(VS.85).aspx :
If hSection is NULL, the system allocates memory for the DIB. In this
case, the CreateDIBSection function ignores the
If you are just testing the Google Chrome build and you don't need
symbols, you can always comment out the -gstabs line in
build/common.gypi.
On Sat, Nov 21, 2009 at 9:10 PM, David Moore davemo...@google.com wrote:
Problem solved. Coincident with using the new linker I started building the
Re http://crbug.com/27195 https://bugs.webkit.org/show_bug.cgi?id=31802 :
Dan Bernstein says that Core Text on Leopard has performance issues vs ATSUI
so I'm going to look into switching APIs at runtime rather than compile
time.
So we'd use ATSUI 10.6 Core Text = 10.6 .
Best regards,
Thanks Nico,
I'll run some numbers.
Best regards,
Jeremy
On Mon, Nov 23, 2009 at 11:15 PM, Nico Weber tha...@chromium.org wrote:
Did you do measuring if it's actually slower on 10.5? The CoreText backend
for MacVim is much faster than the ATSUI backend from what I've heard (then
again,
One command line tool I have sometimes wanted when debugging, is a way
to dump out a cached response from the disk cache.
The only way I know to do this currently is create a profile and load
it in chrome, then use about:cache to print the response as hex.
(At which point you still need to
Hello all,
I'm happy to announce that the developer area of our extensions
gallery is now open:
https://chrome.google.com/extensions
You can upload your extensions, edit their details, add screenshots
and videos, test the autoupdate system, and begin publishing your
download URL.
We are
As an aside, have we looked at using DirectWrite() on Windows?
-- Dirk
On Mon, Nov 23, 2009 at 12:58 PM, Jeremy Moskovich jer...@chromium.org wrote:
Re http://crbug.com/27195 https://bugs.webkit.org/show_bug.cgi?id=31802 :
Dan Bernstein says that Core Text on Leopard has performance issues
On Mon, Nov 23, 2009 at 2:26 PM, Eric Roman ero...@chromium.org wrote:
One command line tool I have sometimes wanted when debugging, is a way
to dump out a cached response from the disk cache.
There is a dump_cache.exe utility; it can copy a cache or copy the whole
thing to a set of disk
*UI Jank Task Force Status Update*
*
*
*Agenda*
*
*
Excellent progress last week
- Spellchecking now in done in the renderer; moved a lot of disk access
off I/O thread.
- Launching child processes now done in background thread; off of UI / IO
threads.
- 30% improvement on Linux
Hi,
Any kind soul willing to review a simple regexp parser? 211 lines.
http://codereview.chromium.org/439008
Thanks,
James Hawkins
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
On Mon, Nov 23, 2009 at 2:58 PM, Glenn Wilson gwil...@chromium.org wrote:
Investigating using a flat file for safebrowsing instead of SQLite (need to
recreate bloom filter and watch disk I/O)
jam crunched some numbers here. During the bloom filter recreation process
we read about 50 MB and
On Mon, Nov 23, 2009 at 2:51 PM, Dirk Pranke dpra...@chromium.org wrote:
As an aside, have we looked at using DirectWrite() on Windows?
crbug.com/25541
(No)
PK
--
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
Sorry, two corrections:
- The promo cookie was removed from the new tab page startup, but local
tests show cookies are still being loaded. Investigation is ongoing.
- The disk access run time check is actually a script that uses Windbg
to detect these types of accesses. The next
Also: will you be allowing extensions hosted on Google to have a custom
update URL? I'm guessing no, but thought I'd find out for sure.
Our plan has been for the gallery to just handle autoupdate for you. Any
reason you'd want to do it yourself? If it's for usage tracking purposes,
one
Automatically closing tree for net_unittests on Modules XP (dbg)
http://build.chromium.org/buildbot/waterfall/builders/Modules%20XP%20%28dbg%29/builds/19523
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Modules%20XP%20%28dbg%29
--= Automatically closing tree for net_unittests
Don't we already have a real regexp engine in WebKit. Why add another? Did
you consider wrapping WebCore::RegularExpression with a WebKit API?
-Darin
On Mon, Nov 23, 2009 at 3:09 PM, James Hawkins jhawk...@chromium.orgwrote:
Hi,
Any kind soul willing to review a simple regexp parser? 211
Automatically closing tree for test_shell_tests on Webkit Mac10.5 (dbg)(3)
http://build.chromium.org/buildbot/waterfall/builders/Webkit%20Mac10.5%20%28dbg%29%283%29/builds/7458
http://build.chromium.org/buildbot/waterfall/waterfall?builder=Webkit%20Mac10.5%20%28dbg%29%283%29
--= Automatically
I'm looking at this; not sure that it is anything I caused
Mike
On Mon, Nov 23, 2009 at 8:18 PM, build...@chromium.org wrote:
http://build.chromium.org/buildbot/waterfall/
Automatically closing tree for test_shell_tests on Webkit Mac10.5
(dbg)(3)
Dirk suspects this was caused by his:
http://chrome-buildbot.corp.google.com:8010/builders/Webkit%20(dbg)(3)/builds/10311
http://chrome-buildbot.corp.google.com:8010/builders/Webkit%20(dbg)(3)/builds/10311
Mike
On Mon, Nov 23, 2009 at 8:23 PM, Mike Belshe mbel...@google.com wrote:
I'm
Greetings Jeremy,
This is just for your information.
It seems WebCore/platform/graphics/mac/ComplexTextControllerCoreText.cpp
uses CTRunGetAdvancesPtr() and CTRunGetAdvances(), which are available
only on 10.6 or later. (This might be a reason why WebKit doesn't use
Core Text for Leopard?)
(*1)
Thanks Hironori,
I thought so too at the beginning but it turns out that they are available,
just not declared in public headers. The WebKit bug I linked to has a patch
that switches us to Core Text on 10.5 10.6.
I'll do some perf tests and then we can make a decision based on that.
Best
27 matches
Mail list logo