Re: [webkit-dev] Position on new syntax in mediaqueries-4

[Antti Koivisto via webkit-dev]

We are supportive. Much of the needed code was already written for the
container queries (as you know) so implementation should be relatively easy.


  antti


On Mon, Apr 11, 2022 at 1:57 PM Anders Hartvoll Ruud via webkit-dev <
webkit-dev@lists.webkit.org> wrote:

> For example, in mediaqueries-4 you can do e.g. @media (width >= 100px)
> rather than @media (min-width: 100px). In addition, the spec level adds
> support for 'not' (in other places than just the start), 'or', nesting and
> /unknown handling.
>
> Do you have any plans to implement this? (Or plans to _not_ implement).
>
> Relevant Webkit bug: https://bugs.webkit.org/show_bug.cgi?id=180234
>
> Thanks,
> Anders
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] in WebKit?

[Antti Koivisto]

I landed the updated behavior.


  antti

On Mon, Oct 19, 2020 at 11:29 AM Anders Hartvoll Ruud 
wrote:

> Yes, there's css/selectors/is-where-error-recovery.tentative.html
>
> (.tentative tag to be dropped momentarily).
>
> On Sat, Oct 17, 2020 at 10:17 AM Antti Koivisto  wrote:
>
>> Seems like a sensible change. Are there WPT tests for this behavior
>> already?
>>
>>
>>   antti
>>
>> On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud <
>> andr...@chromium.org> wrote:
>>
>>> Hi,
>>>
>>> We are about to ship support for :is() and :where() in Chromium,
>>> including support for .
>>> <https://drafts.csswg.org/selectors/#typedef-forgiving-selector-list> As
>>> far as I understand, :is() in Safari 14 takes a regular ,
>>> and Chromium API owners are concerned that this is a potential source of
>>> interop problems.
>>>
>>> Are there any plans to implement the  behavior
>>> in WebKit as well?
>>>
>>> Thanks,
>>> Anders
>>>
>>> FYI: https://bugs.webkit.org/show_bug.cgi?id=217814
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] in WebKit?

[Antti Koivisto]

Seems like a sensible change. Are there WPT tests for this behavior already?


  antti

On Fri, Oct 16, 2020 at 8:06 PM Anders Hartvoll Ruud 
wrote:

> Hi,
>
> We are about to ship support for :is() and :where() in Chromium, including
> support for .
>  As
> far as I understand, :is() in Safari 14 takes a regular ,
> and Chromium API owners are concerned that this is a potential source of
> interop problems.
>
> Are there any plans to implement the  behavior in
> WebKit as well?
>
> Thanks,
> Anders
>
> FYI: https://bugs.webkit.org/show_bug.cgi?id=217814
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit's position on @property

[Antti Koivisto]

We like declarative @property and will definitely consider implementing it.
We like CSS.registerProperty less since it is a performance footgun.


   antti

On Fri, Apr 24, 2020 at 10:25 AM Anders Hartvoll Ruud 
wrote:

> Thanks for the response. I did read through that issue at some point, but
> I didn't detect an underlying endorsement. :-)
>
> On Fri, Apr 24, 2020 at 12:33 AM Simon Fraser 
> wrote:
>
>> In general we are supporting. We've given some feedback here: <
>> https://github.com/w3c/css-houdini-drafts/issues/940>
>>
>> Simon
>>
>> On Apr 23, 2020, at 2:44 AM, Anders Hartvoll Ruud 
>> wrote:
>>
>> Hi,
>>
>> In Blink there's currently an intent to ship
>> 
>>  @property from CSS Properties & Values
>> .
>> I've noticed that there's an in-progress implementation of
>> CSS.registerProperty in WebKit, and I'm wondering if you're also
>> considering implementing @property, or you have any thoughts on it in
>> general.
>>
>> Anders
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

[Antti Koivisto]

On Sat, Nov 2, 2019 at 1:38 AM Ryosuke Niwa  wrote:

> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro 
> wrote:
>
>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:
>> > Namely, some people write a lambda as:
>> > auto x = [] () { }
>> >
>> > with a space between [] and () while others would write it as:
>> >
>> > auto x = []() { }
>>
>> 🔧: I omit the () when there are no parameters, as in these examples.
>>
>
> I guess that's another thing we should decide. Should we, or should we not
> have () when there are no arguments.
>

I think this is easily settled by voting via exiting practice. We have 1287
instances of [&] { and 107 instances of [&]() { and &] () { across the
whole WebKit.


   antti


>
> I think we usually err on the side of more concise form but I do prefer
> having () so that it's clear it's a function. Otherwise, it can look like a
> code block start & end.
>
> - R. Niwa
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [Styling] Space between [] and () in C++ lambdas

[Antti Koivisto]

On Fri, Nov 1, 2019 at 10:50 PM Yusuke Suzuki  wrote:

>
> > On Nov 1, 2019, at 11:53, Michael Catanzaro 
> wrote:
> >
> > On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:
> >> Namely, some people write a lambda as:
> >> auto x = [] () { }
> >> with a space between [] and () while others would write it as:
> >> auto x = []() { }
> >
> > 🔧: I omit the () when there are no parameters, as in these examples.
> >
> > No preference on spacing.
>
> I like having a space here, because this rule is simpler to me.
> If we always have a space between them, this is clear that the above case
> is written in `[] { }` instead of `[]{ }`.
>

I prefer not having the redundant space in [](). It also makes logical
sense to me to keep the lambda signature together. I started using lambdas
with space there, dropped it later, and suffered no adverse consequences.

As for existing practice, WebCore favors spaceless ]( about 2:1 but across
the entire WebKit it is closer to 1:1.

We always put space before { } block, I don't think that is really in
question here, or creating any inconsistencies.


   antti


>
> -Yusuke
>
> >
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Introducing WTF::makeUnique and WTF::makeUniqueWithoutFastMallocCheck

[Antti Koivisto]

On Mon, Aug 19, 2019 at 10:25 AM Yusuke Suzuki  wrote:

> Hello WebKit folks!
>
> I would like to announce that I’ve just landed the patch which introduces
> `WTF::makeUnique` and `WTF::makeUniqueWithoutFastMallocCheck` in
> https://trac.webkit.org/changeset/248846.
> They are drop-in-replacement to std::make_unique, and we should not use
> std::make_unique after that patch is introduced.
> I’m planning to add cpplint check for `std::make_unique` to avoid the use
> of that.
>
> The motivation behind this change is the following.
>
> 1. Our typical way of allocating heap memory is three-fold. Using
> containers (Vector etc.), RefCounted, and std::unique_ptr.
> 2. Containers and RefCounted are covered well by FastMalloc.
> 3. But std::unique_ptr case, we missed using FastMalloc in many places so
> far.
>
> Even in very recently written code, we missed FastMalloc annotation. For
> example, we sometimes create a data structure just like a struct, and
> allocate it with make_unique.
>
> struct XXXData {
> ...
> };
>
> m_data = std::make_unique();
>
> We missed WTF_MAKE_STRUCT_FAST_ALLOCATED annotation in XXXData so
> frequently so that the allocation of XXXData ends up being allocated from
> system-malloc.
>
> This WTF::makeUnique adds one `static_assert` over std::make_unique: the
> static_assert ensures T is FastMalloced or IsoHeap-allocated.
> Otherwise, we see compile-error.
>

Could WTF::makeUnique simply use FastMalloc by default? We could then
remove most of these messy annotations.

This would require replacing std::unique_ptr with a type that knows how to
free the objects correctly (bring back OwnPtr!) but that doesn't seem like
a big deal. It wouldn't play well with mixed use of OwnPtr and new/delete
but that should be avoided in any case.


   antti


> This mechanism surprisingly found so many classes that do not have
> WTF_MAKE_FAST_ALLOCATED / WTF_MAKE_STRUCT_FAST_ALLOCATED in our code base.
>
> If the type T comes from ThirdParty and if we cannot annotate T with
> FAST_ALLOCATED, we can use WTF::makeUniqueWithoutFastMallocCheck explicitly
> as a fallback.
>
> More detailed explanation behind why we took this design (instead of
> allocating FastMalloced-memory automatically when using makeUnique()
> etc.) is described in ChangeLog in
> https://trac.webkit.org/changeset/248846/webkit.
> I already annotated missed structs / classes with WTF_MAKE_FAST_ALLOCATED
> in https://trac.webkit.org/changeset/248762. So, now I think 99% of
> allocations in WebKit-itself are handled well by FastMalloc.
>
> -Yusuke
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone maintaining Nicosia scrolling code?

[Antti Koivisto]

On Sat, Feb 23, 2019 at 1:30 PM  wrote:

> On Sat, Feb 23, 2019, at 2:47 AM, Simon Fraser wrote:
> > There’s a bunch of code in Source/WebCore/page/scrolling/nicosia/ that
> > I keep breaking with scrolling tree refactoring. Most of it it stubs.
> > Is anyone maintaining this code, because it obviously doesn’t work, and
> > I’d like to remove the maintenance burden.
> >
>
> I added the stubs there, and was planning to start adding actual
> implementations there in the following weeks, now that a new release cycle
> was just entered.
>
> I wouldn't mind disabling or removing the code temporarily in order to
> enable you an easier time refactoring around it.


Please do. It is unreasonable to push maintenance burden of this dead code
to people who are working on async scrolling. See
https://bugs.webkit.org/show_bug.cgi?id=198292 for an example.


   antti


> But given that the async scrolling capability is something we plan to add
> support for in the WPE and GTK ports, I'd appreciate some input about the
> scope and the timeframe of your work and possibility of sharing as much of
> the implementation as possible between different ports.
>
> Cheers,
> Zan
>
> > Simon
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rename AtomicString to AtomString

[Antti Koivisto]

Sounds good to me.


  antti

On Wed, Jan 30, 2019 at 6:33 PM Darin Adler  wrote:

> So, did we reach consensus that we should rename AtomicString to
> AtomString?
>
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Watch out for std::optional's move constructor

[Antti Koivisto]

On Tue, Dec 18, 2018 at 3:18 AM Geoffrey Garen  wrote:

> Again, the C++ standard does not say that moving from an object leaves the
> object in an undefined state.
>
> The C++ standard does say:
>
> Objects of types defined in the C++ standard library may be moved from
> (12.8). Move operations may be explicitly specified or implicitly
> generated. Unless otherwise specified, such moved-from objects shall be
> placed in a valid but unspecified state.
>
>
> A few ways this differs from the claim that moving from an object leaves
> the object in an undefined state:
>
> (1) The standard makes no mention of objects in general, only of objects
> in the C++ standard library;
>
> (2) Even for objects in the C++ standard library, the standard makes no
> mention of objects in general, only of objects that are not “otherwise
> specified”;
>

For example, std::unique_ptr does have a fully specified moved-from state
that can be relied on.


   antti


> (3) The standard avoids undefined-ness entirely and instead specifies a
> *valid* but unspecified state.
>
> I think it is accurate to say that the C++ standard specifies that *some* 
> objects
> *in the standard library* have *valid but unspecified* state when moved
> from.
>
> I think it’s also accurate to say that a function that accepts an rvalue
> reference as an argument does not promise to move from that rvalue
> reference.
>
> I think both of these statements are compatible with specifying what
> happens *in WebKit libraries* when we* do move from *an object.
>
> Geoff
>
> On Dec 17, 2018, at 5:04 PM, Alex Christensen 
> wrote:
>
> We can definitely make our own WTF::Optional instead of using
> std::optional and change its move constructor/operator= and I personally
> think that would not be worth it but if I’m in the minority I’ll deal with
> it.  We cannot diverge from the C++ standards that say that moving from an
> object leaves the object in an undefined state, and right now in WebKit we
> are relying quite a lot on that undefined state.  I think that is the
> bigger problem that Chris was trying to solve.
>
> On Dec 17, 2018, at 4:32 PM, Ryosuke Niwa  wrote:
>
> Let me add this.
>
> The situation we have here is analogous to having a member function
> "move()" which leave std::optional in undefined state as in:
>
> std::optional a;
> std::optional b = a.move();
>
> would leave a in some undefined state. I don't care what C++ standards say
> or what STL does. That's insane.
> Every object should remain in a well defined state after performing an
> operation.
>
> - R. Niwa
>
>
> On Mon, Dec 17, 2018 at 4:22 PM Ryosuke Niwa  wrote:
>
>> It's true that WTFMove or std::move doesn't do anything if the moved
>> variable is not used because WTFMove / std::move is just a type cast.
>>
>> However, that behavior is orthogonal from the issue that calling WTFMove
>> / std::move on std::optional, and the returned value is assigned to another
>> std::optional, the original std::optional will be left a bad state.
>>
>> I completely disagree with your assessment that this calls for the use of
>> std::exchange.
>>
>>
>> On Mon, Dec 17, 2018 at 3:55 PM Alex Christensen 
>> wrote:
>>
>>> Let me give a concrete example on why, even with our nice-to-use WTF
>>> types, the state of a C++ object is undefined after being moved from:
>>>
>>> #include 
>>> #include 
>>> #include 
>>>
>>> class Test : public RefCounted { };
>>>
>>> void useParameter(RefPtr&& param)
>>> {
>>>   RefPtr usedParam = WTFMove(param);
>>> }
>>>
>>> void dontUseParameter(RefPtr&&) { }
>>>
>>> int main() {
>>>   RefPtr a = adoptRef(new Test);
>>>   RefPtr b = adoptRef(new Test);
>>>   std::cout << "a null? " << !a << std::endl;
>>>   std::cout << "b null? " << !b << std::endl;
>>>   useParameter(WTFMove(a));
>>>   dontUseParameter(WTFMove(b));
>>>   std::cout << "a null? " << !a << std::endl;
>>>   std::cout << "b null? " << !b << std::endl;
>>>   return 0;
>>> }
>>>
>>> // clang++ test.cpp -I Source/WTF -L WebKitBuild/Debug -l WTF -framework
>>> Foundation -L /usr/lib -l icucore --std=c++17 && ./a.out
>>>
>>> // a null? 0
>>>
>>>
>>> // b null? 0
>>>
>>>
>>> // a null? 1
>>>
>>>
>>> // b null? 0
>>>
>>>
>>>
>>>
>>> As you can see, the internals of callee dontUseParameter (which could be
>>> in a different translation unit) affects the state of the local variable b
>>> in this function.  This is one of the reasons why the state of a moved-from
>>> variable is intentionally undefined, and we can’t fix that by using our own
>>> std::optional replacement.  If we care about the state of a moved-from
>>> object, that is what std::exchange is for.  I think we should do something
>>> to track and prevent the use of moved-from values instead of introducing
>>> our own std::optional replacement.
>>>
>>> On Dec 17, 2018, at 2:47 PM, Ryosuke Niwa  wrote:
>>>
>>> Yeah, it seems like making std::optional more in line with our own
>>> convention provides more merits than downsides here. People are using
>>> WTFMove as if

Re: [webkit-dev] Removing support for CSS regions

[Antti Koivisto]

This is a blocker for making the render tree more secure and for
architectural progress there in general. The feature is extremely invasive
and has design issues. I think the security benefits of removing it alone
are worth taking a small regression risk.


  antti

On Wed, Aug 2, 2017 at 10:00 AM, Ryosuke Niwa  wrote:

> On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling  wrote:
> >
> >> On 2 Aug 2017, at 01:03, Ryosuke Niwa  wrote:
> >>
> >> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling 
> wrote:
> >>> Some time has passed, and it seems that adoption of CSS regions on the
> web is not gonna happen.
> >>>
> >>> Blink has long since removed their support.
> >>> Firefox never supported it AFAIK.
> >>> (The new) IE has some amount of support behind a prefix, but no plans
> to unprefix AFAIK.
> >>>
> >>> I think it’s time we remove the code from WebKit, and relieve
> ourselves of the maintenance burden.
> >>> This should also open up numerous opportunities for clean-up and
> optimization.
> >>>
> >>> If you know of any reason to keep the feature, such as a major website
> or WebKit client depending on it, do speak up now!
> >>
> >> Since we've been shipping CSS regions for a while, I think the first
> >> step we should take would be disabling the feature on trunk, and put
> >> that into STP and other ports' releases so that we can easily revert
> >> the change if we find out any Web content to be broken when the
> >> feature is disabled.
> >
> >> Unless there is evidence of at least one major site or client depending
> on CSS regions, I don’t agree that such a slow removal process is necessary.
> >
> > IMO doing that would only further increase the maintenance burden
> incurred by the feature, since we’d have to add tons of runtime checks
> throughout the codebase.
>
> Given my concern is the compatibility, not the maintenance cost, what
> is the evidence that nobody is relying on this feature?
>
> It seems a little crazy to remove a feature that has been available
> (prefixed) since Safari 6.2 without any prior warning or gathering any
> usage metrics at all.
>
> Also see: https://trac.webkit.org/wiki/DeprecatingFeatures
>
> > I would feel differently if we were pioneering this removal, but since
> we’ve already seen it succeed in Blink I’m far less concerned.
>
> I'm more concerned about iOS and macOS apps that use WebKit than the
> Web content in the wild.
>
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] !!Tests for equality comparison

[Antti Koivisto]

This is a good change as long as we are just relaxing the rule rather than
mandating ==. I think ! makes a lot of sense when testing for emptiness:

if (!container.size())
   ...

if (!count)
   ...

but == should be used for testing things where 0 is just another number,
like indexes:

if (index == 0)
   ...


   antti


On Fri, Apr 28, 2017 at 11:00 AM, Keith Miller 
wrote:

> Is there any opposition to relaxing this rule? Speak now or forever hold
> your piece! (not really but I would be curious to hear opposition).
>
> Cheers,
> Keith
>
> On Apr 27, 2017, at 10:32 PM, Carlos Garcia Campos 
> wrote:
>
> El jue, 27-04-2017 a las 16:06 -0700, JF Bastien escribió:
>
> Hello C++ fans!
>
> The C++ style check currently say:
> Tests for true/false, null/non-null, and zero/non-zero should all be
> done without equality comparisons
>
> I totally agree for booleans and pointers… but not for integers. I
> know it’s pretty much the same thing, but I it takes me slightly
> longer to process code like this:
>
> int numTestsForEqualityComparison = 0:
> // Count ‘em!
> // …
> if (!numTestsForEqualityComparison)
>   printf(“Good job!”);
>
> I read it as “if not number of tests for equality comparison”. That's
> weird. It takes me every slightly longer to think about, and I’ve
> gotten it wrong a bunch of times already. I’m not trying to check for
> “notness", I’m trying to say “if there were zero tests for equality
> comparison”, a.k.a.:
>
> if (numTestsForEqualityComparison == 0)
>   printf(“Good job!”);
>
> So how about the C++ style let me just say that? I’m not suggesting
> we advise using that style for integers everywhere, I’m just saying
> it should be acceptable to check zero/non-zero using equality
> comparison.
>
>
> I agree, it's also quite confusing when using strcmp, because !strcmp
> means the strings are equal. It's not only more difficult to read, I've
> seen patches with wrong strcmp checks because of that.
>
>
> I also think this could be solved by #defining a success a C call positive
> result that is 0 (e.g. CCallSuccess), regardless of the choice we make here.
>
>
>
> !!Thanks (i.e. many thanks),
>
> JF
>
> p.s.: With you I am, fans of Yoda comparison, but for another day
> this will be.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] SVN trouble

