On Tue, Jun 8, 2010 at 8:34 PM, Nathan Vander Wilt 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 delta;
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 Jun 8, 2010, at 19:50, Andy Estes 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 the atomic
unit
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 that
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 mul
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 different
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 o
On Tue, Jun 8, 2010 at 3:21 PM, Peter Kasting wrote:
>
> On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel 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
>>
>
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 PM,
On Jun 8, 2010, at 3:17 PM, Eric Seidel 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 engine? :) In gen
would it be worth replacing #include with #include
in all header files?
On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel 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-extr
On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel 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 unnecessary includ
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 unnecessary includes. I
failed to find any tools for reducing build times or incl
isFocusedAndActive is asking if your frame is the focused frame and if the
window that contains your frame is also active. I would guess that you are not
setting the state of your frames/windows correctly. If your window is
considered inactive or if your frame is not considered focused, then :
So I was just about ready to post a potential patch for keeping track of all
cells that lie on a given grid slot. It seems that information is
insufficient for correct rendering.
Consider the attached test case:
1 R1C4 spans 4 rows, and should be drawn first.
2. R2C1 spans 4 columns and overlaps
Hello list,
We're running a customized build of WebKit (actually a DirectFB port) and we
are experiencing problems with the css :focus pseudo-class. We use webkit as
GUI renderer and, when changing the focused element through JavaScript
(using the focus function), the style associated to the :foc
16 matches
Mail list logo
