September 2018 - webkit-dev - lists.webkit.org

Is gperf really needed when building the JSCOnly with CMake?
by Koby Boyango 01 Oct '18

01 Oct '18

Hi I'm currently experimenting with using the new Azure Pipelines as the CI platform for node-jsc. While setting up the Windows test, I had to add some extra steps in order to add gperf and make sure CMake's find_package finds it. Currently, gperf is required for all CMake ports, as it is checked in WebKitCommon.cmake. But searching the WebKit repo, it seems that it's only used when building WebCore, making it unnecessary for the JSCOnly port (which is by node-jsc). So, do you think it could be excluded from JSCOnly port's dependencies? Thanks, Koby

3 3

WinCairo EWS bot broken?
by Ryosuke Niwa 01 Oct '18

01 Oct '18

e.g. https://webkit-queues.webkit.org/results/9390719 Processing C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\unknwn.idl midl : command line error MIDL1016 : cannot create intermediate file C:\Users\ContainerAdministrator\AppData\Local\Temp\MID8103.tmp [3047/6194] Generating ../../DerivedSources/WebKitLegacy/Interfaces/AccessibleStates.h Microsoft (R) 32b/64b MIDL Compiler Version 8.01.0622 - R. Niwa

2 1

MSVC and the state of C++17
by Chris.Reid＠sony.com 29 Sep '18

29 Sep '18

Hi all, Right now MSVC based ports are still using C++17. We wanted to open up the discussion on some questions that were raised internally regarding the state of C++17 and MSVC. 1. Should MSVC continue using C++17 or switch back to C++14 for consistency with other ports? The main concern to continue using C++17 was with Windows developers inadvertently relying on C++17 features when working in shared code. I'm not sure how big of a concern that is given that EWS should ideally catch it and I don't believe it has been an issue so far. This also raises the question of how far away other ports are from switching back to C++17. 2. If MSVC should continue using C++17, is it safe to go forward using C++17 features in code only touching Windows ports? Looking at the current state of C++17 on other ports, it seems a bit concerning to go forward with C++17 features. - Chris

2 1

2018 WebKit Contributors Meeting - Last Change to Register!
by Jonathan Davis 26 Sep '18

26 Sep '18

Hello WebKit Contributors, This Friday, September 28th is the last chance to register to attend the annual WebKit Contributors Meeting to be held at the Hyatt House San Jose/Silicon Valley hotel on Friday, October 12th, 2018 from 8 AM to 6 PM Pacific. If you haven’t registered yet, you should register soon. We have limited space and spots are filling up! Sign up at https://webkit.org/meeting/ <https://webkit.org/meeting/> to reserve your spot. The meeting is free of charge, but to attend you must be an active WebKit contributor. If you are traveling internationally and require a formal invitation letter, please email me. The event includes a mix of proposed talks of around 40 minutes long and spontaneous lightning talks between 5-10 minutes long. We look forward to seeing you there! Regards, Jon Davis

1 0

node-jsc: A node.js port to the JavaScriptCore engine and iOS
by Koby Boyango 25 Sep '18

25 Sep '18

Hi, I'm Koby Boyango, a senior researcher and developer at mce, and I've created node-jsc <https://github.com/mceSystems/node-jsc>, an experimental port of node.js to the JavaScriptCore engine and iOS specifically. node-jsc's core component, "jscshim" (deps/jscshim) <https://github.com/mceSystems/node-jsc/tree/master/deps/jscshim>, implements (parts of) v8 API on top of JavaScriptCore. It contains a stripped down version of WebKit's source code (mainly JSC and WTF). To build WebKit, I'm using CMake to build the JSCOnly port, with JSC\WTF compiled as static libraries. For iOS I'm using my own build script <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/build…> with a custom toolchain file <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/tools/ios.t…>. The project also includes node-native-script <https://github.com/mceSystems/node-native-script>, NativeScript's iOS runtime refactored as node-jsc native module, allowing access to native iOS APIs directly from javascript. So first of all, I wanted to share this project with the WebKit developer community. It's my first time working with WebKit, and node-jsc has been a great opportunity to experiment with it. Second, as I needed to make some minor changes\additions, I'm using my own fork <https://github.com/mceSystems/webkit>. I would love to discuss some of the changes I've made, and offer some patches if you'll find them useful. "WebKit Fork and Compilation <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/webkit…>" describes WebKit's usage in node-jsc and the major changes\additions I've made in my fork (node-jsc's README <https://github.com/mceSystems/node-jsc/blob/master/README.md> and jschim's documentation <https://github.com/mceSystems/node-jsc/blob/master/deps/jscshim/docs/jscshi…> contains some more information). Besides that, I will appreciate any opinions\ideas\insights\suggestions :) Koby

5 9

CSSOM View behavior for scrollLeft, scrollTop, scrollWidth etc
by Frédéric Wang 24 Sep '18

24 Sep '18

Hi everybody, I'd like to announce that I started to implement the behavior for scrollLeft, scrollTop, scrollWidth, scrollHeight, scrollTo, scrollBy and scrollingElement [1] as specified by the CSSOM View specification [2]. To summarize, the main difference is which element to use in order to set or get the scroll properties of the viewport in standard (non-Quirks) mode: * The CSSOM View spec says it should be document.documentElement and most browsers implement it that way. * Chromium used to use document.body but this has recently been changed to follow the CSSOM View spec [3]. * WebKit still uses document.body and I'm proposing to change this behavior. Note that this is likely to break existing content. The change was attempted in WebKit in the past but broke some non-regression tests [4]. Chromium people also had some issues when trying to ship the change but things went well at the end [5]. For now I'm developing it under a CSSOMViewScrollingAPI developer flag. I was able to run the tests with that flag enabled, modulo a few test adjustments. [1] https://bugs.webkit.org/show_bug.cgi?id=5991 [2] https://drafts.csswg.org/cssom-view [3] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/X64Sg16RhT4 [4] https://bugs.webkit.org/show_bug.cgi?id=106133, https://bugs.webkit.org/show_bug.cgi?id=121876 [5] https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2iOz5-fgD8Y/… ; https://bugs.webkit.org/show_bug.cgi?id=5991#c20 -- Frédéric Wang - frederic-wang.fr