[Antti Koivisto]

Hi,

Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some sort
of SVN problem. Please hold commits until this is resolved.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Antti Koivisto]

Why is the PAL namespace inside the WebCore namespace? Couldn't it just be
a top-level namespace (even if it currently happens to live in the WebCore
project)?

#include  would be more consistent with existing headers than
.


  antti

On Wed, Jan 11, 2017 at 7:24 AM, Myles C. Maxfield 
wrote:

> After 18 months of no progress, Don Olmstead and I are getting the band
> back together!
>
> We’ve uploaded a patch to https://bugs.webkit.org/show_bug.cgi?id=143358 which
> incorporates feedback from many different stakeholders (and as such, the
> direction is a little different than where I was going with this in the
> beginning).
>
> First of all, this isn’t a new project; instead, it’s a new target inside
> the WebCore project. The target creates a static library which gets linked
> into WebCore, which means that the enforcement mechanism can’t be done by
> the linker. Instead, the layering will be enforced by a Python script,
> triggered as an extra build step, which checks the symbol names inside the
> .a file as well as #include directives in source code.
>
> We opted for WebCore to include files using “#include ” instead
> of just including Foo.h. Similarly, we are putting symbols inside the PAL
> namespace, which is a child of the WebCore namespace. Therefore, inside
> WebCore, you use PAL things by specifying “PAL::Foo”.
>
> The first thing to move into PAL is the “crypto” subfolder, which is a
> good candidate because it’s small, simple, yet also has platform-dependent
> implementations.
>
> We would love your feedback on this approach to help make the dream a
> reality!
>
> Thanks,
> Myles and Don
>
> On Mar 22, 2015, at 4:40 PM, Gavin Barraclough 
> wrote:
>
> On Mar 22, 2015, at 4:35 AM, Maciej Stachowiak  wrote:
>
> Web Abstraction Toolbox (it’s hard to tell the difference between wat and
> WTF sometimes…)
>
>
> +1
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Naming preference: SetForScope vs. TemporaryChange

[Antti Koivisto]

On Mon, Dec 26, 2016 at 5:29 AM, Maciej Stachowiak  wrote:

>
> ScopedChange(tachyonFlux, 2.0);
>

I wish there was a compiler warning against this. I have caused at least
one bug by doing this exact thing.

(a temporary gets deleted at the end of the expression)


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] RFC: stop using std::chrono, go back to using doubles for time

[Antti Koivisto]

I think the actual issue here was that std::chrono::duration can't
represent infinite duration and some of our code has been hacking around
that with std::chrono::duration::max(). Clock time + duration is not going
to overflow if the duration is natural (a finite constant or produced by
diffing time_points).

I have found that using Optional in cases where
the duration legitimately can be unspecified/infinite works well. In most
cases it can't be.

If we decide to write our own time type system lets make sure it covers all
the existing use of std::chrono without losing any of the static typing.
But maybe simply disallowing std::chrono::duration::max() in the style
checker would solve the immediate problem here?


   antti


On Mon, May 23, 2016 at 4:41 AM, Filip Pizlo  wrote:

> Hi everyone!
>
> I’d like us to stop using std::chrono and go back to using doubles for
> time.  First I list the things that I think we wanted to get from
> std::chrono - the reasons why we started switching to it in the first
> place.  Then I list some disadvantages of std::chrono that we've seen from
> fixing std::chrono-based code.  Finally I propose some options for how to
> use doubles for time.
>
> *Why we switched to std::chrono*
>
> A year ago we started using std::chrono for measuring time.  std::chrono
> has a rich typesystem for expressing many different kinds of time.  For
> example, you can distinguish between an absolute point in time and a
> relative time.  And you can distinguish between different units, like
> nanoseconds, milliseconds, etc.
>
> Before this, we used doubles for time.  std::chrono’s advantages over
> doubles are:
>
> *Easy to remember what unit is used:* We sometimes used doubles for
> milliseconds and sometimes for seconds.  std::chrono prevents you from
> getting the two confused.
>
> *Easy to remember what kind of clock is used:* We sometimes use the
> monotonic clock and sometimes the wall clock (aka the real time clock).
> Bad things would happen if we passed a time measured using the monotonic
> clock to functions that expected time measured using the wall clock, and
> vice-versa.  I know that I’ve made this mistake in the past, and it can be
> painful to debug.
>
> In short, std::chrono uses compile-time type checking to catch some bugs.
>
> *Disadvantages of using std::chrono*
>
> We’ve seen some problems with std::chrono, and I think that the problems
> outweigh the advantages.  std::chrono suffers from a heavily templatized
> API that results in template creep in our own internal APIs.  std::chrono’s
> default of integers without overflow protection means that math involving
> std::chrono is inherently more dangerous than math involving double.  This
> is particularly bad when we use time to speak about timeouts.
>
> *Too many templates:* std::chrono uses templates heavily.  It’s overkill
> for measuring time.  This leads to verbosity and template creep throughout
> common algorithms that take time as an argument.  For example if we use
> doubles, a method for sleeping for a second might look like
> sleepForSeconds(double).  This works even if someone wants to sleep for a
> nanoseconds, since 0.01 is easy to represent using a double.  Also,
> multiplying or dividing a double by a small constant factor (1,000,000,000
> is small by double standards) is virtually guaranteed to avoid any loss of
> precision.  But as soon as such a utility gets std::chronified, it becomes
> a template.  This is because you cannot have
> sleepFor(std::chrono::seconds), since that wouldn’t allow you to represent
> fractions of seconds.  This brings me to my next point.
>
> *Overflow danger:* std::chrono is based on integers and its math methods
> do not support overflow protection.  This has led to serious bugs like
> https://bugs.webkit.org/show_bug.cgi?id=157924.  This cancels out the
> “remember what unit is used” benefit cited above.  It’s true that I know
> what type of time I have, but as soon as I duration_cast it to another
> unit, I may overflow.  The type system does not help!  This is insane:
> std::chrono requires you to do more work when writing multi-unit code, so
> that you satisfy the type checker, but you still have to be just as
> paranoid around multi-unit scenarios.  Forgetting that you have
> milliseconds and using it as seconds is trivially fixable.  But if
> std::chrono flags such an error and you fix it with a duration_cast (as any
> std::chrono tutorial will tell you to do), you’ve just introduced an
> unchecked overflow and such unchecked overflows are known to cause bugs
> that manifest as pages not working correctly.
>
> I think that doubles are better than std::chrono in multi-unit scenarios.
> It may be possible to have std::chrono work with doubles, but this probably
> implies us writing our own clocks.  std::chrono’s default clocks use
> integers, not doubles.  It also may be possible to teach std::chrono to do
> overflow protection, but that would make me so sad since using d

Re: [webkit-dev] Windows Build Now on VS2015

