[webkit-dev] WinCairo Update

[Olmstead, Don]

Hello WebKittens,

I wanted to give an update on the status of WinCairo to the group as we've hit 
a few good milestones.

WebKitForWindows Github organization

We went ahead and created a WebKitForWindows organization on Github at 
https://github.com/WebKitForWindows where we will be working out of. This has 
the WinCairoRequirements and tooling around building WinCairo. The hope is this 
makes things easier for third-parties building WinCairo.

We'll also be using it to experiment with a way to update ANGLE on a more 
regular cadence.

WinCairoRequirements is up to date

The previous incarnation of WinCairoRequirements run by Per Arne hadn't been 
updated in over a year and a half. Now all the requirements are up to date 
except for ICU. The thing holding us back from updating ICU to 60 is the 
dependency on CFLite. This is something we want to get rid of completely but 
have not exorcised the CF code from WebKitLegacy. After that we'll be doing the 
work to get ICU 60+ working on Windows.

WinCairoRequirements also got a few additions. We've added nghttp2 and have 
been compiling cURL with it to get support for HTTP2. The work to enable it 
will be ongoing. We've also added WebP and will be enabling that shortly.

Windows Docker images for development

Internally we've been big proponents of using Docker for our CI/CD workflows. 
With Windows gaining support for that we took a stab at creating Docker images 
for WebKit development.

We have images that contain all the tools for WebKit, Perl, Python, etc, and 
also Visual Studio 2017 build tools. You can build WinCairo completely in a 
Docker container for your own development using these images. It should also be 
able to build AppleWin.

Additionally we have images for Buildbots and EWS.

EWS is live!

As Aakash mentioned in a previous message WinCairo now has an EWS for release 
builds. Currently we have 5 bots running which seems to be successful thus far. 
Our bots are doing builds within Windows Docker containers so we can easily 
scale out further as needed.

We ask that you respect the EWS as much as possible when landing your patches. 
We made it a point to prioritize the work because there were a number of times 
when we would have to fix the build after our buildbots determined there was an 
error.

WebKit(2) development

Windows on WebKit(2) is still ongoing. We still have a lot of patches to land 
there. After we can build it we'll introduce a Buildbot and EWS for it to make 
sure things stay working.

Visual Studio 2017

All our bots and all our developers are using VS2017 so we are all for 
deprecating VS2015 whenever Apple's build structure is ready.

That's about it for now. If you have any questions or comments let us know.

Thank you for all the assistance in getting this far!

Sony's WebKit Team
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Upstreaming from LayoutTests to web-platform-tests, coordinating Blink+WebKit

[Philip Jägenstedt]

(From Nov 24, I used the wrong email, resending for the archives.)

On Sat, Nov 18, 2017 at 8:02 AM, youenn fablet  wrote:
> Thanks for taking the time to share this additional information.
> I think this is helpful to make progress.
> Please see inline for some more comments related to the points you are
> bringing to the table.
>
> Stepping back from the WPT server specific issue, being optimistic and
> assuming that we are able to run WPT tests with good enough performances.
> Migration potential downsides I heard so far:
> - Prioritization of tests to investigate might be harder.
> - Sharing tests with other teams might be harder if subresource links are
> not relative.
> These two seem like solvable issues to me.
>
> Le ven. 17 nov. 2017 à 10:09, Alexey Proskuryakov  a écrit :
>>
>>
>> 17 нояб. 2017 г., в 9:18, youenn fablet  написал(а):
>>
>>
>> Chris recently noticed that some heavily used files (testharness*) were
>> cacheable through Apache but not WPT.
>> This is now fixed and should improve WPT performances.
>>
>>
>> This is part of , another
>> part is that the server is 10x slower than Apache.
>
>
> Other measurements showed 3x slower, which makes it still worthwhile to
> explore.
> We need to be cautious here though since optimization is all about chasing
> where time is actually spent.
>
> If we can prove to ourselves that this is an important issue, we should
> discuss with the WPT community to see how to fix this issue.
> In addition to better caching, other optimization like
> https://github.com/w3c/wptserve/pull/86 may bring some additional benefit.
>
> If we do not find any good solution at WPT server level, we still have the
> option to run some tests as file-based.
> Ryosuke mentioned the possibility to classify tests at import time by
> checking their results when served through WPT server and as file URLs.

Thanks for filing https://github.com/w3c/web-platform-tests/issues/8391, Youenn!

I've put a placeholder around this in our planning for next quarter.
At a minimum, I'd like to investigate this and see how much slower the
tests are in Chromium's infra than they would be without wptserve, and
where that extra time is spent. But the reasons may not be the same in
WebKit, so please don't count on any improvement :)

>> I just tested on my MacBook Pro, and WPT tests took 23% of time while
>> being only 9% of the total count. Taking in mind that WebKit own tests have
>> higher value due to the way we choose what to test (see below), that's not a
>> great story in my opinion.
>
>
> These numbers are difficult to interpret.
> WPT authoring style is multiple tests in a single file, which is bad for
> stability but potentially good for performances.
> WebKit usually prefers one file/one test.
>
> If we want to talk to WPT community about this, we need to provide some more
> tangible numbers.
> We could try to run a large subset of WPT tests that run the same through
> Apache and WPT.
> I just did that on a small subset of IDB tests. This seems to show something
> like a 25% slowdown.
>
>> One other thing that we discussed before was the operational complexity of
>> running WPT tests. We frequently need to share tests with people who don't
>> work on WebKit directly, but have the need to edit and run our tests.
>> Inability to drag and drop a local copy into a Safari window is a deterrent
>> to addressing problems caught by the tests. I think that the response we got
>> was that tests will continue to require a server to run.
>
>
> Tests are available at https://w3c-test.org which makes it easy to share
> through any tool supporting hyperlinks.
> A webarchive can also be made so that it is easy to share and probably edit
> such tests.
> Tools like jsfiddle are also a great way to create/share/edit tests.
> I received several bug reports on bugzilla using it and this proved to be
> efficient.
>
>>
>> Let me explain why I think that WebKit tests are often more valuable as
>> regression tests than WPT tests are. We add tests as we fix bugs, so we know
>> that the tests are generally for problems that have a high impact on users
>> and developers - that's because someone actually discovered the problem, and
>> someone prioritized it highly enough to fix. We also know that our tests
>> cover code that is error prone, which is why we had bugs in the first place.
>> Of course, anything can be broken, but certain things are less likely to.
>> Compliance tests written for specs are also valuable, but at some point we
>> need to prioritize which tests to investigate and even to run.
>
>
> I don't really see why we should prioritize the tests to run when all of
> them provide clear value to some WebKit members.
> I agree that we need to prioritize tests we investigate. There can be a
> solution inside WPT, like adding WebKit specific metadata so that:
> - WPT contributors would communicate with