1 3

Proposal: Using LLInt Asm in major architectures even if JIT is disabled
by Yusuke Suzuki 21 Sep '18

21 Sep '18

Hi WebKittens! Recently, node-jsc is announced[1]. When I read the documents of that project, I found that they use LLInt ASM interpreter instead of CLoop in non-JIT environment. So I had one question in my mind: How fast the LLInt ASM interpreter when comparing to CLoop? I've set up two builds. One is CLoop build (-DENABLE_JIT=OFF) and another is JIT build JSC with `JSC_useJIT=false`. And I've ran kraken benchmarks with these two builds in x64 Linux machine. The results are the followings. Benchmark report for Kraken on sakura-trick. VMs tested: "baseline" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit/Release/bin/jsc "patched" at /home/yusukesuzuki/dev/WebKit/WebKitBuild/nojit-llint/Release/bin/jsc Collected 10 samples per benchmark/VM, with 10 VM invocations per benchmark. Emitted a call to gc() between sample measurements. Used 1 benchmark iteration per VM invocation for warm-up. Used the jsc-specific preciseTime() function to get microsecond-level timing. Reporting benchmark execution times with 95% confidence intervals in milliseconds. baseline patched ai-astar 3619.974+-57.095 ^ 2014.835+-59.016 ^ definitely 1.7967x faster audio-beat-detection 1762.085+-24.853 ^ 1030.902+-19.743 ^ definitely 1.7093x faster audio-dft 1822.426+-28.704 ^ 909.262+-16.640 ^ definitely 2.0043x faster audio-fft 1651.070+-9.994 ^ 865.203+-7.912 ^ definitely 1.9083x faster audio-oscillator 1853.697+-26.539 ^ 992.406+-12.811 ^ definitely 1.8679x faster imaging-darkroom 2118.737+-23.219 ^ 1303.729+-8.071 ^ definitely 1.6251x faster imaging-desaturate 3133.654+-28.545 ^ 1759.738+-18.182 ^ definitely 1.7808x faster imaging-gaussian-blur 16321.090+-154.893 ^ 7228.017+-58.508 ^ definitely 2.2580x faster json-parse-financial 57.256+-2.876 56.101+-4.265 might be 1.0206x faster json-stringify-tinderbox 38.470+-2.788 ? 38.771+-0.935 ? stanford-crypto-aes 851.341+-7.738 ^ 485.438+-13.904 ^ definitely 1.7538x faster stanford-crypto-ccm 556.133+-6.606 ^ 264.161+-3.970 ^ definitely 2.1053x faster stanford-crypto-pbkdf2 1945.718+-15.968 ^ 1075.013+-13.337 ^ definitely 1.8099x faster stanford-crypto-sha256-iterative 623.203+-7.604 ^ 349.782+-12.810 ^ definitely 1.7817x faster <arithmetic> 2596.775+-14.857 ^ 1312.383+-8.840 ^ definitely 1.9787x faster Surprisingly, LLInt ASM interpreter is significantly faster than CLoop. I expected it would be fast, but it would show around 10% performance win. But the reality is that it is 2x faster. It is too much number to me to consider enabling LLInt ASM interpreter for non-JIT build configuration. As a bonus, LLInt ASM interpreter offers sampling profiler support even in non-JIT environment. So my proposal is, how about enabling LLInt ASM interpreter in non-JIT configuration environment in major architectures (x64 and ARM64)? Best regards, Yusuke Suzuki [1]: https://lists.webkit.org/pipermail/webkit-dev/2018-September/030140.html

6 15

Does any platform set acceleratedCompositingForOverflowScrollEnabled?
by Simon Fraser 20 Sep '18

20 Sep '18

I'd like to remove the code related to acceleratedCompositingForOverflowScrollEnabled; it complicates RenderLayer z-order code, and is not sufficient for our desires of being able to accelerate all overflow-scrolls, not just those that can be made stacking context without affecting z-order. Simon

1 0

Offline Assembler build step always computes hashes even when nothing changes
by Darin Adler 17 Sep '18

17 Sep '18

I noticed that the “Offline Assembler” build step was taking between 5 and 30 seconds every time I build. Really stands out in incremental builds. I realized that this step does not do any dependency analysis. Every time, it builds a hash of the input to see if it needs to recompute the assembly. That’s probably not the best pattern; normally we like to use file modification dates to avoid doing any work when files haven’t changed. Is there someone who can help me fix this so we get faster incremental builds? — Darin

4 10

Copy WebKit Permalink for Sublime Text
by Daniel Bates 13 Sep '18

13 Sep '18

Hi all, If you use Sublime Text, now you can generate a trac.webkit.org hyperlink to a selected code line using the Copy WebKit Permalink plugin (as of < https://trac.webkit.org/changeset/235981/>). See < https://trac.webkit.org/browser/webkit/trunk/Tools/CopyPermalink/Sublime%20…> for more details. I tested the plugin on Mac with Sublime Text 3. The plugin should work on Windows and Linux. Fixes and improvements are welcome :) Happy hacking. Dan

1 0