[Antti Koivisto]

Does this mean we can start using (most) C++14 features?


  antti


On Wed, Aug 12, 2015 at 6:13 AM, Brent Fulgham  wrote:

> Hi Floks,
>
> We’ve finished updating the various Windows builds to VS2015. Full
> regression tests are now completing on these new builds, and seem to be
> comparable in terms of stability and correctness.
>
> Please let me know if you encounter any new issues on Windows. I know that
> EA encountered some JavaScript issues in a prior revision, but I haven’t
> been able to replicate this problem (at least yet).
>
> VS2015 is churning out a number of new build warnings, which I hope to
> address over the coming weeks. It will also likely have some useful static
> analysis results in the Windows-specific portions of the code that we
> should evaluate.
>
> Thanks,
>
> -Brent
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Filling the features.json files

[Antti Koivisto]

On Wed, Apr 8, 2015 at 7:09 AM, Benjamin Poulain 
wrote:

> Hi WebKit,
>
> The two features.json files are in the tree (WebCore/features.json and
> JavaScriptCore/features.json). The style checker now checks the basic
> structure of the files.
>

Could you also explain what these files are used for?


  antti


>
> I have added some basic things in there to show the basic structure. I
> would like help setting up those lists.
>
> If you have worked on a feature in the last 12 months, and you want to
> give it the visibility it deserves, please add it to features.json.
>
> An other type of feature that would be useful for those files are features
> that are not as popular as they should (image-set, srcset,
> sticky-positioning, etc).
>
> The only mandatory fields are "name" and "status".
>
> Committers can edit those files without reviews. Other contributors can
> make patches and ping me for review.
>
> Any question? Email me or poke me on IRC.
>
> Benjamin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebCore/platform standalone library

[Antti Koivisto]

Reusable Os Fitting Layer


   antti

On Fri, Mar 20, 2015 at 11:26 AM, Simon Fraser 
wrote:

>
> On Mar 20, 2015, at 11:03 AM, Edward O'Connor  wrote:
>
> >> This almost makes me want to suggest a jokey name for Platform. I can’t
>> off the top of my head think of a good expansion of OMG, though. Or BBQ.
>> >
>> > I am not a pro at this, but here are a few tries: Lower-level Object
>> Library. Algorithm Reuse Framework. New Framework for WebCore, New System
>> Framework for WebCore.
>>
>> Platform Obfuscation Source.
>
>
> Platform Interface and Testing Abstraction.
>
>
> General Independent Framework (pronounced "jiff," of course).
>
> Low-Level Abstract Platform would also be a logical choice.
>
>
> Low-level Object Library.
>
> Simon
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit Meeting: Network Cache session

[Antti Koivisto]

I added link to the slide to
https://trac.webkit.org/wiki/March%202015%20Meeting .


   antti

On Tue, Mar 17, 2015 at 8:28 AM, Adam Bergkvist  wrote:

> Hi
>
> Perhaps I should have posted this to the webkit-meeting list, but it
> seems pretty dead.
>
> Anyways.. does anyone have any notes or slides from the Network Cache
> session that they would like to share? I missed that session at the
> meeting.
>
> Antti or Chris?
>
> BR
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WorkQueue for Windows?

[Antti Koivisto]

On Sat, Mar 7, 2015 at 9:02 PM, Brent Fulgham  wrote:

> Hi Antti,
>
> Take a look at <https://bugs.webkit.org/show_bug.cgi?id=142432>. I
> haven't landed this yet, because I was hoping to get some kind of test for
> this. However, it seems to introduce no problems, so we could go ahead and
> land it.
>

That was fast, thanks! Looks good as far as I can tell. Basic QOS support
(thread priorities) would also be a useful addition at some point.

I don't think there is any specific test coverage (though WorkQueue is used
heavily in WK2). At least a basic unit test under
Tools/TestWebKitAPI/Tests/WTF would be nice.


> Question: why do we have a separate WorkQueue implementation in
> DumpRenderTree *and* WebKitTestRunner? Seems like we could do some
> consolidation...
>

This might be because the code used to live in WK2 and was only recently
moved to WTF. It would indeed be good to get rid of the duplication.


  antti

-Brent
>
>
> On Mar 6, 2015, at 10:55 AM, Anders Carlsson  wrote:
>
> I think we used to have a WorkQueue implementation for Windows WK2 -
> anyone should be able to dig it up.
>
> (Alternatively, we can just make an implementation using std::thread).
>
> - Anders
>
> On Mar 6, 2015, at 10:46 AM, Antti Koivisto  wrote:
>
>
> Hi,
>
>
> I'd like to start using WTF::WorkQueue abstraction in WebCore code.
> However we are currently missing a Windows implementation (WorkQueue used
> to be part of WK2). Anyone interested in making one? I assume it wouldn't
> be a difficult task for someone who knows the platform.
>
>
>
>   antti
>
> ___
>
> webkit-dev mailing list
>
> webkit-dev@lists.webkit.org
>
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WorkQueue for Windows?

[Antti Koivisto]

Hi,

I'd like to start using WTF::WorkQueue abstraction in WebCore code. However
we are currently missing a Windows implementation (WorkQueue used to be
part of WK2). Anyone interested in making one? I assume it wouldn't be a
difficult task for someone who knows the platform.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] virtual and override

[Antti Koivisto]

We have traditionally marked virtual overrides with the 'virtual' keyword
for documentation purposes. Nowadays we also have the compiler checked
'override'. Using both at the same time seems redundant.

Should we change the coding style so that exactly one of the 'virtual' and
'override' must be present for all virtual functions?


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Antti Koivisto]

I don't think this is really 32bit vs 64bit platform issue. The vast
majority of 64bit systems our users have (that is iOS devices) can't use
memory buffers sized anywhere near the 32bit limit even in theory. Also
when using Vector auto-grow capabilities (which is really the point of
using a vector instead of just allocating a buffer) you need way more
memory than the actual data size. Growing a Vector beyond 4GB has
peak allocation of 9GB.

Are there any examples of Vectors in the current code base where we would
usefully fix an actual problem even in medium term by switching to 64bit
storage sizes? I don't think they exists. Cases like file uploads should
stream the data or use some mapped-file backed buffer type that is not a
Vector.

With this in mind I think the right direction is to make the Vector API
match the implementation and just start using unsigned indexes everywhere.


   antti

On Fri, Nov 21, 2014 at 2:59 AM, Maciej Stachowiak  wrote:

>
> On Nov 20, 2014, at 4:51 PM, Maciej Stachowiak  wrote:
>
>
> On Nov 20, 2014, at 9:26 AM, Alexey Proskuryakov  wrote:
>
>
> 19 нояб. 2014 г., в 14:58, Alexey Proskuryakov  написал(а):
>
> These and related uses are all over the place - see also Vectors
> in FormDataBuilder, data returned from
> FrameLoader::loadResourceSynchronously, plug-in code that loads from
> network, SharedBuffer etc.
>
>
> Another way to say this is: we need to deal with large data arrays
> throughout loading code. We do not really need full size vectors in most
> other code - it's sort of OK for HTML parser or for image decoder to fail
> catastrophically when there is too much data fed to it.
>
> This is somewhat questionable design, but if we are going to stick to it,
> then magnitude checks should be centralized, not sprinkled throughout the
> code. We should not make this check explicitly when feeding a network
> resource to the parser, for example.
>
> A 64-bit API for Vector solves this nearly flawlessly. We do not perform
> the checks manually every time we use a Vector, Vector does them for us.
>
> Other options are:
>
> - uint64_t everywhere. This way, we'll solve practical problems with large
> resources once and for all. Also, this may prove to be necessary to solve
> even YouTube/Google Drive uploads, I do not know that yet.
>
> - size_t everywhere. Same effect on 64-bit platforms, while 32-bit ones
> will still be limited. I like this option, because it won't make us pay the
> memory and performance cost on old crippled 32-bit machines, which are
> unlikely to be used for manipulating huge volumes of data anyway.
>
>
> We probably want YouTube upload of large files to work on 32-bit machines.
> Though presumably if you want to upload a file larger than the virtual
> address space, you need to represent it in some way other than a Vector.
>
>
> Thinking about this more - I think file sizes should probably be an off_t,
> not a size_t, so on 32-bit platforms some care must still be taken in the
> conversion between file sizes and vector sizes.
>
> In general, I like the idea of Vector having a size_t API and a choice of
> smaller or larger internal size. We might also want to change other
> containers with size-related interfaces to match.
>
> Regards,
> Maciej
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Antti Koivisto]

Or Vector and ByteBuffer.

All these cases requiring very large buffers seem to be about untyped data.


   antti

On Thu, Nov 20, 2014 at 9:40 PM, Filip Pizlo  wrote:

> That looks like a pretty good performance win.
>
> I'd advocate for SmallVector and Vector, then.
>
> -Filip
>
>
> On Nov 20, 2014, at 11:38 AM, Chris Dumez  wrote:
>
> The corresponding Blink bug did contain some performance data:
> CrBug#229226 
>
> Kr,
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
>
>
>
>
> On Nov 20, 2014, at 11:32 AM, Geoffrey Garen  wrote:
>
> I wonder what the downsides are to this approach.  Footprint of Vector?
>
>
> It looks like the original change was motivated by shrinking Vector:
>
> https://bugs.webkit.org/show_bug.cgi?id=97268
>
> Sadly, it didn’t include any data on the observed benefit :(.
>
> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] size_t vs unsigned in WTF::Vector API ?

[Antti Koivisto]

I agree with Phil, we should just use unsigned consistently. For very large
memory allocations Vector is probably not the right type to use.


  antti

On Wed, Nov 19, 2014 at 10:32 PM, Filip Pizlo  wrote:

> Whatever we do, the clients of Vector should be consistent about what type
> they use.  I'm actually fine with Vector internally using unsigned even if
> the API uses size_t, but right now we have lots of code that uses a mix of
> size_t and unsigned when indexing into Vectors.  That's confusing.
>
> If I picked one type to use for all Vector indices, it would be unsigned
> rather than size_t.  Vector being limited to unsigned doesn't imply 4GB
> unless you do Vector.  Usually we have Vectors of pointer-width
> things, which means 32GB on 64-bit systems (UINT_MAX * sizeof(void*)).
> Even in a world where we had more than 32GB of memory to use within a
> single web process, I would hope that we wouldn't use it all on a single
> Vector and that if we did, we would treat that one specially for a bunch of
> other sensible reasons (among them being that allocating a contiguous slab
> of virtual memory of that size is rather taxing).  So, size_t would buy us
> almost nothing since if we had a vector grow large enough to need it, we
> would be having a bad time already.
>
> I wonder: are there cases that anyone remembers where we have tried to use
> Vector to store more than UINT_MAX things?  Another interesting question
> is: What's the largest number of things that we store into any Vector?  We
> could use such a metric to project how big Vectors might get in the future.
>
> -Filip
>
>
> On Nov 19, 2014, at 12:20 PM, Chris Dumez  wrote:
>
> Hi all,
>
> I recently started updating the WTF::Vector API to use unsigned types
> instead of size_t [1][2], because:
> - WTF::Vector is already using unsigned type for size/capacity internally
> to save memory on 64-bit, causing a mismatch between the API and the
> internal representation [3]
> - Some reviewers have asked me to use unsigned for loop counters iterating
> over vectors (which looks unsafe as the Vector API, e.g. size(), returns a
> size_t).
> - I heard from Joseph that this type mismatch is forcing us (and other
> projects using WTF) to disable some build time warnings
> - The few people I talked to before making that change said we should do it
>
> However, Alexey recently raised concerns about this change. it doesn't
> "strike him as the right direction. 4Gb is not much, and we should have
> more of WebKit work with the right data types, not less.”.
> I did not initially realize that this change was controversial, but now
> that it seems it is, I thought I would raise the question on webkit-dev to
> see what people think about this.
>
> Kr,
> --
> Chris Dumez - Apple Inc.
> Cupertino, CA
>
>
> [1] http://trac.webkit.org/changeset/176275
> [2] http://trac.webkit.org/changeset/176293
> [3] http://trac.webkit.org/changeset/148891
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Networking process scope

[Antti Koivisto]

On Mon, Nov 10, 2014 at 12:28 PM, youenn fablet  wrote:

> Hi,
>
> I looked at the Networking process recently and am wondering what is
> in scope/out of scope of this process.
>
> Currently, the networking process is used to load resources from:
> - URLs resolved using platform specific libraries (CF, libsoup...),
> including data URLs
> - Blob URLs
> The networking process is not used for (at least):
> - appcache resources URLs
> - archive resources URLs
>
> Two options come to mind:
> 1. Use networking process for all URLs that require actual networking.
> That would mean moving data & blob URL handling within WebProcess,
> probably unifying this loading with appcache/archive resource loading.
>

A load should go to the network process if it needs to do actual
networking. Web processes should not need that capability at all (there are
a few things that still require this at the moment I think). Another reason
might be a case where multiple web processes need to see the same view of
some non-network resources.

