On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel e...@webkit.org wrote:
Has anyone spent any time trying to reduce the number of includes in
WebCore? I know we have:
https://trac.webkit.org/browser/trunk/WebKitTools/Scripts/find-extra-includes
But I feel like we still have way too many
would it be worth replacing #include wtf/*Ptr.h with #include
wtf/Forward.h in all header files?
On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel e...@webkit.org wrote:
Has anyone spent any time trying to reduce the number of includes in
WebCore? I know we have:
On Jun 8, 2010, at 3:17 PM, Eric Seidel e...@webkit.org wrote:
On my Intel Core 2 Duo MBP a full build takes over 1 hour. 5 years
ago, on my g4 laptop a full build took around 40m. :( We seem to be
slowly moving in the wrong direction.
Was that before or after SVG was enabled in the
I think were I to try attacking this, I would write a script to
generate a list of includes, and the number of cpp files which include
them.
Then I would work from the most-included end of that list, trying to
reduce the number of files include each include.
-eric
On Tue, Jun 8, 2010 at 4:04
On Tue, Jun 8, 2010 at 3:21 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel e...@webkit.org wrote:
Has anyone spent any time trying to reduce the number of includes in
WebCore? I know we have:
Hi,
For what it's worth I created all-in-one source files where they
didn't already exist (css, dom, editing, history, etc.), and was able to
drop my full rebuild time to a couple of minutes.
-Ben
On 6/8/2010 3:17 PM, Eric Seidel wrote:
Has anyone spent any time trying to reduce the number of
08.06.2010, в 15:21, Peter Kasting написал(а):
I know someone once suggested that the build would be sped up if the
#includes had longer paths (something like what happens in the
Chromium tree) so that the toolchain didn't have to spend as much
time scanning the (large) number of
In Safari 4, the following event handler would log nice smooth values when
scrolling:
// logs: -3, -9, -6, -48, ...
document.addEventListener(mousewheel, function(e) {
console.log(e.wheelDeltaY); });
In Safari 5, the mousewheel events have lost all precision, and are now big
ugly integral
Hi Nathan,
It is true that Safari now emits mousewheel events in increments of 120 for
compatibility reasons. However, there is no loss of granularity in the sense
that events are generated on fractional wheel ticks and are accelerated on
platforms that support it. The only difference is
On Jun 8, 2010, at 19:50, Andy Estes aes...@apple.com wrote:
The only difference is that you will see increments of 120 rather than
increments of 1
Perhaps a better way to say this is that the old wheelDelta values are now
simply being multiplied by 120. The precision hasn't changed, just
On Jun 8, 2010, at 7:50 PM, Andy Estes wrote:
Hi Nathan,
It is true that Safari now emits mousewheel events in increments of 120 for
compatibility reasons. However, there is no loss of granularity in the sense
that events are generated on fractional wheel ticks and are accelerated on
On Tue, Jun 8, 2010 at 8:34 PM, Nathan Vander Wilt nate-li...@calftrail.com
wrote:
What Safari 5's WebKit does is turn one line into 4800 (!) units instead
of 40. For Safari 5 the code above needs to read as follows to work the
same. You can see it isn't really more compatible at all:
var
12 matches
Mail list logo