Otherwise it makes sense to handle loads as close to the request source as
possible to minimize overhead and complexity. At least data: could be
handled in the web process just fine. I think blob: too.


   antti


> 2. Use networking process for all URLs. That would mean moving
> appcache/archive resource loading into Networking process at some
> point.
>
> Any thoughts?
>
> Regards,
>Youenn
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Disk cache

[Antti Koivisto]

On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos 
wrote:

> El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
> > Hello,
> >
> >
> > I'm planning to add an experimental HTTP cache implementation to
> > WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).
>
> Great news!
>
> >  The main motivations are:
> >
> >
> > - Improving performance by bringing the cache closer. For example we
> > can serialize WebKit response objects directly instead of converting
> > to/from platform types.
> > - Making future innovation around caching easier. Closer coordination
> > between cache and WebKit opens new optimization possibilities.
> >
> >
> > The cache lives in the network process. Most of the code is
> > cross-platform. The storage backend uses libdispatch IO though it
> > wouldn't be hard to add a generic posix one too.
>
> Why is it limited to the network process? wouldn't it be possible to use
> it also in the web process when shared secondary process model is used?
>

The cache ties to NetworkResourceLoader which lives in the network process.
In principle it would be possible to integrate with the web process side
resource loader too. However I don't want to support multiple
configurations during development.

It would be good if all WK2 ports would eventually switch to using the
network process. The current multitude of configurations makes networking
related code more confusing and less hackable than it needs to be.


   antti


>
> >
> > The code will be behind NETWORK_CACHE feature flag.
> >
> >
> >
> >
> >   antti
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Disk cache

[Antti Koivisto]

On Sat, Nov 1, 2014 at 7:03 AM, Alex Christensen <
alex.christen...@flexsim.com> wrote:

> Would anything special need to be done for Windows?
>

Is there some Windows port that uses network process? As I mentioned
enabling the feature would require Windows specific backend implementation.
Just compiling it out requires no action.


   antti


>
> Alex
>
> On Oct 31, 2014, at 11:02 AM, Antti Koivisto  wrote:
>
> Hello,
>
> I'm planning to add an experimental HTTP cache implementation to WebKit (
> https://bugs.webkit.org/show_bug.cgi?id=30322). The main motivations are:
>
> - Improving performance by bringing the cache closer. For example we can
> serialize WebKit response objects directly instead of converting to/from
> platform types.
> - Making future innovation around caching easier. Closer coordination
> between cache and WebKit opens new optimization possibilities.
>
> The cache lives in the network process. Most of the code is
> cross-platform. The storage backend uses libdispatch IO though it wouldn't
> be hard to add a generic posix one too.
>
> The code will be behind NETWORK_CACHE feature flag.
>
>
>   antti
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Disk cache

[Antti Koivisto]

Hello,

I'm planning to add an experimental HTTP cache implementation to WebKit (
https://bugs.webkit.org/show_bug.cgi?id=30322). The main motivations are:

- Improving performance by bringing the cache closer. For example we can
serialize WebKit response objects directly instead of converting to/from
platform types.
- Making future innovation around caching easier. Closer coordination
between cache and WebKit opens new optimization possibilities.

The cache lives in the network process. Most of the code is cross-platform.
The storage backend uses libdispatch IO though it wouldn't be hard to add a
generic posix one too.

The code will be behind NETWORK_CACHE feature flag.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Keep ResourceBuffer?

[Antti Koivisto]

In that case remove away. Did I mention this code is confusing?


   antti

On Thu, Oct 23, 2014 at 8:11 PM, Darin Adler  wrote:

>
> > On Oct 23, 2014, at 10:13 AM, Antti Koivisto  wrote:
> >
> > Note that ResourceBuffer is virtual and wraps a ShareableResource on
> WebKit2 side. ShareableResource exists to do memory mapped IPC.
>
> Really? I don’t see any code actually creating the class in WebKit2. There
> is a class named WebResourceBuffer, but no instance of it is ever created.
> Also, not enough of the functions in ResourceBuffer are virtual to make
> this actually work.
>
> — Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Keep ResourceBuffer?

[Antti Koivisto]

Note that ResourceBuffer is virtual and wraps a ShareableResource on
WebKit2 side. ShareableResource exists to do memory mapped IPC.

The current factoring is confusing and cleaning this up is definitely a
good idea. However it will require a bit more than just changing
ResourceBuffers
to SharedBuffers.


   antti

On Thu, Oct 23, 2014 at 9:42 AM, Darin Adler  wrote:

> Hi folks.
>
> I’ve noticed that we have an unused abstraction in the loader code.
> ResourceBuffer is a cover for a SharedBuffer, with comments and remnants of
> an older effort to make it some kind of abstraction. But at the moment it’s
> just overhead and no abstraction.
>
> Does anyone object to my eliminating ResourceBuffer for now and changing
> code to use SharedBuffer directly instead?
>
> — Darin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Please avoid inheriting concrete types over WebCore/WebKit boundary

[Antti Koivisto]

Hi,

To make callbacks from WebCore to WebKit(2) we have generally used approach
where WebCore exports an abstract client interface which is then
implemented on the WebKit side.

More recently there has been some proliferation of a pattern where we
inherit directly from a concrete WebCore type and specialize it on the
WebKit side, in some cases with a completely different implementation:

class WebResourceLoadScheduler : public WebCore::ResourceLoadScheduler {
class GraphicsLayerCARemote final : public WebCore::GraphicsLayerCA {
etc.

I don't think this is a good pattern. It makes understanding the code
harder as you can no longer reason about it within the WebCore only (the
WebCore side implementation you are looking at may be effectively dead
code). It also blurs the library boundary (which is still useful at least
as long as we support both WebKit and WebKit2).

I think we should avoid this pattern in new code and possibly refactor some
of the existing examples.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove ENABLE(SVG)

[Antti Koivisto]

Yes, let's remove the flag. It is too easy to break the no-SVG build and
the guards uglify the code.


   antti


On Wed, Jan 29, 2014 at 2:13 AM, Sam Weinig  wrote:

> Hi Everyone,
>
> While we are discussing removing #ifdefs that everyone has enabled, I'd
> like to propose removing ENABLE(SVG), as every port has SVG enabled.  The
> only argument I have heard for keeping it around is to keep a "minimal
> build" working, but I don't think the clutter of the #ifdefs is worth that.
>
> -Sam
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Antti Koivisto]

On Mon, Jan 6, 2014 at 11:49 PM, Geoffrey Garen  wrote:

>
> (2) ApplyStyleCommand.cpp:
>
> auto children = elementChildren(*dummySpanAncestor);
> for (auto child = children.begin(), end = children.end(); child !=
> end; ++child) {
> *if (isSpanWithoutAttributesOrUnstyledStyleSpan(&*child))*
> *toRemove.append(&*child);*
> }
>

You are looking at a pretty old revision. In ToT this looks like

for (auto& child : childrenOfType(*dummySpanAncestor)) {
if (isSpanWithoutAttributesOrUnstyledStyleSpan(&child))
toRemove.append(&child);
}

  antti


>
> Thanks,
> Geoff
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Antti Koivisto]

On Fri, Jan 3, 2014 at 9:28 PM, Geoffrey Garen  wrote:

> I strongly object to varying coding style arbitrarily based on author or
> project file. That's a recipe for an unreadable polyglot codebase.
>

I wasn't advocating a general coding style free-for-all. I imagine there
could be valid subsystem specific reasons for not deploying 'auto' widely.

> auto& cell = toRenderTableCell(*renderer); // right
> > RenderTableCell& cell = toRenderTableCell(*renderer);  // wrong
>
> Not sure.
>
> These lines of code do not include a verbatim type name, and so they are
> not friendly to cmd-click/select-and-search. Changing the function
> signature to “to”, or something like that, might help.
>

Cmd-click on toRenderTableCell takes you to RenderTableCell.h. I'm
unconvinced this is a practical problem.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] When to use "auto"? (I usually consider it harmful)

[Antti Koivisto]

On Thu, Jan 2, 2014 at 11:12 PM, Geoffrey Garen  wrote:

> Hi folks.
>
> Recently, I’ve seen patches go by using the C++11 “auto” keyword. For
> example, let me pick on Andreas:
>
> > 
> >
> > +auto newRenderer = textNode.createTextRenderer(style);
> > +ASSERT(newRenderer);
> >
> > ….
> >
> > +parentRenderer->addChild(newRenderer.leakPtr(), nextRenderer);
>
> I think this use of “auto” is net harmful.
>

I agree that in a case where a smart pointer of unclear type (when the new
renderer smart pointers are deployed everywhere the situation might be
different) is returned it might be better not to use "auto".

However I also feel the "harm" here is debatable enough that people working
on/reviewing the code should make decisions instead of there being a
project level dictate. It is a new thing, the appropriate usage hasn't yet
settled and people should be allowed to experiment.

I think an appropriate style guideline for “auto” would say something like:
>
> - Use “auto" to declare a disgusting templated iterator type in a loop
> - Use “auto… ->" to define a template-dependent return type in a class
> template
> - In all other cases, use an explicit type declaration
>

I think this is a too limiting set of rules. I have found that in many
cases "auto" improves code readability by having less gunk obscuring the
logic. It has also made refactoring easier.

I'm not sure how much rules we really need beyond "use 'auto' when it
improves code". I gather from this thread that especially people working on
JSC are not comfortable using it so they shouldn't.

If we start making rules I'd add the following:

- Use "auto" when the type name is already mentioned on a line:

auto& cell = toRenderTableCell(*renderer); // right
RenderTableCell& cell = toRenderTableCell(*renderer);  // wrong

for (auto& source : descendantsOfType(*this)) // right
for (const HTMLSourceElement& source :
descendantsOfType(*this)) // wrong

auto properties = std::make_unique();  //right
std::unique_ptr properties =
std::make_unique(); //wrong

This rule is already widely deployed and I think the code readability has
improved.

- Use "auto" when the type is irrelevant. This covers things like iterators
and adapter classes:

auto sourceDescendants = descendantsOfType(*this));

It might also cover smart pointer usage like your example and multiline
expansions of setSize(foo->size()).

- Use "auto" when type is obvious for people with basic familiarity with a
subsystem:

auto& style = renderer.style();


> Thoughts?



   antti


>
> Thanks,
> Geoff
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] The SrcN responsive images proposal

[Antti Koivisto]

On Tue, Oct 22, 2013 at 11:50 PM, Tab Atkins Jr. wrote:

> The parsing aspect isn't particularly new - parsing data-* attributes
> presents the same problem.  You just need to filter the list of
>

data-* attributes are not parsed.


> attributes on the element to look for things with a src- prefix.  I've
> heard direct feedback from Yoav, implementing in Blink, that it's not
> a big problem.
>

I didn't say it is a big problem. I said it is ugly.


  antti


> ~TJ
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] The SrcN responsive images proposal

[Antti Koivisto]

On Sun, Oct 20, 2013 at 11:08 PM, Benjamin Poulain wrote:

> On 10/20/13, 9:07 AM, Antti Koivisto wrote:
> > Ignoring other aspects of this, the idea of making attribute name an
> > enumeration is somewhat distasteful. It will require ugly special
> > parsing. The platform has plenty of attribute values that are lists
> already.
>
> I was thinking the same thing last night. In addition to weirdness on
> the engine side, it looks like a nightmare for authoring/tooling.


> Is there a precedent for this strange notation?
>

Also CSS selectors only support matching exact attribute names. There is no
way to write universal "elements with some srcN attribute" query for
example. This might not be important for practical uses here but it does
demonstrate that the approach is a poor fit to the platform.


  antti


> Benjamin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] The SrcN responsive images proposal

[Antti Koivisto]

Ignoring other aspects of this, the idea of making attribute name an
enumeration is somewhat distasteful. It will require ugly special parsing.
The platform has plenty of attribute values that are lists already.


  antti


On Sun, Oct 20, 2013 at 4:00 AM, Maciej Stachowiak  wrote:

> My initial impression is that it seems a bit overengineered.
>
>  - Maciej
>
> On Oct 19, 2013, at 4:39 PM, Yoav Weiss  wrote:
>
> Hello WebKiteers,
>
> I'd like to get the project's opinion on a recent responsive image
> proposal by Tab Atkins dubbed srcN:
> http://tabatkins.github.io/specs/respimg/Overview.html
>
> This proposal covers all the major responsive images use-cases: DPR based
> resource selection, viewport dimensions based resource selection and
> art-direction.
> It does so while avoiding previous implementor concerns regarding the
>  element and its complexity, and while providing better authoring
> tools for viewport based resource selection than previous proposals.
>
> The srcN proposal does come to replace the srcset DPR switching syntax
> which recently landed in WebKit (an effort I was a part of). OTOH, srcN's
> x-based URL syntax replicates srcset's DPR syntax, so I believe large parts
> of that code can be reused in srcN's implementation.
>
> Will the project welcome patches implementing the srcN proposal? (Possibly
> behind a flag)
>
> Thanks,
> Yoav
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: remove style scoped

[Antti Koivisto]

I think it is a feature that we may want to have sooner or later. We will
probably want to change the implementation quite a bit though and removing
the dead code for now makes sense.


   antti


On Thu, Sep 26, 2013 at 3:42 PM, Benjamin Poulain wrote:

> Dear WebKit,
>
> We have an unmaintained implementation of the "scoped style" feature in
> the tree. (http://www.whatwg.org/specs/**web-apps/current-work/**
> multipage/semantics.html#attr-**style-scoped
> )
> It is getting in the way of improvements so I would like to remove it for
> now.
>
> From what I have found online, only Firefox ships the feature and it is
> not popular.
>
> Does anyone plan to finish the feature and ship it? If not, I will remove
> it soon-ish.
> We can always add the feature later if it becomes useful.
>
> Cheers,
> Benjamin
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Removing DIALOG_ELEMENT for now

[Antti Koivisto]

We current have an incomplete, unmaintained implementation of the HTML5
 element in our code base. No one is building it as far as I can
see and it has bit-rotted to the point it probably wouldn't work anyway.

I think we should remove the code for now. It should be possible to come up
with a nicer implementation when we decide to bring it back.

https://bugs.webkit.org/show_bug.cgi?id=120467


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Ref counting questions

[Antti Koivisto]

TreeShared is essentially an implementation detail of the DOM tree (the
only other client besides Node is SVGElementInstance).  It shouldn't be
used for anything else.

TreeShared keeps Nodes alive when they are part of a tree (have a parent
node) even when they have zero refcount. This way nodes don't need to
explicitly ref and deref their children.


  antti


On Wed, May 22, 2013 at 7:26 PM, Bem Jones-Bey  wrote:

> Hey all,
>
> I've read the document at http://www.webkit.org/coding/RefPtr.html, but I
> still have some questions about using RefPtrs.
>
> The first one is listed in the "Improving this document" section of the
> aforementioned documentation:
> • Perils of programming with TreeShared.
> What does that mean? What gotchas should I be aware of? (Heck, more
> details on any of the things in "improving this document" would be helpful,
> and I'll do my best to update the document with anything I learn if that's
> desired.)
>
> Also, I've noticed that there's both TreeShared and RefCounted, and they
> seem fairly similar to my uninitiated eye. What's the difference between
> the two and when should one use one or the other? Also, are there other
> templates/classes that I should be aware of?
>
> Thanks,
> Bem
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] We should delete ENABLE_SHADOW_DOM

[Antti Koivisto]

I think it would be better to remove this code in controlled pieces along
with all the underlying implementation (which is mostly not behind the
flag) rather than removing it wholesale. It is good to understand what we
are removing and that gets difficult if the API level (the only thing
consistently behind SHADOW_DOM) is not present. I was also considering
leaving a basic implementation along the lines of
http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0387.html in
place (mostly to keep  element working).


   antti



On Thu, May 16, 2013 at 8:09 PM, Ryosuke Niwa  wrote:

> Hi,
>
> It appears that not a single port enables SHADOW_DOM build flag at this
> point, and WebKit doesn't even compile with that option enabled. (There are
> a few dozens of build failures).
>
> Is anyone intending to maintain the feature on trunk?  If not, we should
> simply get rid of code behind this build flag for now; keeping unmaintained
> code that doesn't even compile isn't healthy for the project of our size.
>
> - R. Niwa
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] What do we do with various Web component features?

[Antti Koivisto]

I agree that we should remove most of the Shadow DOM related code (the
portions supporting distribution especially). It is invasive, has
significant architectural issues (including use of a confusing mutating
iterator) and forces generic code many places where it would not be needed
otherwise. It is essentially blocking us from improving DOM data
structures. The code has been developed organically in parallel with the
spec and I feel that a future new implementation could be cleaner.


   antti



On Sat, Apr 27, 2013 at 2:38 PM, Benjamin Poulain wrote:

> On Fri, Apr 26, 2013 at 9:46 PM, Ryosuke Niwa  wrote:
>
>> There appears to be a lot of Web component related features in
>> WebKit that used to be maintained by Chromium contributors;
>> specifically those related to Shadow DOM and node distributions.
>>
>> What do we do with them? The specification is still under the
>> construction and our implementation is getting outdated day by day.
>>
>> I certainly see the value of the proposed specification, and I would like
>> it to be shipped by WebKit browsers. However, having unmaintained code that
>> is this invasive in WebCore is very harmful in short term.
>>
>> Is anyone stepping up to maintain the code, or should we consider
>> removing them for the time being?
>>
>
> All that unmaintained code has a cost we should not have to pay.
>
> I am in favor of removing it and bring the code back later when someone
> decide to support that spec.
>
> Benjamin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

[Antti Koivisto]

On Sat, Apr 13, 2013 at 8:26 AM, Filip Pizlo  wrote:

>
> Also, you could do a libdispatch style, where there is no "lock" per se
> but instead you just have queues that you put tasks on.  I like that, too.
>  It's also formally equivalent to both locks and message queues, but much
> more similar to threads and locks in practice.
>

I always thought libdispatch style concurrency would be a great fit for the
web. It is slightly higher level and probably easier to use than locks and
threads, without being particularly limiting. You also get thread
management and platform event integration (timers etc) in the same package.
The programming style (with blocks C extension) even looks like Javascript
style.


   antti


> -Filip
>
>
> Regards,
> Maciej
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] StyleBuilder vs StyleResolver

[Antti Koivisto]

On Fri, Apr 12, 2013 at 4:50 PM, Dirk Schulze  wrote:

>
> On Apr 12, 2013, at 1:08 AM, Antti Koivisto  wrote:
>
> > On Fri, Apr 12, 2013 at 7:36 AM, Dirk Schulze 
> wrote:
> > Hi,
> >
> > The style of CSS properties is either set in StyleBuilder/CSSProperty or
> in StyleResolver (alias CSSStyleSelector).
> >
> > StyleResolver has a giant switch statement to handle all CSS property
> values and set the style. It is the historical way to build the style.
> >
> > StyleBuilder was introduced ~2 years ago. Instead of a giant switch to
> handle all property styles, it has a concept of template to combine CSS
> property handling.
> >
> > In these last two years new properties were mainly added to
> StyleBuilder, older properties were left alone in StyleResolver. The
> concept of StyleBuilder was always controversial[1][2]. A lot of people had
> concerns that StyleBuilder is less readable and makes it harder to
> understand the code.
> >
> > I personally am more worried that we still have two ways to set the
> style. I think it is bad to keep half of the properties in StyleResolver
> and the other half in StyleBuilder. We may use the general "spring cleanup"
> to revalidate the concept of StyleBuilder and StyleResolver and decide to
> use the one or the other concept.
> >
> > Any thoughts?
> >
> > Fully agreed. I'm still sad I couldn't stop this refactoring initially.
> So much wasted effort.
> >
> > Having property applying code in a separate class instead of piling it
> back to StyleResolver still makes sense though and StyleBuilder is a good
> name. Maybe something like this would be a good strategy?
> >
> > rename StyleBuilder -> DeprecatedStyleBuilder
> > create new StyleBuilder
> > move the giant switch and the related functions from StyleResolver to
> StyleBuilder
> > move individual properties from DeprecatedStyleBuilder to StyleBuilder
> until nothing remains
> > delete DeprecatedStyleBuilder
>
> I agree that StyleBuilder is the better name. Do you really want to have
> two huge renamings? Can't we just move everything over to StyleResolver and
> then rename it to StyleBuilder? After all, we just removed one build system
> yet ;) However, I am fine with both.
>

StyleBuilder is an implementation detail of StyleResolver and is not
referenced from anywhere else. I don't changing its name qualifies as a
"huge renaming".

The transition may take a while. I like strategy like this as it documents
both the current state and the end goal.


   antti


> I would definitely help to make this possible but would appreciate to get
> help from others as well.
>
> Here is a master bug for this change:
> https://bugs.webkit.org/show_bug.cgi?id=114508
>
> Greetings,
> Dirk
>
>
> >
> >
> >antti
> >
> >
> > Greetings,
> > Dirk
> >
> > [1] https://bugs.webkit.org/show_bug.cgi?id=54707
> > [2] https://bugs.webkit.org/show_bug.cgi?id=102844
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] StyleBuilder vs StyleResolver

[Antti Koivisto]

On Fri, Apr 12, 2013 at 7:36 AM, Dirk Schulze  wrote:

> Hi,
>
> The style of CSS properties is either set in StyleBuilder/CSSProperty or
> in StyleResolver (alias CSSStyleSelector).
>
> StyleResolver has a giant switch statement to handle all CSS property
> values and set the style. It is the historical way to build the style.
>
> StyleBuilder was introduced ~2 years ago. Instead of a giant switch to
> handle all property styles, it has a concept of template to combine CSS
> property handling.
>
> In these last two years new properties were mainly added to StyleBuilder,
> older properties were left alone in StyleResolver. The concept of
> StyleBuilder was always controversial[1][2]. A lot of people had concerns
> that StyleBuilder is less readable and makes it harder to understand the
> code.
>
> I personally am more worried that we still have two ways to set the style.
> I think it is bad to keep half of the properties in StyleResolver and the
> other half in StyleBuilder. We may use the general "spring cleanup" to
> revalidate the concept of StyleBuilder and StyleResolver and decide to use
> the one or the other concept.
>
> Any thoughts?


Fully agreed. I'm still sad I couldn't stop this refactoring initially. So
much wasted effort.

Having property applying code in a separate class instead of piling it back
to StyleResolver still makes sense though and StyleBuilder is a good name.
Maybe something like this would be a good strategy?

rename StyleBuilder -> DeprecatedStyleBuilder
create new StyleBuilder
move the giant switch and the related functions from StyleResolver
to StyleBuilder
move individual properties from DeprecatedStyleBuilder to StyleBuilder
until nothing remains
delete DeprecatedStyleBuilder


   antti


> Greetings,
> Dirk
>
> [1] https://bugs.webkit.org/show_bug.cgi?id=54707
> [2] https://bugs.webkit.org/show_bug.cgi?id=102844
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] AncestorChainWalker substance and style thoughts

[Antti Koivisto]

The purpose of the NodeTraversal refactoring was simply to move the
existing traversal functions off the (rather bloated) Node and add Element
specific functions. I think longer term iterators are the way to go as they
allow decoupling our internal document tree data structures from the DOM
API.

The problem with ComposedShadowTreeWalker is not that it is an iterator but
that it is ill-defined and complex. It calls back to non-trivial, mutating
functions on the structure being traversed (ContentDistributor::distribute!).
Simply traversing a tree with it can apparently end up marking the tree for
style recalc.

I don't think adding NodeRenderingTraversal on top of this helped much
though it did clarify the case where ComposedShadowTreeWalker is actually
needed.


  antti

On Tue, Feb 19, 2013 at 4:18 AM, Hajime Morrita wrote:

> AncestorChainWalker follows the style of ComposedShadowTreeWalker,
> which also breaks conventions like mutations-should-be-verbs. We also fix
> its style for integrity.
>
> Non-trivial tree traversal API in general should, IMO, be modeled after
> recently introduced NodeTraversal.
> Having separate namespaces allows us to keep Node API minimal. Also it is
> stateless and simple.
>
> I made NodeRenderingTraversal in that way.
> AncestorChainWalker could be just merged to NodeRenderingTraversal.
>
> Speaking of ComposedShadowTreeWalker, I think it is worth having a class
> instead of namespace
> since it holds configuration parameters to decide, for example, whether it
> skips specific types of node.
>
>
>
> On Tue, Feb 19, 2013 at 10:37 AM, Darin Adler  wrote:
>
>> I am trying to learn about code related to shadow DOM that needs to be
>> understood by anyone working on an part of the DOM.
>>
>> I have some questions and concerns about AncestorChainWalker. If there is
>> a document I should be reading that covers these, please point me to it.
>>
>> The parentNode and parentElement functions are just plain old functions
>> that are used to walk the ancestor chain of the normal DOM. But the shadow
>> DOM AncestorChainWalker is a class. Why? It seems that it could just be a
>> function with two return values. Is it more efficient to have it be a
>> class? Can the operation be correctly done without storing
>> m_distributedNode in a data member?
>>
>> There is a function in AncestorChainWalker named parent. That name is a
>> noun, so the function should be a const function that returns a value.
>> Since it’s not, the function name should be a verb phrase, such as
>> advanceToParent, or event just “advance” since it’s in the context of an
>> ancestor chain walker.
>>
>> The function crossingInsertionPoint should be named
>> isCrossingInsertionPoint as the data member is. But also, since the walker
>> sits still on a single node, I don’t think it makes sense to talk about the
>> position as “is crossing”. It should be “just crossed” or something like
>> that instead. Unless an insertion point is like a bridge and is not itself
>> a “true node”.
>>
>> The function that returns the current node in the ancestor chain is named
>> “get”. That’s not a good name, and should be avoided if possible. It could
>> be named “node” or “currentNode” instead.
>>
>> -- Darin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Opera and WebKit

[Antti Koivisto]

Welcome!


   antti


On Wed, Feb 13, 2013 at 10:06 AM, Håkon Wium Lie  wrote:

> Dear WebKit community,
>
> Many of us have met through various web standards efforts, such as
> W3C and WHAT WG. Today I'd like to introduce Opera Software in a new
> forum for us: the webkit-dev mailing list.
>
> We have known WebKit and its KTHML predecessor for some time. Lars
> Knoll, who (re)wrote KHTML in 1999, worked for TrollTech for many
> years. TrollTech and Opera shared a building in Oslo, a building which
> has earned its place in the rendering engine hall of fame.
>
> Some of our best programmers have been working on the WebKit code for
> a while, and today we have announced that we will be using the WebKit
> engine in the future [1]. We will also submit our code; switching from
> Presto to WebKit frees up resources and allows us to contribute to the
> WebKit platform.
>
> The first contributions from our side will be in multi-column layout
> [2]. We have experimented with combining multicol layout with
> page floats and column spans [3]; in 10 lines of CSS code one can
> create amazingly beautiful, scaleable and responsive paged
> presentations [4].
>
> We hope to work with you to further strengthen the open web that we
> all believe in.
>
>[1] http://www.opera.com/press/releases/2013/02/13/
>[2] http://www.w3.org/TR/css3-multicol/
>[3] http://dev.w3.org/csswg/css3-gcpm/#page-floats
>[4] http://people.opera.com/howcome/2013/02-reader
>
> Cheers,
>
> Håkon Wium Lie
> CTO Opera Software
> http://people.opera.com/howcome
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread

[Antti Koivisto]

When loading web pages we are very frequently in a situation where we
already have the source data (HTML text here but the same applies to
preloaded Javascript, CSS, images, ...) and know we are likely to need it
in soon, but can't actually utilize it for indeterminate time. This happens
because pending external JS resources blocks the main parser (and pending
CSS resources block JS execution) for web compatibility reasons. In this
situation it makes sense to start processing resources we have to forms
that are faster to use when they are eventually actually needed (like token
stream here).

One thing we already do when the main parser gets blocked is preload
scanning. We look through the unparsed HTML source we have and trigger
loads for any resources found. It would be beneficial if this happened off
the main thread. We could do it when new data arrives in parallel with JS
execution and other time consuming engine work, potentially triggering
resource loads earlier.

I think a good first step here would be to share the tokens between the
preload scanner and the main parser and worry about the threading part
afterwards. We often parse the HTML source more or less twice so this is an
unquestionable win.


  antti


On Thu, Jan 10, 2013 at 7:41 AM, Filip Pizlo  wrote:

> I think your biggest challenge will be ensuring that the latency of
> shoving things to another core and then shoving them back will be smaller
> than the latency of processing those same things on the main thread.
>
> For small documents, I expect concurrent tokenization to be a pure
> regression because the latency of waking up another thread to do just a
> small bit of work, plus the added cost of whatever synchronization
> operations will be needed to ensure safety, will involve more total work
> than just tokenizing locally.
>
> We certainly see this in the JSC parallel GC, and in line with traditional
> parallel GC design, we ensure that parallel threads only kick in when the
> main thread is unable to keep up with the work that it has created for
> itself.
>
> Do you have a vision for how to implement a similar self-throttling, where
> tokenizing continues on the main thread so long as it is cheap to do so?
>
> -Filip
>
>
> On Jan 9, 2013, at 6:00 PM, Eric Seidel  wrote:
>
> > We're planning to move parts of the HTML Parser off of the main thread:
> > https://bugs.webkit.org/show_bug.cgi?id=106127
> >
> > This is driven by our testing showing that HTML parsing on mobile is
> > be slow, and long (causing user-visible delays averaging 10 frames /
> > 150ms).
> > https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002
> > Complete data can be found at [1].
> >
> > Mozilla moved their parser onto a separate thread during their HTML5
> > parser re-write:
> >
> https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading
> >
> > We plan to take a slightly simpler approach, moving only Tokenizing
> > off of the main thread:
> >
> https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit
> > The left is our current design, the middle is a tokenizer-only design,
> > and the right is more like mozilla's threaded-parser design.
> >
> > Profiling shows Tokenizing accounts for about 10x the number of
> > samples as TreeBuilding.  Including Antti's recent testing (.5% vs.
> > 3%):
> > https://bugs.webkit.org/show_bug.cgi?id=106127#c10
> > If after we do this we measure and find ourselves still spending a lot
> > of main-thread time parsing, we'll move the TreeBuilder too. :)  (This
> > work is a nicely separable sub-set of larger work needed to move the
> > TreeBuilder.)
> >
> > We welcome your thoughts and comments.
> >
> >
> > 1.
> https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0
> > (Epic thanks to Nat Duca for helping us collect that data.)
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

[Antti Koivisto]

On Fri, Dec 21, 2012 at 3:33 AM, Tab Atkins Jr. wrote:

> No, it's just a refactoring on the CSS side, so we don't have to
> repeat a bunch of stuff every time we have an at-rule that contains
> other rules.  It just makes the WebIDL easier and less error-prone.
>

It seems bit strange to add a web-exposed type if it is just a spec writing
helper. Each new type has non-zero cost (code size of generated bindings
etc).

Internally it obviously makes sense to share code, I'm just wondering why
we would want to expose this via API.


   antti


>
> ~TJ
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] CSSGroupingRule and a bit of refactoring?

[Antti Koivisto]

We already have internal type corresponding to the new
CSSGroupingRule, StyleRuleBlock. Technically refactoring the CSSOM like
this would be fairly trivial.

It is not clear to me what value this new type adds though. In JS you don't
really care if types have a common base as long as they share similar
looking interface. Are there some concrete use cases?


  antti


On Thu, Dec 13, 2012 at 3:41 AM, Pablo Flouret  wrote:

> Hello webkit folk,
>
> I'm working on having @supports behave like a proper CSSSupportsRule [1].
>
> In the css3-conditional spec, CSSSupportsRule inherits from a
> CSSGroupingRule (CSSMediaRule does as well):
> http://dev.w3.org/csswg/css3-conditional/#the-cssgroupingrule-interface.
>
> I'm wondering if it's a good idea, as a first step, to do a bit of
> refactoring and rip the stuff that's now in CSSGroupingRule from
> CSSMediaRule (cssRules/insertRule/deleteRule), and have the supports
> and media rules inherit from it.
>
> Incidentally, i see at least WebKitCSSKeyframesRule and
> WebKitCSSRegionRule also having similar but not quite identical
> re-implementations of these functions, but i guess whether these ones
> should also inherit from CSSGroupingRule might be a question for the
> standards mailing lists first (in any case, they would potentially
> benefit from such a refactoring).
>
> Opinions / advice / potential problems?
>
> Thanks!
>
> [1] http://wkbug.com/104822
>
> --
> pablo flouret
> motorola | webkit / browser team
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Prefix naming scheme for DOM-exposed functions

[Antti Koivisto]

On Fri, Dec 7, 2012 at 1:36 PM, Maciej Stachowiak  wrote:

>
> Would this involve creating a bindingsFoo() for every method foo() that is
> exposed to bindings? For example, would we have to add
> XMLHttpRequest::bindingsSend(), even though there's no real need for a
> special internal XMLHttpRequest::send()? Would getters and setters that map
> to JavaScript properties (but which do not reflect markup attributes) also
> need a bindings... version? For example, would we need
> HTMLMediaElement::bindingsMuted() and HTMLMediaElement::bindingsSetMuted()
> to wrap the regular muted() and setMuted()?
>

I see no internal clients for HTMLMediaElement::muted()/setMuted() so there
would be no need for internal versions for it. I suspect that in many cases
we would at most need an internal accessor (which could then properly
follow our naming conventions HTMLMediaElement::isMuted()).


> If the answer to these questions is "yes", then I think this is too much
> complexity tax on all exposed methods and properties to make up for the
> benefit. It's likely only a minority of methods where it's highly desirable
> to have a specialized version for internal use.
>

Probably the only way to find out is try doing it and seeing how the patch
ends up looking like.


> As a side note, I don't see how this would address the concrete example
> given, that of firstElementChild likely becoming more efficient than
> firstChild. If we add bindingsFirstChild() and bindingsFirstElementChild(),
> how does this help WebCore developers know that they should use the
> internal firstElementChild() instead of the internal firstChild()? I expect
> both have to exist, because there really are cases where you need to
> traverse the whole DOM, not just elements, and even if we were to convert,
> firstElementChild() is not a drop-in replacement.
>

This would create more freedom for our internal document tree to diverge
from how it looks like through the DOM api. For example internal
firstChild() that returns Node* may no longer make sense at all if we
eliminate Text nodes.


  antti


> It also seems to me that internal methods that do the exact same thing as
> a bindings...() version but lack an ExceptionCode parameter, we'll still
> want to avoid excess code duplication, in some cases of tricky algorithms.
> I would not want a second copy of ContainerNode::insertBefore() and its
> helper methods that replaces exception checking with preflight checks that
> return false without setting an exeption code (I don't think you can just
> skip the checks entirely or you'd make a method that is extremely dangerous
> to call if you have not met very complex preconditions).
>
> I do agree with the goal of having efficient internal interfaces that are
> not constrained by what is exposed to the Web, but a blanket introduction
> of methods just for bindings does not seem like a good way to get there.
>
> Possible alternatives:
> - Use something in the IDL to call a bindings... variant only in cases
> where we know there is a materially better internal method.
> - Use the style checker to ban calling select exposed methods from
> hand-written WebCore code, and give the corresponding internal methods
> different names.
>
> These approaches could achieve the goals described for critical DOM
> methods without having to infect things like XHR::send() or
> HTMLMediaElement::setMuted().
>
> Regards,
> Maciej
>
> On Dec 7, 2012, at 9:27 AM, Darin Adler  wrote:
>
> > Hi folks.
> >
> > Many of the APIs designed for use in the DOM are not efficient for use
> inside WebKit, or have designs that are better for JavaScript than for C++.
> Antti Koivisto and I have been discussing how to best communicate this to
> WebKit contributors so they don’t end up using inefficient idioms just
> because they are familiar with them from use in JavaScript code on
> websites. So far, our best idea for this is to add a prefix to function
> names that indicate they are functions for use by the bindings machinery.
> Thus, a function like appendChild would get a new name:
> >
> >void bindingsAppendChild(Node*, ExceptionCode&);
> >
> > The internal function that’s used to add a child node would be designed
> for the best clarity, ease of use, and efficiency within WebKit
> implementation code, even when that does not match up with the DOM
> standard. And could be refactored over time as WebKit design changes
> without affecting the bindings.
> >
> > - It’s not clear what the best prefix is. I don’t like the prefix “dom”,
> since it’s a lowercased acronym and an overloaded not all that precise
> term. The prefix “bindings” is sort of silly because these functions are
> not themselve

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

[Antti Koivisto]

On Wed, Oct 31, 2012 at 12:05 AM, Alexey Proskuryakov  wrote:

> This will mean that cache is always almost empty, and all resources in it
> are extremely fresh. I don't know if this would provide substantial
> additional test coverage over cleaning the cache all the time, or just
> completely disabling it in WebKitTestRunner.
>

Certain areas of coverage would improve. The code paths taken when a
resource is restored from the memory cache can be quite different from the
usual loading. Many operations (like script execution) happen synchronously
if the resource is found from the cache. We reuse various decoded forms
(bitmaps, stylesheets, jsc parse structures, likely more in the future).
All data is available in single chunk. It is possible to write tests that
detect these differences (and it is possible that some tests hit them
accidentally).

We would still lose coverage for things that depend on having lots of
resources around like cache pruning.


   antti


> - WBR, Alexey Proskuryakov
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] On returning mutable pointers from const methods

[Antti Koivisto]

I don't think the original proposal was meant to apply to the basic
container types. Would this be a sensible rule to adopt for WebCore only
for example?

Like all our "blanket rules", this one should be ignored when it doesn't
make sense. If that kind of cases are expected to be very rare then their
existence shouldn't be a show stopper for adopting the rule.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

[Antti Koivisto]

We could clear the cache between tests but run each test twice in a row.
Second run will then happen with deterministically pre-populated cache.
That would both make things more predictable and improve our test coverage
for cached cases. Unfortunately it would also slow down testing
significantly, though less than 2x.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

[Antti Koivisto]

On Fri, Oct 26, 2012 at 6:09 PM, Ami Fischman  wrote:

> The reality is that this "test coverage" today shows up as flakiness and
> so is ignored anyway, meaning we don't actually have useful coverage here.
>  Even when flakiness is investigated, the "fix" is to cache-bust using
> unique URL params, which just means we "lose" the coverage you describe for
> that test, anyway.
>

When making cache related changes I have frequently found bugs from my
patches because some seemingly random test started failing and I
investigated. Without the test coverage some of those bugs would probably
now be in the tree.


  antti


>
> Brian notes in the bug that GTK & wk2 GTK+ are done.
> I believe that just leaves chromium & mac.
> Anyone wanting to step up to do mac, and, I guess, wk2 mac?
>
> -a
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

[Antti Koivisto]

On Wed, Aug 8, 2012 at 9:54 PM, Eric U  wrote:

> On Wed, Aug 8, 2012 at 11:43 AM, Alexey Proskuryakov 
> wrote:
> > I can see some downsides to emptying the cache before each test:
> >
> > - we won't be getting any test coverage for cache behavior when it hits
> > non-trivial size;
>
> Then let's add a cache test explicitly for this.  Otherwise we just
> have to hope it gets tested accidentally along the way.
>

Cache has subtle interactions with other things being tested (->flakiness).
More explicit cache tests would be nice but we can't hope the replicate all
the accidental testing we now get. We are going to lose a large chunk of
existing test coverage if we do this.


  antti


>
> > - this may well make tests measurably slower;
> >
> > - this will be yet another cause of subtle difference between platforms,
> as
> > some will undoubtedly have this unimplemented for a long time.
>
> Both good points, but probably worth it, given the reliability
> improvement in the tests IMO.
>
> Eric
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] On returning mutable pointers from const methods

[Antti Koivisto]

On Thu, Oct 25, 2012 at 1:48 PM, Andreas Kling  wrote:

>
> So, I propose that we allow only these two signature formats for raw
> pointers:
>
> - const Foo* foo() const;
> - Foo* foo();
>

I think this would be an excellent rule to adopt for new code. The
mutable/immutable state pattern is a powerful way to optimize data
structures that are rarely mutated. Correct use of const through the code
makes using it much easier and safer. With adaption of PassRef/OwnPtr I
can't think of any correct uses for Foo* foo() const.


   antti

Moreover, for methods that return references to objects where call sites
> are expected to take a strong reference, we should really be using
> PassRefPtr as the return type.
>
> Thoughts? Objections? Am I missing something?
>
> -Kling
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Antti Koivisto]

On Tue, Oct 9, 2012 at 10:02 PM, Adam Barth  wrote:

> This is interesting data, but it seems to be related to whether we
> should make the MemoryCache content addressable rather than whether we
> should use shared memory to back the MemoryCache when there are
> multiple WebProcesses.
>

It is relevant when considering if and how to share cache data between
processes. It is also interesting in single process case. Brady's
refactoring should be helpful for both scenarios.


  antti


> Adam
>
>
> >> You can also expect that we won't push forward blindly on this effort if
> >> data ultimately shows it to be a bad idea, or in general not worth the
> >> complexity.
> >>
> >> Regards,
> >> Maciej
> >>
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Discussing bug 98539 - Refactor resource loading to allow for out-of-process loading and memory caching

[Antti Koivisto]

On Tue, Oct 9, 2012 at 4:21 AM, Maciej Stachowiak  wrote:

> One preliminary finding of ours is that different web pages fairly often
> load identical resource bodies from different URLs. We expect possible
> benefits from sharing the body data of resources in memory even if we
> cannot share the URL or response headers.
>

I did some preliminary profiling of this earlier. The data is not
necessarily very representative of the web as whole, I simply browsed
through a number of popular sites with an instrumented build (
https://bug-98539-attachments.webkit.org/attachment.cgi?id=167753). Here is
what I had in the WebCore memory cache in the end:

TOTAL duplicates count=443 size=852791 decodedSize=3426638
all cached resources count=2636 size=116463712

17% of cache entries are exact copies of previous entries. They use 4.3MB
out of total 116MB cache size (4%). The average size of duplicate entries
is much smaller than the average entry size (not surprisingly, transparent
1x1 images etc).

Some examples:

HTTP vs. HTTPS:

hash=5d90af size=91556 decodedSize=34834
https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js
hash=5d90af size=91556 decodedSize=32
http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js

(decodedSize for js resources is the size of the function offset cache
which can differ depending which functions have been parsed).

Ad scripts with deliberately unique URLs:

hash=6f6494 size=3111 decodedSize=32
http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=76273718
?
hash=6f6494 size=3111 decodedSize=648
http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=711567314
?
hash=6f6494 size=3111 decodedSize=32
http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=908690779
?
hash=6f6494 size=3111 decodedSize=32
http://ad.doubleclick.net/adj/teg.fmsq/j2ek;subs=n;wsub=n;sdn=n;dcopt=ist;pos=ldr_top;sz=728x90,970x90;tile=1;ord=876087584
?

Same framework loaded by multiple unrelated sites:

hash=230c7d size=1958 decodedSize=0
http://static.iltalehti.fi/js/measure/spring.js
hash=230c7d size=1958 decodedSize=1536 http://yle.fi/global/spring/spring.js

(didn't see as many of these as expected though i'm sure there are sites
that run into this)

Copy-paste resources:

hash=8fb3e size=3965 decodedSize=13088
http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif
hash=8fb3e size=3965 decodedSize=13088
http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/features/search/css/bg/spinner.gif
hash=8fb3e size=3965 decodedSize=13088
http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/source/store/base/nav/globalnav/css/bg/globalsearch_spinner.gif
hash=8fb3e size=3965 decodedSize=13088
http://images.apple.com/global/nav/images/globalsearch_spinner.gif

Versioning:

hash=cecbad size=184899 decodedSize=0
http://store.storeimages.cdn-apple.com/2150/store.apple.com/rs/applestore-rs-2.css
hash=cecbad size=184899 decodedSize=0
http://store.storeimages.cdn-apple.com/2149/store.apple.com/rs/applestore-rs-2.css

hash=47a8de size=20041 decodedSize=7870
http://js.t.sinajs.cn/open/analytics/js/suda.js?version=b4d67909ad6b5b7d
hash=47a8de size=20041 decodedSize=7870
http://tjs.sjs.sinajs.cn/open/analytics/js/suda.js

Multiple content servers:

hash=8e976b size=808 decodedSize=13088
http://i0.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif
hash=8e976b size=808 decodedSize=71700
http://i3.sinaimg.cn/home/deco/2008/0329/sinahome_0803_ws_003_new.gif

Based on this I think this is definitely worth at least looking further.


  antti

You can also expect that we won't push forward blindly on this effort if
> data ultimately shows it to be a bad idea, or in general not worth the
> complexity.
>
> Regards,
> Maciej
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Eliminate potential null pointer dereference?

[Antti Koivisto]

Sat, Apr 21, 2012 at 8:13 AM, John Yani  wrote:

> 2316if (selector->relation() != CSSSelector::SubSelector)
> 2317break;
> 2318selector = selector->tagHistory();
> 2319};
>
> Now selector is null and we are trying to call tagHistory():
>

This is not possible. If selector->relation() == CSSSelector::SubSelector
then there will always be a subselector in tagHistory.


> 2321for (selector = selector->tagHistory(); selector; selector =
>
> Which will result in segfault.
>

That would indicate a serious bug in CSS parser. The crash would allow us
to catch and fix the bug. Now the bug is hidden. We have also lost some
documentation (in form of code) on how our data structures look like. The
only sensible change here would have been ASSERT(selector) for
documentation purposes.

There is generally too much pointless drive-by refactoring going on in the
project. I think we should take harder line against these "No new test /
code cleanup only" type patches to reduce noise level.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] How to use ASSERT_NO_EXCEPTION

[Antti Koivisto]

On Thu, Dec 15, 2011 at 8:36 AM, Darin Adler  wrote:

>ExceptionCode ec;
>appendChild(newChild, ec);
>ASSERT(!ec);
>

Often code like this indicates misuse of DOM API functions for internal
purposes. This is inefficient (due to exception related checking and other
spec mandated behaviors) and architecturally bad (ties our internal data
structures to DOM way of presenting them, see stylesheet related classes).

I'm not sure it is a good idea to make these cases less visible.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Using C++ constant local variables in WebKit

[Antti Koivisto]

On Thu, Dec 1, 2011 at 4:26 AM, Ojan Vafai  wrote:

> I don't mind using const in some cases, but I share Darin's concern of
> littering the code with consts. I'd prefer that
>
we come up with a fairly conservative guideline about when to use it. I'm
> not sure what that would look like. We could start with, what's special
> about this case, or string parsing in general that makes using const more
> valuable?
>

Littering the code with anything is bad. Has misuse of consts been a
significant practical problem? Perhaps we don't need a specific rule here.


   antti


>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] old-run-webkit-tests is officially deprecated.

[Antti Koivisto]

On Fri, Oct 28, 2011 at 1:00 AM, Eric Seidel  wrote:
>
> If you're still using old-run-webkit-tests for your work, I would
> *love* to know and fix any issues you may have with NRWT.
>
>
The lack of locale independence is a showstopper for me,
https://bugs.webkit.org/show_bug.cgi?id=68691.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Compile-time assertions for object sizes

[Antti Koivisto]

On Thu, Sep 29, 2011 at 9:40 PM, Andreas Kling  wrote:

> One idea is to add a file that would only be built on (for example) 64-bit
> Mac and then at least that bot would break if an object changes size. That's
> obviously not ideal though.
>

I like that approach as it allows you to explicitly assert against byte
counts. Other approaches are more abstract and so easier to dismiss when
checking in a bloaty patch. It also documents the byte sizes and makes
progressions explicit too.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Implementing

[Antti Koivisto]

On Fri, Sep 9, 2011 at 12:28 AM, Roland Steiner
wrote:

>
> ad 3.) Implementation of scoped selector matching works as follows:
>
> .) scoped style sheet rules are contained in a separate map  element address> -> RuleSet
> .) add a field to ParentStackFrame that identifies the
> closest ParentStackFrame that refers to a scoping element
> .) during matching only check RuleSets that are thusly identified in
> ParentStackFrame (plus a slow path that climbs the tree in case
> ParentStackFrame isn't applicable), plus global rules
> .) add a 'scope' parameter to the matching functions that identifies the
> scoping element that limits the matching.
>
> Note that with this implementation rules in scoped RuleSets that are not
> "in scope" aren't even looked at. Also note that the actual selector data is
> NOT modified for this. I.e., a selector in a scoped style sheet is not
> different from a global selector. This has several benefits:
>

Sounds good to me. We don't currently rely on ParentStackFrames to get any
semantics right, it is just for performance optimization. You will need to
take care that it is now functional (rebuild as needed) in all cases.

Inroducing root should be ok for fastCheckSelector path too, testing against
root element shouldn't be slower than testing against null.

I was anyway thinking of moving the parent stack to SelectorChecker. With
this it will actually be needed for querySelectorAll.


   antti


>
> .) no updating necessary if a 

Re: [webkit-dev] Preload Scanner in WebKit

[Antti Koivisto]

On Fri, Feb 11, 2011 at 9:11 AM, Adam Barth  wrote:
> We run the preload scanner when the regular parser is blocked on the
> network.  CSS and other sub-resources don't block the main parser
> whereas scripts do.

If the main parser encounters an script tag (including inline scripts)
it will also block on any external CSS load that was triggered earlier
in the document.


   antti

>
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] beforeload & link (esp rel prefetch)

[Antti Koivisto]

2011/1/13 Darin Fisher :
> Supporting the Link header enables web servers to inject  tags without
> modifying the document, which can be useful, especially for intermediaries.

That sounds like a great reason not to support this feature. Why would
we want to make the web more unpredictable and harder to understand?

>From prefetching perspective this has little or no value. When we get
the response header we are generally milliseconds away from parsing
the real document text and requesting the linked resources properly.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 & Web Links (RFC 5988)

[Antti Koivisto]

Even for prefetching this seem rather worthless as it won't allow
prefetching start significantly earlier over the resources specified
in the document source.

There is also (based on the experience in similar things) a high
chance that whatever is listed in the Link header won't match what the
document actually uses and so will end up slowing down the page load.


  antti

2010/11/9 Gavin Peters (蓋文彼德斯) :
> Firefox supports it for rel=prefetch, and it was my thought to include that
> support in my patch.  That use is worthwhile: it allows server specification
> of prefetch resources, as opposed to author (as in HTML).l
> - Gavin
>
> On 9 November 2010 12:20, Maciej Stachowiak  wrote:
>>
>> On Nov 9, 2010, at 9:00 AM, Alexey Proskuryakov wrote:
>>
>> >
>> > 09.11.2010, в 03:51, Alex Milowski написал(а):
>> >
>> >> Now that RFC 5988 is a proposed standard [1] and HTML5 references the
>> >> "Link:" header [2]
>> >
>> >
>> > Note the way in which HTML5 references it: "Some versions of HTTP
>> > defined a Link: header". That's about HTTP 1.0 only.
>> >
>> > Specifying stylesheets in HTTP headers seems like a most obvious
>> > misfeature to me, and other potential uses of the Link header field are so
>> > unimportant that RFC 5988 doesn't even bother to mention them in its
>> > introduction.
>>
>> It might be worth testing which other browsers support it. I know at least
>> Firefox supports associating a stylesheet with Link. It does seem like a
>> fairly ill-conceived feature, but not so much that it is worth being the
>> sole holdout, if other browser engines all do it. And there are some
>> plausible use cases - same document served with multiple stylesheets,
>> without having to modify the document on the fly, just the headers.
>>
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Tightening up smart pointer usage rules

[Antti Koivisto]

Is the plan also to banish the std::auto_ptr? It seems pointless and
confusing to allow both the OwnPtr and the auto_ptr.


  antti (who wants PwnPtr too)

On Mon, Jun 28, 2010 at 11:39 PM, Darin Adler  wrote:
> Hi folks.
>
> I’d like to use our smart pointers more consistently to decrease the chances 
> of memory leaks or other similar problems.
>
> My proposal is that we have a rule that all calls to "new" are immediately 
> followed by putting the object into a smart pointer. The main types of smart 
> pointer that matter for these purposes are:
>
>    RefPtr
>    OwnPtr
>    OwnArrayPtr
>
> Today, we put a new reference counted object into a RefPtr by calling 
> adoptRef. The code looks something like this:
>
>    PassRefPtr createSharedObject()
>    {
>        return adoptRef(new SharedObject);
>    }
>
> I propose we do the same thing with single ownership objects. It would look 
> like this:
>
>    PassOwnPtr createSingleOwnerObject()
>    {
>        return adoptPtr(new SingleOwnerObject);
>    }
>
> Then it would be a programming mistake to call new without immediately 
> calling adoptPtr or adoptRef. As part of this effort I plan to do the 
> following:
>
>    1) Add a debugging mode where we assert at runtime if we ref, deref, or 
> destroy a RefCounted object before doing adoptRef. Tracked in 
> .
>
>    2) Add an adoptPtr function that returns a PassOwnPtr, and a releasePtr 
> function that returns a raw pointer to the PassOwnPtr class.
>
>    3) Add a PassOwnArrayPtr with similar adoptArrayPtr and releaseArrayPtr 
> functions.
>
>    4) Add a strict mode to PassOwnPtr and OwnPtr which removes OwnPtr::set 
> entirely and removes the ability to construct a PassOwnPtr or OwnPtr from a 
> raw pointer directly, making it a compile time error to forget to use 
> adoptPtr.
>
>    5) Once everything compiles with the strict mode, make the strict mode the 
> only mode.
>
>    6) Add validator rules that make invocation of the "new" operator legal 
> only inside adoptRef and adoptPtr function calls.
>
> Code that used to say this:
>
>    OwnPtr m_otherObject;
>    ...
>    m_otherObject.set(new OtherObject);
>
> Will now say this:
>
>    OwnPtr m_otherObject;
>    ...
>    m_otherObject = adoptPtr(new OtherObject);
>
> And one thing that’s cool about that is it is quite natural for this to 
> become:
>
>    OwnPtr m_otherObject;
>    ...
>    m_otherObject = OtherObject::create();
>
> I thought I’d mention this to everyone on the list before getting doing 
> significantly more work on this. I think it’s going to work well. Any 
> questions or comments?
>
>    -- Darin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 tokenizer landing soon

[Antti Koivisto]

Cool. Are you going to switch the PreloadScanner to the new tokenizer too?


  antti

On Mon, Jun 14, 2010 at 8:21 AM, Adam Barth  wrote:
> People of WebKit,
>
> As mentioned recently on webkit-dev, Eric, Tonyg, and I have been
> working on implementing the HTML5 parsing algorithm in WebKit:
>
> http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11472.html
>
> We're now ready to turn the new tokenization algorithm on by default
> (probably early this week).  The new code passes all the existing
> LayoutTests, with the exception of roughly 40 tests that "expect"
> behavior that violates the HTML5 specification [1].
>
> There are some differences between the old parser and the HTML5
> parser.  We've written up a brief document outlining those
> differences:
>
> https://docs.google.com/document/edit?id=1as5xYjyMSCph4960iz0-Kb7hZKf_L6f2vts57NMcVBI&hl=en
>
> If these differences cause real compatibility issues on the web, we
> should contribute this information to the working group so we can
> improve the specification.  If these differences cause compatibility
> issues for WebKit-specific HTML (e.g., for Dashboard widgets), we
> might need to add a flag to support some subset of these parsing
> quirks for non-web uses of WebKit.
>
> Please be on the lookout for parsing-related regressions and CC Eric,
> Tonyg, and me on the bugs.  There's still a lot of work to do
> (including implementing the tree construction algorithm), but turning
> the tokenization code on by default is an important milestone for the
> project.
>
> Happy parsing,
> Adam
>
> [1] See 
> https://spreadsheets.google.com/ccc?key=0AppchfQ5mBrEdDFJUW5DOGNsdmtvZkN0ZmIzMjdaT0E&hl=en
> for details.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Proposal: Rect based HitTest for a better touch experience

[Antti Koivisto]

On Wed, Jun 2, 2010 at 11:22 PM, David Hyatt  wrote:

> I really don't think hit testing needs to be modified to get what you want.  
> You can do a scattershot sampling using multiple candidate points within the 
> rect and apply whatever heuristics you want to choose a node.  I'm also not 
> convinced that we should be complicating core hit testing code in this way, 
> since I suspect this is one of those areas where mobile platforms will each 
> want to do their own slightly different thing anyway.

The problem with hit testing by multisampling is that it is
ridiculously slow. You need to take at least a dozen samples for
decent results. With a complex document on a mobile platform doing
those can take several hundreds of milliseconds. That is pretty far
from what is needed for good responsiveness. I think area hit testing
would make a lot of sense.

With WebKit2 it might actually be a good idea to track all event
sensitive areas in the document. This way at least partial (no
hit/maybe hit) testing could be done entirely in the UI process side.


  antti

> dave
> (hy...@apple.com)
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] PreloadScanner aggressiveness

[Antti Koivisto]

On Fri, Jan 8, 2010 at 3:00 AM, Mike Belshe  wrote:

Nice testing!

But for HTTP; the key seems to the pre-rendering-ready escape hatch in
> DocLoader::preload.  Removing this gives me most all of the benefit.  The
> comment says it pretty clearly:  "Don't preload images or body resources
> before we have something to draw. This prevents preloads from body delaying
> first display when bandwidth is limited."  For SPDY, there is more benefit
> by continuing to preparse aggressively - I suspect this is due to the finer
> grained prioritization where it can continue to send requests up without
> impacting the clogged downlink channel.
>

Yeah, this is currently really optimized for best first display, not for
total load time.

In my testing that escape hatch was pretty important for first display if
the case was bandwidth limited (several seconds on some major sites on 3G).
It is not surprising that it may somewhat hurt total load time in high
bandwidth/high latency case.

Ideally we would have per-site estimate of the current bandwidth and latency
values available so we could tune things like this dynamically.

Any testing of changes here should consider first display times too, not
just total load time.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WebKit runtime image compression

[Antti Koivisto]

On Sun, Dec 14, 2008 at 9:12 AM, Paul Pedriana  wrote:

> For a lot of web pages, images are the primary source of memory usage.
> These images seem to be typically stored as RGB or ARGB data in the
> BitmapImage class. It seems to me that applications that wish or need to
> save runtime memory could benefit from runtime image compression whereby
> images are stored in some compressed form instead of RGB or ARGB formats. I
> am currently looking into this possibility and I'm wondering if anybody has
> previously looked into it.
>
> My current idea is to support two kinds of compressed images: RLE and
> YCoCg-DXT5. The former could be for any images that are simple enough, and
> the latter could be for general images and give a fixed 4:1 compression
> ratio. RGB transforms to YCoCg with better decorrelation (breakdown of RGB
> to YCC) than YCbCr and many images can get PSNR values over 40 (i.e. hard to
> tell from original). If the computer has decent vector processing or a
> programmable GPU, the performance could be decent, otherwise it depends on
> the CPU. (A)RGB could of course remain as a fallback.
>
> I'm wondering if anybody has looked into runtime image compression with
> WebKit and considered options such as this.


Several ports (S60 and Android I think) RLE compress suitable bitmaps. It
does not need WebKit level support.


   antti


>
>
> Thanks.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] http cache support - rfc2616

[Antti Koivisto]

WebKit implements significant parts of RFC 2616 caching logic for it's
internal memory cache and will implement more. See
https://bugs.webkit.org/show_bug.cgi?id=17998 for details.


   antti

2008/11/15 Darin Fisher <[EMAIL PROTECTED]>:
> The http caching logic for chromium lives here:
> http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_cache.cc?view=markup
> WebKit does not have code for a network stack.  Instead, each port provides
> a network stack, typically by using a system library.
> -Darin
>
> On Sat, Nov 15, 2008 at 9:01 AM, zaheer ahmad <[EMAIL PROTECTED]> wrote:
>>
>> hi,
>> Does webkit or any component built with (e.g. chromium) has a full
>> implementation of http caching- rfc2616. a quick search in the code base or
>> the bug list does not suggest one. Looks like some of the pieces from html5
>> application cache can be reused for such an implementation. kindly suggest.
>> thanks,
>> Zaheer
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Windows build now requires QuickTime SDK

[Antti Koivisto]

Hi,

I just checked in the timed media support ( and ) for
Windows. This means that Windows build now depends on the QuickTime
SDK which can be downloaded from here:

http://developer.apple.com/quicktime/download/

Note that QuickTime itself is not required to build, just the SDK.


   antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Re: [webkit-changes] [24907] trunk

[Antti Koivisto]

These are good ideas. O(n^2) fixes really should have regression tests
attached, like any other bug fixes.


  antti

On 8/8/07, Andre-John Mas <[EMAIL PROTECTED]> wrote:
> I am just wondering whether it should be the other way round, in that
> how many iterations can be done in time x. The logic here is that as
> processors gets faster a given number of iterations will eventually
> reach a value near zero. On the other hand for a given time period
> there is much more room for expansion on the number of iterations
> possible.
>
> Andre
>
> On 7-Aug-07, at 19:04 , Mitz Pettel wrote:
>
> > If I understood the bug fix and the test correctly, then a test
> > like this might work: do 5000 iterations (instead of 3) and
> > look at the ratio between the time the first 500 and last 500
> > iterations take.
> >
> > On Aug 7, 2007, at 5:22 PM, Antti Koivisto wrote:
> >
> >> On 8/7/07, Mitz Pettel <[EMAIL PROTECTED]> wrote:
> >>> On Aug 7, 2007, at 2:15 PM, [EMAIL PROTECTED] wrote:
> >>> - added performance test. With debug build on MBP this takes
> >>> about 1.5s to
> >>> run.
> >>>
> >>> * fast/block/basic/stress-shallow-nested-expected.txt: Added.
> >>> * fast/block/basic/stress-shallow-nested.html: Added.
> >>>
> >>> (emphases mine). Nothing about that makes sense to me.
> >>
> >> Are you objecting to testing performance regressions as part of the
> >> test suite in general or particular method here? I'm open to
> >> suggestions.
> >>
> >> It does not take long to run (300ms on release, 1.5s on debug MBP) so
> >> I thought it would be appropriate for automatic test. There are
> >> similar cases in the suite already. It needs to have non-zero
> >> execution time so that O(n^2) nature of the bug shows up in testable
> >> way.
> >>
> >>
> >>   antti
> >>
> >>> ___
> >>> webkit-dev mailing list
> >>> webkit-dev@lists.webkit.org
> >>> http://lists.webkit.org/mailman/listinfo/webkit-dev
> >>>
> >>>
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Re: [webkit-changes] [24907] trunk

[Antti Koivisto]

On 8/7/07, Mitz Pettel <[EMAIL PROTECTED]> wrote:
> Hi Antti,
>
> I do not understand the purpose of the test and how it is supposed to
> serve that purpose (two of the reasons that I am baffled are that it
> is my understanding that there are facilities to track performance
> within fractions of a percent, and that I am not aware of other tests
> that have use elapsed time internally as their success criterion).

In this case a particular narrow aspect of performance was testable in
way that can be executed as part of the automatic suite.

I can find only one directly timing related case,
LayoutTests/fast/forms/slow-click.html (thought  tests in
branch have a ton more). I suspect number of others are timing
dependent indirectly.

 > On the computer I run the tests on, that single test alone takes
> roughly as much time as all the other 229 tests in fast/block together.

It does? That is suprising. For me fast/block takes 8.2s, 1.5s is
spent in this particular test. Fast/block is generally one of the
fastest sets, http set takes 50s for 184 tests, several of which are
slower than this.

But yes, I should probably remove the test since it has so much impact
on slower systems.


  antti
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Re: [webkit-changes] [24907] trunk

[Antti Koivisto]

On 8/7/07, Mitz Pettel <[EMAIL PROTECTED]> wrote:
> On Aug 7, 2007, at 2:15 PM, [EMAIL PROTECTED] wrote:
>  - added performance test. With debug build on MBP this takes about 1.5s to
> run.
>
>  * fast/block/basic/stress-shallow-nested-expected.txt: Added.
>  * fast/block/basic/stress-shallow-nested.html: Added.
>
> (emphases mine). Nothing about that makes sense to me.

Are you objecting to testing performance regressions as part of the
test suite in general or particular method here? I'm open to
suggestions.

It does not take long to run (300ms on release, 1.5s on debug MBP) so
I thought it would be appropriate for automatic test. There are
similar cases in the suite already. It needs to have non-zero
execution time so that O(n^2) nature of the bug shows up in testable
way.


   antti

> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev