Re: [webkit-dev] Trying to turn WebRTC's code on - MEDIA_STREAM flags

[Benjamin Poulain]

Quick answers inline:

On 7/21/14, 9:22 PM, Jacques-Olivier wrote:
Note: I already sent this email, but I didn't get any answer, nor can 
I see the thread in the archives. Therefore I think it was blocked, 
maybe because of the attachment that I remove this time.


I'm new on this mailing so I'll start by introducing myself:
My name Jacques-Olivier Haché (J-O), I'm working for Temasys 
Communication, and I'm entering the WebKit project to work on the 
implementation of WebRTC inside WebKit.
For those who would be following the WebRTC's news, I'm also the main 
developer of the WebRTC plugin released by Temasys.


Back to business:

I was able to download the project, build it and run it inside Safari. 
I did not try to run it in a different browser yet.


My configuration:

  * Macbook Air 2012
  * Mac OS X 10.9.4
  * Revision 171167
  * I'm on master
  * I suppose I'm using the regular Mac port as I didn't see where to
change from one port to another yet.
  * building for debug mode

I am now trying to enable the WebRTC related features to get a better 
understanding of the current state of this part of the project.
I have to say that I faced a lack of documentation on this area. I 
found the features list https://trac.webkit.org/wiki/FeatureFlags, a 
document about how to add a new feature 
https://trac.webkit.org/wiki/AddingFeatures but nothing about how to 
turn a feature on and off (there is actually a TODO about that in the 
second link).


I looked into the files that one needs to change to add a new feature 
and found two interesting files:


  * Source/WTF/wtf/FeatureDefines.h - where the WebRTC related
contants were set to 0 instead of 1
  * Source/cmake/WebKitFeatures.cmake - where the contants were set to OFF

I listed the following definitions that look related to WebRTC

  * ENABLE_MEDIA_CAPTURE
  * ENABLE_MEDIA_CONTROLS_SCRIPT
  * ENABLE_MEDIA_SOURCE
  * ENABLE_MEDIA_STATISTICS
  * ENABLE_MEDIA_STREAM
  * ENABLE_VIDEO
  * ENABLE_VIDEO_TRACK

I turned those definitions to 1 and ON in the respective file and 
tried to build.
The code in the header WebCore/Modules/mediastream/mediastream.h could 
not compile apparently because the observer did not have a destructor. 
I created one:

class Observer {
public:
virtual void didAddOrRemoveTrack() = 0;
  virtual ~Observer() {};
};

and tried to build again.

I now have a linking error when building WebCore with Xcode.

Ld 
/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/WebCore.framework/Versions/A/WebCore 
normal x86_64
cd 
/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/Source/WebCore

export MACOSX_DEPLOYMENT_TARGET=10.9
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ 
-arch x86_64 -dynamiclib -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk 
-L/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug 
-F/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug 
-filelist 
/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/WebCore.LinkFileList 
-Xlinker --no-demangle -exported_symbols_list 
/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/DerivedSources/WebCore/WebCore.LP64.exp 
-install_name 
/System/Library/Frameworks/WebKit.framework/Versions/A/Frameworks/WebCore.framework/Versions/A/WebCore 
-mmacosx-version-min=10.9 -lsqlite3 -lobjc -lANGLE -sub_library 
libobjc -umbrella WebKit -allowable_client WebCoreTestSupport 
-allowable_client WebKit2 -allowable_client WebKitLegacy -framework 
ApplicationServices -framework AudioUnit -framework Carbon -framework 
Cocoa -framework IOSurface -framework OpenGL -stdlib=libc++ 
-fobjc-link-runtime -framework Accelerate -framework AudioToolbox 
-framework CoreAudio -framework IOKit -framework JavaScriptCore 
-licucore -lobjc -lxml2 -lz -framework QuartzCore -framework Security 
-framework SystemConfiguration -single_module -compatibility_version 1 
-current_version 600.1 -Xlinker -dependency_info -Xlinker 
/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/WebCore.build/Debug/WebCore.build/Objects-normal/x86_64/WebCore_dependency_info.dat 
-o 
/Users/jacquesolivierhache/Workspace/Temasys/WebKitProject/WebKit/WebKitBuild/Debug/WebCore.framework/Versions/A/WebCore


Undefined symbols for architecture x86_64:
__ZN7WebCore11JSNavigator18webkitGetUserMediaEPN3JSC9ExecStateE, 
referenced from:
__ZN7WebCore46jsNavigatorPrototypeFunctionWebkitGetUserMediaEPN3JSC9ExecStateE 
in JSNavigator.o
__ZN7WebCore15RTCOfferOptions6createERKNS_10DictionaryERi, 
referenced from:

Re: [webkit-dev] Updating and Enabling the CSS Font Loading Spec

[Benjamin Poulain]

On 7/29/14, 11:38 AM, Dirk Schulze wrote:


On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote:


Hi All,

WebKit has support for an older version of the CSS Font Loading Specification 
[1], implemented back in 2013 [2]. I would like to bring this work in line with 
the current version of the specification, and enable it by default in the 
nightlies. The specification provides support for coordinating font loading: 
querying if fonts have loaded, requesting specific fonts to load, and providing 
notifications as fonts are loading.

Other browsers have a positive outlook on the feature. Chrome has already 
shipped it [3], and Mozilla is in the process of implementing it [4].


Do you want to implement it behind a compile time flag? IMO it is an important 
and great API. However, Cameron filed a lot of specifications but reports while 
implementing it [1]. So there might still be some issues to discover.

I strongly support the implementation though.


+1.

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

Re: [webkit-dev] Updating and Enabling the CSS Font Loading Spec

[Benjamin Poulain]

On 7/29/14, 3:33 PM, Bear Travis wrote:

On 7/29/14, 12:26 PM, Benjamin Poulain benja...@webkit.org wrote:


On 7/29/14, 11:38 AM, Dirk Schulze wrote:


On Jul 29, 2014, at 7:42 PM, Bear Travis betra...@adobe.com wrote:


Hi All,

WebKit has support for an older version of the CSS Font Loading
Specification [1], implemented back in 2013 [2]. I would like to bring
this work in line with the current version of the specification, and
enable it by default in the nightlies. The specification provides
support for coordinating font loading: querying if fonts have loaded,
requesting specific fonts to load, and providing notifications as fonts
are loading.

Other browsers have a positive outlook on the feature. Chrome has
already shipped it [3], and Mozilla is in the process of implementing
it [4].


Do you want to implement it behind a compile time flag? IMO it is an
important and great API. However, Cameron filed a lot of specifications
but reports while implementing it [1]. So there might still be some
issues to discover.

I strongly support the implementation though.


+1.



Yep, the implementation will be behind a compile time flag (the old
implementation already is). That said, I would like to have it enabled by
default in dev builds and the nightlies, both to get it into users’ hands
for testing and to keep the bots running the tests.


That's okay.

The flags are useful to disable unfinished features when shipping (until 
they are ready). You can enable a flag in nightly if the code is stable 
and has good test coverage, the feature does not need to be complete.


Successful examples are CSS Grid Layout and the Picture Element. Both 
are work in progress, they are enabled in Nightly, but none of that code 
is compiled into the released WebKit.


Benjamin

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

Re: [webkit-dev] Trying to turn WebRTC's code on - MEDIA_STREAM flags

[Benjamin Poulain]

 and links against them. 
Why are the script and Xcode not using the same files? It feels like 
a waste of time and space.


2) I had to do a number of modifications to the project to get here. 
At some point I will send pull requests, but I understand most of the 
people do not want to have media_stream enabled by default. Does that 
mean that for each pull request, I will have to remove my changes, 
send the pull request and do them again?What is the right way of 
handling this situation?


Regards,
J-O H

--
Haché Jacques-Olivier
RD Engineer at Temasys Communications Pte Ltd
Fr : 06 45 85 48 80
Sg : 9086 3673

On 23 Jul 2014, at 16:49, Alexandre GOUAILLARD agouaill...@gmail.com 
mailto:agouaill...@gmail.com wrote:



Hi benjamain, thanks for the answers,

Cmake is not a build system in itself, it is a cross platform build 
generator. i.e. you can generate a make file, an VS solution file 
and a Xcode file from CMakeLists.txt (cmake -G).


So you mean to say that the committed make files and Xcode files are 
not generated from CMake, is that correct? Also, do you have any 
insight what the people using cmake end up using for building (is it 
make/gcc/ld, make/clang/ld, other flavors of build/compiler/linker) ?


regards,

Alex.



On Wed, Jul 23, 2014 at 4:24 PM, Benjamin Poulain 
benja...@webkit.org mailto:benja...@webkit.org wrote:



On 7/22/14, 12:48 AM, Jacques-Olivier wrote:

HI Benjamin,

Thanks for you answer.

I just deleted the XCodeBuild folder and added a couple of
files in the project manually.
My computer is re-building the project, I will see how it goes.
A couple of extra questions:

1) After deleting the XCodeBuild folder, I cannot make my first
build using Xcode. I end up with a file not found on
#include llvm-c/Analysis.h
in JavaScriptCore/llvm/LLVMHeaders.h
I actually had the same issue on my first build. After a
successful build from build-webkit, I can build again using
Xcode (not clean and build).
Any lead regarding why?

No idea, I only use build-webkit and make for building.
A lot of people use Xcode so there must be a way to get it to work.


2) The Xcode projects is versioned on the repo. Is there anyway
to re-generate it automatically?
Having the Xcode project shared sounds very unsafe. What is
someone introduces a bug in it someday?

The Xcode project files are not generated, they are real project
files created by Xcode. WebKit contributors maintain 3 build
systems in parallel: Xcode, CMake, and VS.

Regards,
J-O H

--
Haché Jacques-Olivier
RD Engineer at Temasys Communications Pte Ltd
Fr : 06 45 85 48 80
Sg : 9086 3673

On 22 Jul 2014, at 15:16, Benjamin Poulain benja...@webkit.org
mailto:benja...@webkit.org wrote:


Quick answers inline:

On 7/21/14, 9:22 PM, Jacques-Olivier wrote:

Note: I already sent this email, but I didn't get any answer,
nor can I see the thread in the archives. Therefore I think
it was blocked, maybe because of the attachment that I remove
this time.

I'm new on this mailing so I'll start by introducing myself:
My name Jacques-Olivier Haché (J-O), I'm working for Temasys
Communication, and I'm entering the WebKit project to work on
the implementation of WebRTC inside WebKit.
For those who would be following the WebRTC's news, I'm also
the main developer of the WebRTC plugin released by Temasys.

Back to business:

I was able to download the project, build it and run it
inside Safari. I did not try to run it in a different browser
yet.

My configuration:

  * Macbook Air 2012
  * Mac OS X 10.9.4
  * Revision 171167
  * I'm on master
  * I suppose I'm using the regular Mac port as I didn't see
where to change from one port to another yet.
  * building for debug mode

I am now trying to enable the WebRTC related features to get
a better understanding of the current state of this part of
the project.
I have to say that I faced a lack of documentation on this
area. I found the features list
https://trac.webkit.org/wiki/FeatureFlags, a document about
how to add a new feature
https://trac.webkit.org/wiki/AddingFeatures but nothing
about how to turn a feature on and off (there is actually a
TODO about that in the second link).

I looked into the files that one needs to change to add a new
feature and found two interesting files:

  * Source/WTF/wtf/FeatureDefines.h - where the WebRTC
related contants were set to 0 instead of 1
  * Source/cmake/WebKitFeatures.cmake - where the contants
were set to OFF

I listed the following definitions that look related to WebRTC

  * ENABLE_MEDIA_CAPTURE
  * ENABLE_MEDIA_CONTROLS_SCRIPT
  * ENABLE_MEDIA_SOURCE
  * ENABLE_MEDIA_STATISTICS
  * ENABLE_MEDIA_STREAM
  * ENABLE_VIDEO

Re: [webkit-dev] CSS Grid Layout status review

[Benjamin Poulain]

Thank you for the update.

I would love to see CSS Grid in a stable state by the end of the year!

Do you know if Fuzzinator covers CSS Grid Layout?

Benjamin

On 8/1/14, 7:32 AM, Javier Fernandez wrote:

Hi all,

It's been a while since Igalia started contributing to the development
of the CSS Grid Layout spec in WebKit (enabled in the nightly builds
since May) and we'd like to report about the implementation status to
gather feedback from the community (comments, issues, questions, etc.).

CSS Grid Layout is a browser feature that allows to define responsive
and flexible 2D layouts using just CSS declarations. Visit
http://www.w3.org/TR/css-grid-1/ for more information about the standard.

First of all, the following meta-bug can be used to track the
implementation: http://webkit.org/b/60731

Besides a quite active bugfixing, these are the most important changes
that have been landed recently:

* Introduce compilation flag (http://webkit.org/b/129153) and remove
runtime feature http://webkit.org/b/132382 (thus CSS Grid Layout is
enabled in the nightly builds since May).

* Syntax implementation:
   - Adapting some properties to the last specification:
http://webkit.org/b/127987
  + grid-template-{columns, rows} and grid-template-areas
   - grid-template: Explicit Grid shorthand: http://webkit.org/b/128980
   - grid: Grid Definition Shorthand: http://webkit.org/b/132122

* Code refactoring:
   - Grid position resolution code moved to its own class:
http://webkit.org/b/131732

* Auto-Placement algorithm:
   - Add support for spanning items: http://webkit.org/b/110633

* Z-index:
   - Properly support z-index property on grid items:
http://webkit.org/b/103329

* Alignment and justification:
   - Implement justify-self css property:  http://webkit.org/b/134419

In addition, we're actively working on the following features:

* Alignment and justification:
   - Implement row-axis Alignment:  http://webkit.org/b/133222
   - Implement column-axis Alignment:  http://webkit.org/b/133224
   - Improve margin, border and padding support.

* Auto-placement algorithm:
   - Implement the new sparse and stack modes: http://webkit.org/b/103316

* Performance optimizations:
   - meta-bug to track future optimizations: http://webkit.org/b/125145
   - Dirty bit on grids: http://webkit.org/b/132332

We hope you find this report useful so people interested on this feature
could be aware of our progress and future work. Please, don't hesitate
to give us any kind of feedback; it's really appreciated.

Finally, stating that we're planning to continue working on the
implementation of this spec with the goal of asking before the end of
the year to be considered for shipping . Let's see how all this evolves
and we'll keep you informed.

Best regards.
___
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] Starting CSS Selectors Level 4

[Benjamin Poulain]

Hi WebKit,

I will soon start doing some work around the next spec of CSS Selectors:
http://dev.w3.org/csswg/selectors4/

The work will be behind a compile time flag
(https://bugs.webkit.org/show_bug.cgi?id=135535).

The spec is relatively minor and non-intrusive and the flag will be
enabled by default for all ports. I strongly advice disabling the flag
in stable branches.

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

[webkit-dev] Is anyone interested in maintaining INPUT_SPEECH?

[Benjamin Poulain]

Hi,

Is anyone interested in INPUT_SPEECH?

It looks like no port enable that feature. The code looks unmaintained. 
Everyone skip all the tests.


I will remove the code if nobody maintains it.

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

Re: [webkit-dev] Questions about ports

[Benjamin Poulain]

On 8/5/14, 11:48 PM, Jacques-Olivier wrote:
 I have a couple of questions regarding the different ports of WebKit:
 
 1) I suppose the port used by Safari Mac OS X is the Apple’s mac port
 (built by default)
 Is there a planing of when a version of WebKit is being publicly
 released in Safari Mac?

Each port can decide to branch WebKit trunk at any time to stabilize a
release version.

As far as I know, only WebKitGTK makes public announcements of their
release plans, bug targets, etc.

About Safari Mac, it is branched off WebKit trunk like any other port.
There is no public announcement of the release plans.

 2) Which port is being used by Safari iOS and how to build it?
 Is there a release planning?
 What is the flag to build this port?
 How to test it?

iOS Safari uses the iOS port (flag PLATFORM(IOS)). It shares a lot of
code with OS X, iOS and OS X are very similar platforms.

You do not need to build for it or run the tests, this is done by Apple.
For now, work in the WebKit project really focuses on OSX/GTK/EFL/Windows.

 3) Which port is being used to power third party applications on iOS?
 and how to build it?
 Is there a release planning?
 What is the flag to build this port?
 How to test it?

There is not a separate WebKit for Safari and third party apps, the same
WebKit is used for both.

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

Re: [webkit-dev] Trying to turn WebRTC's code on - MEDIA_STREAM flags

[Benjamin Poulain]

On 8/24/14, 8:37 AM, Alexandre GOUAILLARD wrote:
For clarification of the  goals and the scope, we intend to provide 
patches in webkit for webRTC. We would love to see webRTC support in 
iOS and we understand that having it in apple provided webkit 
(UIWebView) to comply to apple store rule 2.17. We understand we do 
not have complete control over the entire process, especially the 
eventual packaging and deployment, and the timelines, and that apple 
does not comment about this, but we thought implementing it in webkit 
was a necessary prerequisite in any case. For the rest we will have 
faith :-)


During a phone conversation with eric C, we've ben told that we should 
start by making it happen in the macOS X port as we would snot be able 
to build for iOS and because the differences were not so big between 
the iOS and the macOS ports.

Yep, that sounds like a good plan.
JO has been working on the Media Capture and Stream and webRTC APIs 
for almost a year, and developed an IE and Safari plugin that 
implements all of the APIs. He reads/speaks/write web IDL fluently 
now, and now all the subtleties of the constraints, streams, tracks, 
ect. I sit at the standard committees and help with everything that is 
not clear from the specs. Unfortunately, that does not help understand 
webkit intricacies and that's where we are today.


We reached out to Eric C, Thiago from nokia (NIX port), kirun from 
samsung, and started from there. I also speak regularly with adam Be. 
from ericson at the w3c meetings. I will jump in the project and add 
an additional senior staff, so we should be 2~3 FTE starting tuesday. 
Looking at philippe N works in WK2, it looks like you would be a 
reviewer of any patch we would submit, correct? (bug 
https://bugs.webkit.org/show_bug.cgi?id=123158)
I help from time to time but the right reviewers for work on multimedia 
are Brent Fulgham, Eric Carlson, Jer Noble and Philippe Normand.
With our target (iOS/MacOS X) should we target WK1 or WK2? We plan to 
finalize the webcore part first, but we need to target an app, and a 
port for testing. NIX does not seem to be an option anymore.
Usually, what goes into the WebKit layer is small and WK1 and WK2 are 
done simultaneously. For the initial prototype, you can focus on WebKit2 
and port the code to WebKit1 once you have something stable.


On OS X, WebKit2 is used by WKWebView and Safari, WebKit1 is used by the 
WebView API. On iOS, WebKit2 is used by WKWebView and Safari, WebKit1 is 
used by UIWebView.


For initial prototyping, you can generally focus on WebKit2 first.
There also seem to have been a discussion about the design (platform 
vs client) triggered by adam Be.. Anybody knows if there was a 
conclusion? (bug https://bugs.webkit.org/show_bug.cgi?id=67946) We 
would prefer putting a maximum of common code in webcore, as proposed 
by adam.
The architecture depends on the backend but also security considerations 
(especially with the access to hardware). You should ask Eric Carlson 
for input.
We are also contributing some tests to w3c (based on testharness.js, 
testing the bindings and IDL only) that we plan to use for testing. 
Dominique has recently committed the tests for steams and tracks using 
the latest spec (here 
https://github.com/w3c/web-platform-tests/tree/master/mediacapture-streams). 
Is there anything we should prepare in the layout tests for this as 
well? It looks like the media stream tests have been excluded from the 
tests for the time being.

That is a good start. You can import W3C tests into WebKit.

To qualify for a release, you would need to have a lot more testing than 
that. Given the scope of WebRTC, this will require improving the testing 
infrastructure of WebKit.
We are trying to have a working implementation by oct 15th, so we 
could send it for test around and get feedback in time for discussion 
during the W3C technical plenary and advisory committee meeting on 
oct. 27th, in San Jose, CA.
Honestly this seems a little short, WebRTC is big. Most non-trivial 
features take several months to get in good shape with proper testing 
and performance coverage.


It is probably possible to get a working prototype in 2 months, but this 
will require great review cycles.


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

[webkit-dev] WebKit2 EWS bots are sick

[Benjamin Poulain]

Hi,

It looks like the WebKit2 EWS bots are having a bad time. They keep
timing out on a bunch of tests. Can anyone restart them?

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

Re: [webkit-dev] Binary archives

[Benjamin Poulain]

On 9/15/14, 6:55 PM, Aravind Prakash wrote:

I am working on a research project involving webkit. Is there a repository from 
which I can retrieve past versions of precompiled 32 bit binaries for webkit? 
Thanks!


There: http://nightly.webkit.org/builds/trunk/mac/1

I think they are universal binaries with 64 and 32 bits. On x86 the 
32bits version are not very relevant, Safari has switched to 64bits a 
long long time ago. It may be better to focus on 64bits for your research.


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

[webkit-dev] Easy bugs for grab

[Benjamin Poulain]

Hello WebKittens,

From time to time, people ask for easy bugs to fix.

Looking at various specs, I see some new features and easy fixes 
available. For example:
-Unprefix cursor zoom-in and zoom-out (easy): 
http://www.w3.org/TR/css3-ui/#cursor

-Element.closest (easy): https://dom.spec.whatwg.org/#dom-element-closest
-Fix the visualization of :nth-child(An+B of selector) in the Inspector 
(probably easy).
-Unprefix your favorite CSS property (easy to hard depending on the 
property).

-etc, etc.

If you want to work on an amazing opensource project, here is an 
opportunity to get started. Shoot me an email if you want to implement 
one of the ideas above.


If nobody wants those, I'll just fix them :)

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

[webkit-dev] Unprefixing CSS Grid (was: Easy bugs for grab)

[Benjamin Poulain]

On 9/25/14, 12:34 AM, Sergio Villar Senin wrote:

On 23/09/14 10:28, Benjamin Poulain wrote:

-Unprefix your favorite CSS property (easy to hard depending on the
property).

What's the policy for unprefixing properties? I thought that they're
prefixed as long as the feature was experimental/under heavy
development. Has it changed? (I'm particularly interested in unprefixing
grid layout properties).

The policies have not changed.

From the data I have at the moment, I see a few reasons to keep the 
prefix on Grid Layout:

-It is a major feature.
-The spec is still a working draft, you are still helping the editor 
finishing the work.
-As far as I know, nobody has shipped the unprefixed version yet, there 
is no urgency for compatibility.

-What IE ships is not the current spec.
-I have not seen much feedback from web developers, which is 
frustrating/annoying :(


Once we are fully matching the latest spec and we have outstanding test 
coverage, we should unprefix the feature.


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

Re: [webkit-dev] SIMD support in JavaScript

[Benjamin Poulain]

Thanks for sharing your analysis on webkit-dev.

There has been a lot of criticisms about SIMD.js this year. It is great 
to read about solutions for vectorization without the problems of SIMD.js.


Benjamin

On 9/26/14, 3:16 PM, Nadav Rotem wrote:

Recently members of the JavaScript community at Intel and Mozilla
havesuggested http://www.2ality.com/2013/12/simd-js.htmladding SIMD
types to the JavaScript language. In this email would like to share my
thoughts about this proposal and to start a technical discussion about
SIMD.js support in Webkit. I BCCed some of the authors of the proposal
to allow them to participate in this discussion.

Modern processors feature SIMD (Single Instruction Multiple Data)
http://en.wikipedia.org/wiki/SIMD instructions, which perform the same
arithmetic operation on a vector of elements. SIMD instructions are used
to accelerate compute intensive code, like image processing algorithms,
because the same calculation is applied to every pixel in the image. A
single SIMD instruction can process 4 or 8 pixels at the same time.
Compilers try to make use of SIMD instructions in an optimization that
is called vectorization.

The SIMD.js API
http://wiki.ecmascript.org/doku.php?id=strawman:simd_number adds new
types, such as float32x4, and operators that map to vector instructions
on most processors. The idea behind the proposal is that manual use of
vector instructions, just like intrinsics in C, will allow developers to
accelerate common compute-intensive JavaScript applications. The idea of
using SIMD instructions to accelerate JavaScript code is compelling
because high performance applications in JavaScript are becoming very
popular.

Before I became involved with JavaScript through my work on the FTL
project
https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/, I
developed the LLVM vectorizer
http://llvm.org/docs/Vectorizers.html and worked on a vectorizing
compiler for a data-parallel programming language. Based on my
experience with vectorization, I believe that the current proposal to
include SIMD types in the JavaScript language is not the right approach
to utilize SIMD instructions. In this email I argue that vector types
should not be added to the JavaScript language.

Vector instruction sets are sparse, asymmetrical, and vary in size and
features from one generation to another. For example, some Intel
processors feature 512-bit wide vector instructions
https://software.intel.com/en-us/blogs/2013/avx-512-instructions. This
means that they can process 16 floating point numbers with one
instruction. However, today’s high-end ARM processors feature 128-bit
wide vector instructions
http://www.arm.com/products/processors/technologies/neon.php and can
only process 4 floating point elements. ARM processors support
byte-sized blend instructions but only recent Intel processors added
support for byte-sized blends. ARM processors support variable shifts
but only Intel processors with AVX2 support variable shifts. Different
generations of Intel processors support different instruction sets with
different features such as broadcasting from a local register, 16-bit
and 64-bit arithmetic, and varied shuffles. Modern processors even
feature predicated arithmetic and scatter/gather instructions that are
very difficult to model using target independent high-level intrinsics.
The designers of the high-level target independent API should decide if
they want to support the union of all vector instruction sets, or the
intersection. A subset of the vector instructions that represent the
intersection of all popular instruction sets is not useable for writing
non-trivial vector programs. And the superset of the vector instructions
will cause huge performance regressions on platforms that do not support
the used instructions.

Code that uses SIMD.js is not performance-portable. Modern vectorizing
compilers feature complex cost models and heuristics for deciding when
to vectorize, at which vector width, and how many loop iterations to
interleave. The cost models takes into account the features of the
vector instruction set, properties of the architecture such as the
number of vector registers, and properties of the current processor
generation. Making a poor selection decision on any of the vectorization
parameters can result in a major performance regression. Executing
vector intrinsics on processors that don’t support them is slower than
executing multiple scalar instructions because the compiler can’t always
generate efficient with the same semantics.
I don’t believe that it is possible to write non-trivial vector code
that will show performance gains on processors from different families.
Executing vector code with insufficient hardware support will cause
major performance regressions. One of the motivations for SIMD.js was to
allow Emscripten
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Emscripten to 
vectorize
C code and to emit JavaScript SIMD intrinsics. One problem 

Re: [webkit-dev] Adding support for gradient midpoint

[Benjamin Poulain]

On 9/29/14, 1:41 PM, Rik Cabanier wrote:

I'm planning on adding support for gradient midpoints.[1]
Since this is such a small addition, the feature will not be behind a
feature flag and will be enabled by default.

Let me know if you have questions or concerns with this approach

1: http://dev.w3.org/csswg/css-images-4/#color-interpolation-hint


Sounds okay to skip the feature flag for this.

As usual:
-Please make sure to add a functional implementation in a single patch.
-Please create outstanding test coverage.

What is the bug number for tracking this?

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

Re: [webkit-dev] Determining stable JavaScriptCore revision

[Benjamin Poulain]

safari-600.1.17 is in a good state, try getting JSC from there. Getting 
your release branch from the Safari branch seems like a good plan, it 
has been stabilizing for a while.


Benjamin

On 10/7/14, 7:26 PM, Gary Kratkin wrote:

Hello, I’m using WebKitGtk 2.4.4. It branched from trunk at r163300 on
Feb. 03, 2014. That may not have been a great moment for JavaScriptCore.
The jsCStack branch had recently been merged, and 2.4.4 has numerous JSC
crashes, especially in DFG. Disabling DFG is a reasonable short-term
solution for my use case, but it leaves one crash I’m having trouble
debugging. The release build crashes here:

#0
https://surfcrew.lighthouseapp.com/projects/120856/tickets/0 
0x7f1ffd385710
in JSC::JSCell::toBoolean(JSC::ExecState*) const () from
libjavascriptcoregtk-1.0.so.0
#1
https://surfcrew.lighthouseapp.com/projects/120856/tickets/1 
0x7f1ffd3ac7f0
in ?? () from libjavascriptcoregtk-1.0.so.0
#2
https://surfcrew.lighthouseapp.com/projects/120856/tickets/2 
0x7f1ffd3b6de3
in ?? () from libjavascriptcoregtk-1.0.so.0
#3
https://surfcrew.lighthouseapp.com/projects/120856/tickets/3 
0x7f1ff7a5d018
in ?? ()
#4
https://surfcrew.lighthouseapp.com/projects/120856/tickets/4 
0x7f1ff7a5d000
in ?? ()
#5
https://surfcrew.lighthouseapp.com/projects/120856/tickets/5 
0x7f1fb40af970
in ?? ()
#6
https://surfcrew.lighthouseapp.com/projects/120856/tickets/6 
0x7f1f7dec6a28
in ?? ()
#7
https://surfcrew.lighthouseapp.com/projects/120856/tickets/7 
0x7f1fac4b0ff8
in ?? ()
#8
https://surfcrew.lighthouseapp.com/projects/120856/tickets/8 
0x7fffe0e09000
in ?? ()
#9
https://surfcrew.lighthouseapp.com/projects/120856/tickets/9 
0x7fffe0e08da0
in ?? ()
#10
https://surfcrew.lighthouseapp.com/projects/120856/tickets/10 
0x7f1ffd36bada
in JSC::JITCode::execute(JSC::VM*, JSC::ProtoCallFrame*, JSC::Register*)
() from libjavascriptcoregtk-1.0.so.0
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The debug build asserts:

#0  0x7f434f2e692f in WTFCrash () at
../../Source/WTF/wtf/Assertions.cpp:333
#1  0x7f434eefe7ba in JSC::validateCellJSC::Structure*
(cell=0x3569a30) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
#2  0x7f434eefe39d in
JSC::WriteBarrierBaseJSC::Structure::operator- (this=0x7f42fd3bba90)
at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:123
#3  0x7f434ef1d4fc in JSC::JSCell::isString (this=0x7f42fd3bba90) at
../../Source/JavaScriptCore/runtime/JSCellInlines.h:124
#4  0x7f434ef290e3 in JSC::JSCell::toBoolean (this=0x7f42fd3bba90,
exec=0x7f42fd3bb878) at
../../Source/JavaScriptCore/runtime/JSCellInlines.h:188
#5  0x7f434ef290b5 in JSC::JSValue::toBoolean (this=0x7fff20ff7410,
exec=0x7f42fd3bb878) at ../../Source/JavaScriptCore/runtime/JSString.h:521
#6  0x7f434f085a84 in JSC::operationConvertJSValueToBoolean
(exec=0x7f42fd3bb878, encodedOp=0x7f42fd3bba90) at
../../Source/JavaScriptCore/jit/JITOperations.cpp:861
#7  0x7f43069fc99c in ?? ()
#8  0x7f43069218e0 in ?? ()
#9  0x0274c130 in ?? ()
#10 0x0301f740 in ?? ()
#11 0x031e5eb0 in ?? ()
#12 0x03295eb8 in ?? ()
#13 0x7f434a8eae08 in WebCore::JSDOMWindowBase::supportsProfiling
(object=0x7f43069218e0) at
../../Source/WebCore/bindings/js/JSDOMWindowBase.cpp:121
#14 0x7fff20ff74c0 in ?? ()
#15 0x7f434f06f74c in JSC::JITCode::execute
(this=0xf0458b4832eb, vm=0xb8077500f07d,
protoCallFrame=0x8348f0458948, topOfStack=0xdb6e8c7894860c0) at
../../Source/JavaScriptCore/jit/JITCode.cpp:48
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

My question isn’t how to debug this, though any insights would be
welcome. Instead I’m hoping to to roll JSC forward or backward to a more
stable revision somewhere near 02/2014  (in order to reduce problems
merging into WebKitGtk). It seems best to tie it to a contemporaneous
Safari release, perhaps from the safari-600.1 branch. I’m wondering if
that branch is considered always stable, and therefore safe to pull from
at an arbitrary revision. Alternatively, is there a way to discover the
revision for a given Safari release?

Thanks for any help,
Gary



___
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] Removing ENABLE guard for @supports (CSS3_CONDITIONAL_RULES)

[Benjamin Poulain]

+1, let's do it.

Benjamin

On 10/9/14, 1:47 PM, Dean Jackson wrote:

We've had support for @supports for a while. I'm planning to remove the 
compile-time guard for the feature.
(Note: Safari on iOS 8 and the public Yosemite builds currently have it turned 
off)

Does anyone disagree?

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

Dean

___
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] Downtime for Bugzilla upgrade on Thursday, October 16 from 8-10 AM PDT

[Benjamin Poulain]

It works great! Thanks for updating bugzilla, it is really neat.

Benjamin

On 10/16/14, 5:06 PM, David Kilzer wrote:

On Oct 16, 2014, at 4:04 PM, David Kilzer ddkil...@webkit.org
mailto:ddkil...@webkit.org wrote:


On Oct 16, 2014, at 2:38 PM, David Kilzer ddkil...@webkit.org
mailto:ddkil...@webkit.org wrote:


Two commit queue issues:

1. Patches are landing, but bugs aren't being closed.  Looks like
webkit-patch is failing because a textarea is disabled by default.


Bug 137794: commit-queue: fails to close bugs after successfully
landing patches
https://bugs.webkit.org/show_bug.cgi?id=137794
http://trac.webkit.org/changeset/174797

Tentatively fixed.  Still waiting for a cq+ patch to land with this
fix applied.  (There are some in flight that will not have this fix yet.)


2. Some commit queue patches fail to apply because 'OOPS!' is not
being removed from ChangeLog entries.


Bug 137795: commit-queue: fails to replace OO-PS! with reviewer name
https://bugs.webkit.org/show_bug.cgi?id=137795

Investigating this now.


Tentative fix (for the first issue found) checked in:
  http://trac.webkit.org/changeset/174800

If neither of these work, please let me know.  I'll check in later
tonight to see how things are going.

Dave



Dave



Investigating.

Dave
--
Sent from my iPhone 6

On Oct 16, 2014, at 10:58 AM, David Kilzer ddkil...@webkit.org
mailto:ddkil...@webkit.org wrote:


Update complete.

Please file bugs on bugs.webkit.org http://bugs.webkit.org/ and
reply to this thread with the bug.

Thanks!

Dave
--
Sent from my iPhone 6

On Oct 16, 2014, at 10:56 AM, David Kilzer ddkil...@webkit.org
mailto:ddkil...@webkit.org wrote:


Sorry, sent this from the wrong address before the update.


On Oct 16, 2014, at 3:33 AM, Osztrogonác Csaba
o...@inf.u-szeged.hu mailto:o...@inf.u-szeged.hu wrote:

Hi,

have you tried if the webkit-patch bugzilla tool (upload,
apply-attachment, apply-from-bug, ... ), the review tool,
the commit queue and EWS will work properly with the new
bugzilla version?


I did verify webkit-patch upload works.  We don't have an easy way
to test commit queue and EWS outside of the production environment.
 (That is something we want to improve going forward.)

If those are too broken to fix quickly, the plan is to roll back.


I think they are very fragile and highly rely on the generated
HTML forms. I prefer fixing these tools before updating to
breaking them and then trying to fix.


I wanted to upgrade as soon as possible to patch security issues
that were not back-ported to the version we were running.


Just out of curiosity, if we do an upgrade, why do we upgrade
to the old stable release (4.2.11), why not the latest stable
relase (4.4.6)? Is there a fundamental reason for it?


It was the quickest path to upgrade to a version where security
patches were available.

I had upgraded to 4.2.5 about a year ago, and had qualified over
90% of the website, so it was quickest to upgrade to 4.2.11 rather
than 4.4.6 (which could have introduced more compat issues with tools).


There are many good fixes in 4.4 release. If we can't upgrade
to 4.4 for some reason, it would be great to cherry-pick at
least the following changes:

It is now possible to add yourself to the CC list when uploading
an attachment and when editing an existing one. (note)
-- auto cc reviewer -
https://bugs.webkit.org/show_bug.cgi?id=124047 )

Changes to the CC list no longer causes midair collisions. (note)
-- It is very annoying if you are commenting a bug, and you
have to start it again if somebody else cc-ed him/herself.
Or if you clicked force, it would remove these new cc-s.


After we upgrade to 4.2.11, I will start work on 4.4.6 (plus a way
to test the EWS and commit queue with our test environment).


And one more question: Are you planning to check-in
the new bugzilla to Websites/bugs.webkit.org
http://bugs.webkit.org/ ?


Yes.  That will be part of the upgrade.  It's split into many
individual patches (and 3 merge patches); I didn't want to
squash-merge it in case it was easier to fix a future bug based on
these changes.

Dave



(note):
http://www.bugzilla.org/releases/4.4/release-notes.html#v44_feat

br,
Ossy

David Kilzer írta:

Hi,
We’re planning on upgrading Bugzilla (bugs.webkit.org
http://bugs.webkit.org/ http://bugs.webkit.org/) from 3.2.3
to 4.2.11 on Thursday, October 16 from 8-10 AM PDT
x-apple-data-detectors://1.
Sorry for the short notice.  I sent this message from the wrong
address, and didn't see he bounce message until now.
Please let me know if you have questions or concerns.  Thanks!
Dave



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

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

Re: [webkit-dev] CSS4 Media Queries

[Benjamin Poulain]

Nice :)

FYI, I am planning to do 
http://dev.w3.org/csswg/mediaqueries-4/#mf-interaction at some point 
next month. I may skip the flag for this one if everything goes well.


Benjamin

On 10/17/14, 4:55 PM, Dean Jackson wrote:

I'm going to start implementing a small part of CSS4 Media Queries. I'll put it 
behind a feature flag.

I'm starting with http://dev.w3.org/csswg/mediaqueries-4/#inverted because 
Apple wants to discuss it at the W3C TPAC meetings. We don't have any intention 
to ship the feature yet - it's just for experimentation and evaluation. I 
suggest other ports disable it if they plan on releasing from trunk.

Dean

___
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] Removing webkit prefix from CSS Shapes properties?

[Benjamin Poulain]

Any update on this?

There are a quite a few open bugs for CSS shapes. A lot of tests are 
skipped too: 
http://trac.webkit.org/browser/trunk/LayoutTests/TestExpectations#L137
CSS Shapes is really neat, it would be great to polish the 
implementation and unprefix.


Benjamin

On 10/27/14, 11:46 AM, Sam Weinig wrote:

Can you give us an overview of what other browsers have shipped CSS Shapes and 
how interoperable they are (e.g are they all passing a shared test suite)?

-Sam


On Oct 27, 2014, at 11:42 AM, Bem Jones-Bey bjone...@adobe.com wrote:

Hey all,

Chrome shipped CSS Shapes un-prefixed. The spec has been in CR for awhile now, 
with no changes in behavior. I keep on coming across content that uses CSS 
Shapes but doesn't use the prefixed version, so it doesn't work in Safari. Any 
objections to enabling un-prefixxed versions of CSS Shapes properties in WebKit?

- 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


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

Re: [webkit-dev] Streams API

[Benjamin Poulain]

It looks like nobody has raised any concern against Streams API. We even 
got positive feedback from Anne. :)


I have two concerns:
1) You have many patches waiting for review. I think you need to get 
better communication channels with reviewers in order to iterate over 
your patches faster. It is unfortunate but getting complex patches 
reviewed in WebKit requires poking reviewers directly. Since you work on 
the network stack, I suggest asking Alexey (ap) and Pratik (psolanki) on 
IRC, they can help with reviews or suggest other reviewers.
2) Streams is a large spec and it touches platform code. Please be 
careful with stability, make more tests than reasonable and #ifdef 
everything.


I suggest the flag name ENABLE_STREAMS_API, I find ENABLE_STREAMS a 
bit too generic.


If you open a meta bug, please send the bug number to the mailing list 
for reference.


Good luck :)
Benjamin

On 10/30/14, 4:02 PM, youenn fablet wrote:

Hi all,

I would like to add support for the streams API ([1], [2]), starting
with readable streams and their integration with XHR and loaders.
This work is expected to happen behind a flag.

Regards,
Youenn

[1] https://github.com/whatwg/streams
[2] http://www.w3.org/TR/streams-api/
___
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

[Benjamin Poulain]

On 11/2/14, 1:11 AM, Carlos Garcia Campos wrote:

El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:

On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
carlo...@webkit.org 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.

The GTK+ port supports the network process, but it's only used when
multiple secondary process model is used. Some applications prefer the
single shared secondary process model, and even some of the browser
users change the default process model of epiphany to single web process
because it requires fewer resources. So, we could either integrate the
cache with the web process loader, or use the network process
unconditionally for all process models. I think for many simple
applications a single web process is the most efficient model, though.
I believe it would be better to enable the network process for all 
process models. Maintaining multiple configurations for marginal gains 
is not sustainable, especially in the network stack.


You say a single Web Process is the most efficient model for some 
applications. What is the impact of always enabling the network process on:

-CPU load?
-Memory load?
-Overall performance?

Once we know where the problems are, we should work together at reducing 
the impact. I suspect we can get the network process below 5% overhead.


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

Re: [webkit-dev] Disk cache

[Benjamin Poulain]

On 11/3/14 11:12 AM, Carlos Garcia Campos wrote:

El lun, 03-11-2014 a las 00:22 -0800, Benjamin Poulain escribió:

On 11/2/14, 1:11 AM, Carlos Garcia Campos wrote:

El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:

On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
carlo...@webkit.org 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.

The GTK+ port supports the network process, but it's only used when
multiple secondary process model is used. Some applications prefer the
single shared secondary process model, and even some of the browser
users change the default process model of epiphany to single web process
because it requires fewer resources. So, we could either integrate the
cache with the web process loader, or use the network process
unconditionally for all process models. I think for many simple
applications a single web process is the most efficient model, though.

I believe it would be better to enable the network process for all
process models. Maintaining multiple configurations for marginal gains
is not sustainable, especially in the network stack.

You say a single Web Process is the most efficient model for some
applications. What is the impact of always enabling the network process on:
-CPU load?
-Memory load?
-Overall performance?


I haven't measured, I was thinking mainly on the overhead of the IPC
traffic required for the network resources.


On iOS, we managed to optimize this until IPC was no longer a major 
performance concern. Our IPC should definitely improve but it is not a 
high priority for performance.


You could argue that iOS runs on very unconventional CPUs but we also 
have some old ARMv7 that are close to conventional CPU and we managed 
reasonable overhead on those too.


In my humble opinion, we should just get hard data and solve the actual 
problems (which I suspect may be memory and not IPC).


Benjamin


Once we know where the problems are, we should work together at reducing
the impact. I suspect we can get the network process below 5% overhead.

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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Tagged assertions...

[Benjamin Poulain]

I don't think the problem is big enough to justify ASSERT_TAG.

Why not just add FIXME with some explanations and a link to the bug number?

Benjamin

On 11/6/14 12:34 PM, Said Abou-Hallawa wrote:

When the logical expression in the ASSERT is changed, you should do the 
following:

-   ASSERT_TAG(condition, “abcde”);
+  ASSERT(new_condition);

Then the pre-build tagging tool will generate a new tag for the new assertion:

+  ASSERT(new_condition, “fghij”);

So the assertions do not get messed up with Bugzailla.

The pre-build tool runs periodically only on Bot, maybe once every day and only 
on the touched files since it was last run.  Then it commits only the changed 
files because of tagging.  This should not add much to the build process.

Both ASSERT and ASSERT_TAG should be supported.  Since the developer should 
only add ASSERT and leave the tagging for the pre-build tagging tool.

___
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 ?

[Benjamin Poulain]

I agree with Filip and Antti.

The internal type of Vector is an orthogonal issue.

Keeping the old size_t API with the unsigned internal has caused a 
mess of types in the codebase and some confusion for contributors. We 
should fix the API and clean up our code.


There are cases were we can expect large vectors. It would be reasonable 
to have the storage type as a template argument of Vector. But in most 
cases we have a lot of very small vectors, not a small amount of large 
vectors.
We could also have a BigVector class that would be optimized for bigger 
allocations.


Benjamin

On 11/19/14 12:54 PM, Alexey Proskuryakov wrote:


This is not exactly about Vector, but if one
uses FileReader.prototype.readAsArrayBuffer() on a large file, I think
that it overflows ArrayBuffer. WebKit actually crashes when uploading
multi-gigabyte files to YouTube, Google Drive and other similar
services, although I haven't checked whether it's because of
ArrayBuffers, or because of a use of int/unsigned in another code path.

I think that we should use size_t everywhere except for perhaps a few
key places where memory impact is critical (and of course we need
explicit checks when casting down to an unsigned). Or perhaps the rule
can be even simpler, and unsigned may never be used for indices and
sizes, period.

- Alexey


19 нояб. 2014 г., в 12:32, Filip Pizlo fpi...@apple.com
mailto:fpi...@apple.com написал(а):


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 Vectorchar.  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 cdu...@apple.com
mailto:cdu...@apple.com 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 mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto: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] Do we need ENABLE(SQL_DATABASE) guards?

[Benjamin Poulain]

I hope we will be able to get rid of WebSQL at some point. The guard 
would be useful for cleanup.


But given how popular WebSQL is, I don't see us doing that anytime soon. :(

I am in favor of removing the flag.

Benjamin

On 12/5/14 6:38 AM, Osztrogonác Csaba wrote:

Hi all,

it seems ENABLE(SQL_DATABASE) is enabled on all ports,
but there are still ifdef guards for it in 300+ files.

Is there anybody shipping WebKit with disabled SQL_DATABASE?
If no, I'd propopse removing these guards.

br,
Ossy

___
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] Announcing WebKit for Wayland

[Benjamin Poulain]

Hi Žan,

Thanks for announcing this project here.

Can you explain a bit why you decided to use the UIProcess directly 
inside the compositor?


I am a bit concerned about the security of this model because the 
UIProcess becomes an attack vector for the compositor. Sharing the 
memory space with the compositor would prevent aggressive sandboxing.


Great Wayland support seems like an important target for WebKit on 
Linux. Do you know what are the plans for GTK and EFL?


Benjamin


On 12/9/14 7:44 AM, Žan Doberšek wrote:

Hi,

now with proper formatting, Igalia is happy to announce the Wayland port
of WebKit.

This port avoids using traditional GUI toolkits in favor of directly
operating with the Wayland display protocol. Leveraging the WebKit2
multi-process architecture, the UIProcess is implemented as a shared
library and loaded by the Wayland compositor, enabling the WebProcess to
act as a direct client of the compositor while still being controlled by
the UIProcess.

EGL, the Wayland EGL platform, and OpenGL ES are used for
hardware-accelerated compositing of the rendered Web content. GLib,
Libsoup and Cairo are used under the hood.

The port serves as a good base for building systems and environments
that are mostly or completely relying on the Web platform technologies
for building the desired interface.

Overall the port is still in its early days, with some basic
functionality (e.g. functional keyboard and mouse input support) and
many other Web platform features still not supported. But with Wayland
EGL support constantly growing in graphics drivers for different GPUs,
it can already be tested on devices like the Raspberry Pi or the Jetson
TK1 development board.

In terms of supported Wayland compositors, for the moment we only
support Weston (the reference Wayland compositor implementation), which
is also used for development purposes. It's also used for running the
layout tests by again pushing WebKitTestRunner functionality into a
shared library, though all that is still in very early stages.

The code is available on GitHub. There are also short instructions for
building the dependencies and the port, and how to run it.
https://github.com/WebKitForWayland/webkit

There's also additional repositories there (for Cairo, Weston),
containing changes that haven't yet been pushed upstream. In the
following days we'll also be providing Buildroot configurations that can
be used for cross-compiling the whole software stack for the supported
hardware.

We look forward to continuing evolving this work, enabling further
features and improving performance on the software side and adding
support for additional devices. As with all open-source projects,
contributions are welcome.

Regards,
Zan Dobersek


On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com
mailto:zandober...@gmail.com wrote:

Hi,
Igalia is happy to announce the Wayland port of WebKit.
This port avoids using traditional GUI toolkits in favor of directly
operating with the Wayland display protocol. Leveraging the WebKit2
multi-process architecture, the UIProcess is implemented as a shared
library and loaded by the Wayland compositor, enabling the
WebProcess to act as a direct client of the compositor while still
being controlled by the UIProcess.
EGL, the Wayland EGL platform, and OpenGL ES are used for
hardware-accelerated compositing of the rendered Web content. GLib,
Libsoup and Cairo are used under the hood.
The port serves as a good base for building systems and environments
that are mostly or completely relying on the Web platform
technologies for building the desired interface.
Overall the port is still in its early days, with some basic
functionality (e.g. functional keyboard and mouse input support) and
many other Web platform features still not supported. But with
Wayland EGL support constantly growing in graphics drivers for
different GPUs, it can already be tested on devices like the
Raspberry Pi or the Jetson TK1 development board.
In terms of supported Wayland compositors, for the moment we only
support Weston (the reference Wayland compositor implementation),
which is also used for development purposes. It's also used for
running the layout tests by again pushing WebKitTestRunner
functionality into a shared library, though all that is still in
very early stages.
The code is available on GitHub. There are also short instructions
for building the dependencies and the port, and how to run
it.https://github.com/WebKitForWayland/webkit
There's also additional repositories there (for Cairo, Weston),
containing changes that haven't yet been pushed upstream. In the
following days we'll also be providing Buildroot configurations that
can be used for cross-compiling the whole software stack for the
supported hardware.
We look forward to continuing evolving this work, enabling further
  

Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

[Benjamin Poulain]

That's interesting information.

Did you add usage counters before the removal? Any idea how much usage 
there is?


On 12/15/14 4:28 PM, TAMURA, Kent wrote:

FYI.  We removed Web SQL support for Workers in Blink, and already
shipped the removal in Google Chrome stable channel.  The removal made
the code much simpler because we don't need synchronous-version classes.


On Sat, Dec 6, 2014 at 9:13 AM, Benjamin Poulain benja...@webkit.org
mailto:benja...@webkit.org wrote:

I hope we will be able to get rid of WebSQL at some point. The guard
would be useful for cleanup.

But given how popular WebSQL is, I don't see us doing that anytime
soon. :(

I am in favor of removing the flag.

Benjamin


On 12/5/14 6:38 AM, Osztrogonác Csaba wrote:

Hi all,

it seems ENABLE(SQL_DATABASE) is enabled on all ports,
but there are still ifdef guards for it in 300+ files.

Is there anybody shipping WebKit with disabled SQL_DATABASE?
If no, I'd propopse removing these guards.

br,
Ossy

_
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/__mailman/listinfo/webkit-dev
https://lists.webkit.org/mailman/listinfo/webkit-dev


_
webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/__mailman/listinfo/webkit-dev
https://lists.webkit.org/mailman/listinfo/webkit-dev



--
TAMURA Kent
Software Engineer, Google




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

Re: [webkit-dev] Do we need ENABLE(SQL_DATABASE) guards?

[Benjamin Poulain]

Nice. Thanks for the links.

We should do the same, at least add a #ifdef for the worker support. It 
is a step in the right direction.


On 12/15/14 4:54 PM, TAMURA, Kent wrote:

Yes.

openDatabase on WorkerGlobalScope:
https://www.chromestatus.com/metrics/feature/timeline/popularity/313

openDatabaseSync on WorkerGlobalScope:
https://www.chromestatus.com/metrics/feature/timeline/popularity/314

openDatabase on Window: (We can't remove this yet.)
https://www.chromestatus.com/metrics/feature/timeline/popularity/10


These graph contains a period in which Google Chrome still had Web SQL
for Workers.  However the usage was almost zero.


On Tue, Dec 16, 2014 at 9:43 AM, Benjamin Poulain benja...@webkit.org
mailto:benja...@webkit.org wrote:

That's interesting information.

Did you add usage counters before the removal? Any idea how much
usage there is?

On 12/15/14 4:28 PM, TAMURA, Kent wrote:

FYI.  We removed Web SQL support for Workers in Blink, and already
shipped the removal in Google Chrome stable channel.  The
removal made
the code much simpler because we don't need synchronous-version
classes.


On Sat, Dec 6, 2014 at 9:13 AM, Benjamin Poulain
benja...@webkit.org mailto:benja...@webkit.org
mailto:benja...@webkit.org mailto:benja...@webkit.org wrote:

 I hope we will be able to get rid of WebSQL at some point.
The guard
 would be useful for cleanup.

 But given how popular WebSQL is, I don't see us doing that
anytime
 soon. :(

 I am in favor of removing the flag.

 Benjamin


 On 12/5/14 6:38 AM, Osztrogonác Csaba wrote:

 Hi all,

 it seems ENABLE(SQL_DATABASE) is enabled on all ports,
 but there are still ifdef guards for it in 300+ files.

 Is there anybody shipping WebKit with disabled
SQL_DATABASE?
 If no, I'd propopse removing these guards.

 br,
 Ossy

 ___
 webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
mailto:webkit-dev@lists.__webkit.org
mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
https://lists.webkit.org/__mailman/listinfo/webkit-dev
 https://lists.webkit.org/__mailman/listinfo/webkit-dev
https://lists.webkit.org/mailman/listinfo/webkit-dev


 ___
 webkit-dev mailing list
webkit-dev@lists.webkit.org mailto:webkit-dev@lists.webkit.org
mailto:webkit-dev@lists.__webkit.org
mailto:webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
https://lists.webkit.org/__mailman/listinfo/webkit-dev
 https://lists.webkit.org/__mailman/listinfo/webkit-dev
https://lists.webkit.org/mailman/listinfo/webkit-dev



--
TAMURA Kent
Software Engineer, Google





--
TAMURA Kent
Software Engineer, Google




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

Re: [webkit-dev] Problem with a crash using JSC code

[Benjamin Poulain]

There is not formal size limit for any patch, some changes are 
inherently big.


Experience shows that big patch tends to have more hidden bugs and 
poorer code coverage. It is better to go forward by little step while 
having huge test coverage at every step.


https://bugs.webkit.org/attachment.cgi?id=245350action=review looks 
hard to split.


Maybe do a first patch with an empty shell + the bindings. You can test 
passing all kind of valid and invalid values to the API; test the 
property of the object and every function/properties, test creating 
thousands of ReadableStream objects, etc.


Then a follow up patch implementing the ReadableStream and have an other 
set of test checking the behavior?



On 1/26/15 3:22 AM, youenn fablet wrote:

The latest patch at https://bugs.webkit.org/show_bug.cgi?id=138967
resolves the crash (some JSC::Strong were missing).

I fear that the patch may be a bit too big to get a thorough review though.
The patch could be split into meaningful but not testable sub-patches
(module stuff, JS integration stuff and then tests and more tests).
Would that make sense?
What is a reasonable patch size limit?

Any advice well appreciated.

Thanks,
Youenn


2015-01-21 19:40 GMT+01:00 Xabier Rodríguez Calvar calva...@igalia.com:

 Hi!

I am now implementing with Youenn the Streams API standard [1] in
WebKit. You can find the first patch at [2] (it's r? now). While we get
that patch reviewed and landed we are adding more tests and working out
the problems. One of them is one crash that I cannot hunt, with the
following backtrace:

http://fpaste.org/172619/60635142/

You can find the code under the lines to make it easier. What is going
on is:

  1. There's a call to the ReadableStream object, delegated to the
 JSReadableStreamSource as a result of the object creation.
  2. There's a call to the JSReadableStream::read method, delegating
 in the ReadableStream that ends up pulling again and that second
 call crashes.

It is probably something stupid I am not taking into account, but I have
already been fighting this for a couple of days and cannot make it work
properly.

Any help? Thanks a lot in advance!

[1] https://streams.spec.whatwg.org/
[2] https://bugs.webkit.org/show_bug.cgi?id=138967


___
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] Running W3C tests using wptserve

[Benjamin Poulain]

Hi Youenn,

Thanks for working on this.

How do we run the imported tests? Do we just use run-webkit-test passing 
'imported/w3c'?
Is there a way to get the percentage of W3C tests that succeed? It would 
be useful to have a report per directory so that we improve it over time 
until we reach 100%.


Benjamin

On 1/31/15 11:57 AM, youenn fablet wrote:

Hi all,

W3C wptserve server is now used to serve all tests under
LayoutTests/imported/w3c/web-platform-tests.

Currently, only two tests are run within that folder:
- web-platform-tests/domparsing/DOMParser-parseFromString-html.html
- web-platform-tests/domparsing/insert-adjacent.html

Should there be any issus with those tests, the problem may be related
to running wptserve.
The wptserve server log is dumped in the the layout-test-results folder.
Please let me know if you see any such issue, particularly on WebKit bots.

Next planned steps in that area are:
1. Update Tools/Scripts/import-w3c-tests according this new set-up
2. Migrate already imported W3C WPT tests within
LayoutTests/imported/w3c/web-platform-tests
3. Further improve the tools to make import of new tests and re-import
existing tests as easy as possible

Any suggestion welcome.

Thanks,
youenn
___
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] WebRTC in WebKit

[Benjamin Poulain]

Getting WebRTC working on WebKitGTK sounds awesome.

I am a little concerned with the use of an abstraction layer as a 
backend. I am afraid this could lead to weird abstractions.


Typically in WebKit we try to have baseline code in C++ that handles 
everything that can be shared between ports, and platform abstractions 
for everything port and/or platform specific.


Using OpenWebRTC, there would be no abstractions and WebCore would just 
be a bridge between JavaScript and OpenWebRTC. Is that correct?


Could you explain a bit why you chose to use an abstraction layer at the 
WebRTC level instead of interfacing directly with GStreamer at the 
platform abstraction level?


Benjamin


On 1/28/15 2:28 AM, Adam Bergkvist wrote:

Hi

Back in 2011-2012 there was some work done to implement WebRTC in WebKit
by Google and Ericsson [1]. At the time, it was only the chromium port
that had a WebRTC backend implemented (webrtc.org) and a fully testable
implementation. As of late 2014, there is an alternative WebRTC
implementation out there; OpenWebRTC [2] is an open source WebRTC
framework based on GStreamer.

This is an announcement that we are a group of people/companies that
intend to continue the work on WebRTC in WebKit.

What we would like to do is to:
* Get the WebCore interfaces up to date. Quite a lot has changed in the
WebRTC API since the code landed in WebCore. For example, the
MediaStreamTrack has taken over most of the responsibilities previously
owned by MediaStream.

* Use OpenWebRTC as a WebRTC backend on the GTK+ port. Our approach
would be to use a stable platform interface on a lower level than the
W3C API (MediaStream API and RTCPeerConnecion) and implement the API
related details in WebCore. This would allow us to let API related
objects only exist in WebCore and not having to mirror them across layers.

* Evaluate the feasibility of multiple back-end support (e.g. webrtc.org
 OpenWebRTC).

This effort will involve quite a few people, including Adam Bergkvist
(Ericsson), Alex Gouaillard (Temasys), Philippe Normand (Igalia) and
Sebastian Dröge (Centricular).

Feedback and/or help is always appreciated.

BR
Adam, Alex, Philippe and Sebastian

[1] https://lists.webkit.org/pipermail/webkit-dev/2011-November/018445.html
[2] https://github.com/EricssonResearch/openwebrtc
___
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] Pattern for singleton classes instance getters

[Benjamin Poulain]

IMHO, scoping the function by its class is cleaner.
http://trac.webkit.org/changeset/179247 looks like an improvement to me.

Benjamin

On 1/28/15 11:30 AM, Chris Dumez wrote:

Hi,

I noticed that we are currently not very consistent in WebKit in the 
way we implement singleton classes instance getters.
- Some classes use free functions (like MemoryCache, and PageCache 
until I updated it yesterday). e.g. memoryCache().xxx()
- Some classes are using static functions in the class 
(e.g. DatabaseProcess::shared(), PluginProcess::shared()).


As I said, I landed a patch yesterday so that the global page cache is 
now accessed via PageCache::shared() because I thought this was the 
currently preferred pattern (given it seems very common in WebKit2 code).
However, I thought I would email webkit-dev to make sure this is 
actually the case and make sure we agree on a given pattern (one way 
or another) for current and future code. We could then maybe document this

as part of our coding style.

Any feedback on this matter?

Kr,
--
Chris Dumez - Apple Inc.
Cupertino, CA






___
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] FTP directory support

[Benjamin Poulain]

Isn't it used by iOS? I remember fixing a bug for it last year.

Benjamin

On 1/4/15, 6:22 PM, Darin Adler wrote:

Hi folks.

Is anyone using the FTP directory support in WebKit? This is implemented in 
html/FTPDirectoryDocument.cpp and Sam Weinig and I think it’s currently not 
actively used by any port, but I’d like to understand if that’s right or not.

If you are taking advantage of this, please let us know by responding here.

Otherwise, I’d like to delete this code some time soon.

— 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] Removing support for Shared Workers

[Benjamin Poulain]

Let's do it!

On 1/5/15 2:52 PM, Sam Weinig wrote:

Hello,

I’d like to remove support for Shared Workers.

We have not shipped support for Shared Workers in Safari for two releases and 
have not seen any significant complaints.  The code as it currently stands is 
not a good fit for the WebKit2 architecture, so, if we ever decided Shared 
Workers were important, we would probably start over.

Does anyone object?

- 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] Removing Web SQL Database support in workers

[Benjamin Poulain]

I support this :)

This was discussed a bit last month: 
https://lists.webkit.org/pipermail/webkit-dev/2014-December/027106.html


Benjamin

On 1/5/15 11:42 AM, Anders Carlsson wrote:

Hello,

I’d like to remove support for Web SQL databases in workers.

The whole specification has been deprecated (see
http://www.w3.org/TR/webdatabase/) and ditching the worker related
database code will allow us to simplify the code a lot.

FWIW, it looks like support has already been removed in Blink (and they
deprecated the feature in July 2014 - see
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/2SWnbXAL7Wg).

Unless anyone objects I’m going to start removing this next week.

- 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] WebCore/platform standalone library

[Benjamin Poulain]

On 3/19/15 2:49 PM, Maciej Stachowiak wrote:



On Mar 19, 2015, at 1:47 PM, Benjamin Poulain benja...@webkit.org wrote:

On 3/18/15 9:43 PM, Myles C. Maxfield wrote:

Hello, all,

I’d like to announce that I intend to create a standalone static library from the 
current contents of WebCore/platform over the coming months. This will involve 
creating a “Platform top-level directory and moving source files into it, one 
by one.

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?


That's an awesome project. That's gonna be a lot of work.

How do you plan to do the interface between WebCore and Platform?

Between WebCore and WebKit, we use interfaces with pure virtual functions that 
are implemented by the clients.
Between WebCore and the platform, we have headers and each port has its own 
implementation of that interface.

Do you plan to move Platform behind a public interface or keep the current 
model?


I don’t think we need a model like the WebCore/WebKit interface. WTF is 
essentially like the proposed Platform library already, and it just exposes 
normal C++ headers and implementation files. I think the main benefit here is 
cleaning up the layering, as opposed to adding more abstraction. In fact, you 
could sort of think of WTF and Platform as logically the same library, with WTF 
being only the parts needed by JavaScriptCore, plus things that are logically 
at the same level (so basically non-GUI and no networking code).

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.


Have you seen the clean interface of ResourceHandle? :)

The client layers tend to get cleaner over time while the lower layers 
tends to become messier.

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

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

[Benjamin Poulain]

On 3/18/15 9:43 PM, Myles C. Maxfield wrote:

Hello, all,

I’d like to announce that I intend to create a standalone static library from the 
current contents of WebCore/platform over the coming months. This will involve 
creating a “Platform top-level directory and moving source files into it, one 
by one.

There are a few reasons for this:

1. Enforcing the layering between Platform and WebCore. Moving Platform into 
its own target/directory can guarantee that nothing inside it knows about 
anything in WebCore.
2. Being able to test code in the Platform directory with TestWebKitAPI 
(without exporting Platform symbols from the WebCore library)
3. Managing conceptual complexity.

Does anyone have any thoughts or feedback?


That's an awesome project. That's gonna be a lot of work.

How do you plan to do the interface between WebCore and Platform?

Between WebCore and WebKit, we use interfaces with pure virtual 
functions that are implemented by the clients.
Between WebCore and the platform, we have headers and each port has its 
own implementation of that interface.


Do you plan to move Platform behind a public interface or keep the 
current model?




Thanks,
Myles
___
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] NEON_INTRINSICS

[Benjamin Poulain]

This is quite different from legacy features we remove all the time. 
This simple valuable code that happen to be untested because of the lack 
of ARMv7 infrastructure on the public bots.


Regarding maintenance, I'd be happy to fix bugs in that code.

Benjamin

On 3/9/15 11:34 AM, Maciej Stachowiak wrote:

Requiring a perf bot to be set up before removing unmaintained code
seems like a really high bar. What would it take to do a one-shot
test of whether NEON_INTRINSICS is a perf benefit? Would it show up
on PLT or on JS perf benchmarks if you compiled with it? If it’s not
a speedup in its existing form, then it’s probably not worth keeping
around. If it is, then that might be incentive for someone to get it
production-ready and on by default for relevant platforms.

Regards, Maciej


On Mar 8, 2015, at 6:56 PM, Benjamin Poulain benja...@webkit.org
wrote:

That code looks straightforward, the maintenance cost is likely
low. We just really need a test bot to run that code.

I suggest we wait until we have a ARMv7 perf bot and re-evaluate
NEON_INTRINSICS.

On 05/03/2015 22:27, Carlos Garcia Campos wrote:

Yesterday a patch was submitted to fix the build with
NEON_INTRINSICS, and Ossy pointed out that the build has been
broken since r170433, and nobody has noticed it until now. So
that makes me wonder if anybody is actually using that and if it
even works, because otherwise we should probably remove the
NEON_INTRINSICS code.

So, is there anybody actually using that (I guess patched
downstream)?


___ 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] NEON_INTRINSICS

[Benjamin Poulain]

That code looks straightforward, the maintenance cost is likely low. We
just really need a test bot to run that code.

I suggest we wait until we have a ARMv7 perf bot and re-evaluate
NEON_INTRINSICS.

On 05/03/2015 22:27, Carlos Garcia Campos wrote:
 Yesterday a patch was submitted to fix the build with NEON_INTRINSICS,
 and Ossy pointed out that the build has been broken since r170433, and
 nobody has noticed it until now. So that makes me wonder if anybody is
 actually using that and if it even works, because otherwise we should
 probably remove the NEON_INTRINSICS code. 

 So, is there anybody actually using that (I guess patched downstream)?


 ___
 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] Request for feedback: Status page for WebKit

[Benjamin Poulain]

Hi ,

For those who were not at that session at the contributor meeting: some
web developers have asked for a better way to follow what is being done
in WebKit without having to follow every WebKit engineers on Twitter.

On our end, having more visibility on what is enabled in Nightly could
help getting more feedback and bug reports.

Google maintains a status page for the features enabled in chrome
(https://www.chromestatus.com/features) and it seems to be useful. We
could try doing something similar for WebKit.

Since Webkit's engineering is distributed with all the ports and various
prototypes, the idea would be to let every contributor maintain the
status page. We would have JSON files in the tree describing features
and their states, and webkit.org would pull that information from the
repository to publish that in a nicer way.

My current plan is to have 2 files, named features.json, with the
information about our features. The files would be in
Source/JavaScriptCore/features.json and Source/WebCore/features.json.

From the feedback at the contributor meeting, I drafted the following
format for the files: http://trac.webkit.org/wiki/Feature%20Status
I am still not sure how to best format the list of releases where a
feature has shipped for the first time. In the draft, I used a list of
strings with a custom format.

Please have a look. Send me your feedback. If everyone still think it is
a good idea in a week, I'll start working toward putting something like
that in the tree.

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

Re: [webkit-dev] Single-page apps without Javascript W3C proposal interest?

[Benjamin Poulain]

IMHO JavaScript is a better solution for this. Instead of baking a 
custom solution into the engine that solve a single use case, we have a 
fast lightweight language that let you solve any use cases you have.


Did any vendor actually respond positively to the whatwg proposal?

Benjamin

On 3/27/15 12:49 AM, Bobby Mozumder wrote:

Hi,

I submitted a proposal to W3C  WHATWG to enhance HTML to support
single-page apps without using Javascript:

https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/0071.html

And here’s a document on Github that’s clearer than that email:

https://github.com/mozumder/html6

This proposal somehow went viral:

http://www.infoworld.com/article/2901436/internet/faster-web-page-loading-without-javascript.html
  (includes an analyst quote)
http://sdtimes.com/w3c-member-proposes-single-page-apps-without-javascript-in-html6/
  (been a top trending story for the last week)
http://blog.smartbear.com/web-development/html6-apis-as-natural-friends/
http://jaxenter.com/html6-proposal-for-single-page-apps-without-javascript-causes-scandal-115919.html

and lots more, in different languages around the world. If you search
“html6” on Twitter, you’ll see. There are hundreds or thousands of
shares, upvotes, comments, etc.

So it looks like a lot of people want something like this to happen.  I
believe it represents web developers’ dissatisfaction in having to use
these Javascript frameworks to do something basic that should have been
a part of the HTML spec, that is, dynamic loading of content.  I put
this proposal out there as a result of my own frustrations with these
frameworks being constantly redesigned.

I’m checking if there’s any interest from the Webkit team on this?  I’m
trying to plan the next steps and probably wouldn’t proceed without at
least some sort of interest or guidance from the browser vendors.
  (maybe this is technically impossible, etc..) Next steps would
probably include working on a full spec, and possibly implementation.  I
have built WebKit nightly before, but haven’t modified any of its code,
and I suspect something like this would be way beyond me time-wise to
fully implement myself, but if there’s interest, I could possibly figure
out some options.

Anyways do let me know of any interest.

-bobby
---
Bobby Mozumder
/Editor-in-Chief/
FutureClaw Magazine
mozum...@futureclaw.com mailto:mozum...@futureclaw.com
+1-240-745-5287
www.futureclaw.com http://www.futureclaw.com/
twitter.com/futureclaw https://www.twitter.com/futureclaw
www.linkedin.com/in/mozumder http://www.linkedin.com/in/mozumder



___
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 TextureMapperImageBuffer

[Benjamin Poulain]

It seems undesirable to use a completely different stack for testing and 
for shipping.


Wouldn't it be possible to use Mesa on the EFL bots?

On 4/23/15 12:10 PM, Martin Robinson wrote:

A slight update on this issue. It's already been attempted here:
https://bugs.webkit.org/show_bug.cgi?id=143561

The issue is that WebKitEFL is using the TextureMapperImageBuffer to
run tests on their bots, because the EFL bots don't support OpenGL
tests. My suggestion is that we disable accelerated compositing
completely for WebKitEFL (if possible) and skip those tests. Once the
bots have the ability to run tests that use OpenGL, we can re-enable
that code path for WebKitEFL.

--Martin

On Thu, Apr 23, 2015 at 11:12 AM, Martin Robinson mrobin...@webkit.org wrote:

Background: There currently exists a fallback TextureMapper
implementation that does not use OpenGL to composite and project
layers, but instead relies on 2D rasterization. This does not work
correctly for Cairo, since Cairo only supports affine transformations.
I believe this path is only used by GTK+ (and perhaps WinCairo) now.

Proposal: I would like to remove TextureMapperImageBuffer and make
TextureMapperGL the only implementation of TextureMapper. Not only
will this simplify the code, it will remove a build flag
(TEXTURE_MAPPER_GL). The current path isn't (or really shouldn't) be
enabled by default.

Please speak up if you are opposed. :)

--Martin

___
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] Yusuke Suzuki is now a WebKit Reviewer

[Benjamin Poulain]

Hi WebKittens,

I am happy to announce that Yusuke is now a WebKit Reviewer :)

Yusuke is very active in all the WebKit compilers. Lately, he has been 
working hard on implementing new ES6 features and improving the spec 
compliance of existing features.


He is also familiar with our style subsystem and has greatly improved 
the CSS JIT.


Congratulation Yusuke!

Benjamin
___
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

[Benjamin Poulain]

On 4/8/15 12:01 PM, Bem Jones-Bey wrote:


On 4/7/15, 21:09, Benjamin Poulain benja...@webkit.org wrote:


The only mandatory fields are name and status.


What are the valid values for the “status” field, and what is the criteria for 
a feature to be classified under each value?


-enabled-by-default tells if the feature is in WebKit nightly.
-status is free text, it will be shown as it is.
-shipped is the list of the first release versions shipping the feature.

For the status text, I have not made up any rule yet. I used:
-Done: fully functional, maybe some minor bugs left.
-Prototyping: proof of concept kind of work.
-In Development: anything in between the other two. Even something 
that barely work can use this.


Outside status, you can also add comment if you want to clarify 
something, want feedback, etc.


Benjamin

___
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

[Benjamin Poulain]

On 4/8/15 10:34 AM, Maciej Stachowiak wrote:



On Apr 8, 2015, at 5:42 AM, Antti Koivisto koivi...@iki.fi
mailto:koivi...@iki.fi wrote:

On Wed, Apr 8, 2015 at 7:09 AM, Benjamin Poulain benja...@webkit.org
mailto:benja...@webkit.orgwrote:

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?


They’ll be used to generate a feature status page similar to the ones
that Chrome, IE and Firefox have.

I am curious if we have a way to generate the page yet.


The page is not there yet, hopefully I'll have time to start that next 
weekend.


Benjamin
___
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

[Benjamin Poulain]

On 4/8/15 3:52 PM, Bem Jones-Bey wrote:



On Apr 8, 2015, at 15:45, Benjamin Poulain benja...@webkit.org
wrote:

On 4/8/15 12:01 PM, Bem Jones-Bey wrote:


On 4/7/15, 21:09, Benjamin Poulain benja...@webkit.org
wrote:


The only mandatory fields are name and status.


What are the valid values for the “status” field, and what is the
criteria for a feature to be classified under each value?


-enabled-by-default tells if the feature is in WebKit nightly.
-status is free text, it will be shown as it is. -shipped is
the list of the first release versions shipping the feature.

For the status text, I have not made up any rule yet. I used:
-Done: fully functional, maybe some minor bugs left.
-Prototyping: proof of concept kind of work. -In Development:
anything in between the other two. Even something that barely work
can use this.

Outside status, you can also add comment if you want to clarify
something, want feedback, etc.


What do you think about having a version of “Done” for fully
functional, but -webkit prefixed? For example, we’ve implemented all
the features of CSS Shapes Level 1, the spec is in CR, but we still
have some bugs to fix. I’d assume that would be past the prototyping
phase at this point, but not quite Done, given that it’s still
prefixed.


If there are only minor bugs left, my first preference would be to 
unprefix. :)


If the bugs are not so minor, I think In Development would be okay.

You can also make up your own status string for now, I'll triage them at 
some point :)


All of this is really about documentation. Add as much comments as you 
need in comment to explain the state of the feature.


Benjamin
___
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

[Benjamin Poulain]

On 4/8/15 10:41 PM, Daryle Walker wrote:

On Apr 8, 2015, at 6:45 PM, Benjamin Poulain benja...@webkit.org wrote:


On 4/8/15 12:01 PM, Bem Jones-Bey wrote:


On 4/7/15, 21:09, Benjamin Poulain benja...@webkit.org wrote:


The only mandatory fields are name and status.


What are the valid values for the “status” field, and what is the criteria for 
a feature to be classified under each value?


-enabled-by-default tells if the feature is in WebKit nightly.
-status is free text, it will be shown as it is.
-shipped is the list of the first release versions shipping the feature.


Add, at least eventually, a “retired” column for the release version that 
dropped the feature. Maybe include a list of newer features that (at least 
partially) replace it. (An empty list would mean no replacement, or none yet.)


Yep, that's a good point, Shared workers is a good example of such case.


For the status text, I have not made up any rule yet. I used:
-Done: fully functional, maybe some minor bugs left.
-Prototyping: proof of concept kind of work.
-In Development: anything in between the other two. Even something that 
barely work can use this.

Outside status, you can also add comment if you want to clarify something, 
want feedback, etc.


—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com



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

[webkit-dev] Filling the features.json files

[Benjamin Poulain]

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.


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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Benjamin Poulain]

Looks llke nobody objects. Please make sure to #ifdef everything and 
disable the feature on OS X and iOS.


What is your plan for testing?

On 5/19/15 6:31 PM, Gyuyoung Kim wrote:

Hello,

I would like to listen what do you think to support 
'registerProtocolHandler' in WebKit2.


This feature is to execute web content through registered custom protocol.
- For example, web content can register mailto custom protocol using 
this feature,

script
navigator.registerProtocolHandler(mailto,
  https://mail.naver.com/;,
  Web Mail);
/script

html
head
titleWeb Protocol Handler Sample - Test/title
/head
body
pSend an email : a href=mailto://;this !/a/p
/body
/html

Besides this feature has been supported by Mozilla and Chromium (From 
Mozilla 3.0, Chromium 13).
  - 
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

  - https://developer.mozilla.org/en/docs/Web-based_protocol_handlers

The feature is included in the W3C recommendation 28 released on Oct. 
2014.

  - W3C spec : http://www.w3.org/TR/html5/webappapis.html#custom-handlers

IIRC, some WebKit1 ports supported this feature though, those ports 
were deprecated. Now WebKit port supports this feature no more.


There is a very old bug to support this feature though, it wasn't 
maintained so far. Recently I updated it based on latest WebKit.

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

Feel free to give me any feedback about this feature.

Gyuyoung.


___
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] TestWebKitAPI and CMake

[Benjamin Poulain]

On 8/7/15 4:59 PM, Alex Christensen wrote:

Right now, the Mac and Windows ports have TestWebKitAPI built as a single 
executable.  Tools/TestWebKitAPI/CMakeLists.txt currently creates many 
executables to test things in groups.  I want to make the Windows port build 
everything with CMake at the beginning of next week, but I’m not sure how to 
proceed and build TestWebKitAPI.  I see 3 options:

1) Change the GTK and EFL ports to build and run one TestWebKitAPI executable.
2) Change the Windows and maybe eventually Mac ports to build many 
TestWebKitAPI executables (TestWTF, TestJavaScriptCore, etc.).  It would be 
easiest for me if this were done after removing the Visual Studio build system.
3) Maintain different CMake builds of TestWebKitAPI building one or many 
executables.  This would probably be the least invasive option.

I consider each option to have about equal merit, but I think I need input from 
the GTK and EFL maintainers before proceeding.  Either way, there would be 
slight differences between the ports because of things like WebKit2 not 
existing on Windows right now, so I suggest the third option.


I have the feeling [2] may be the most useful for the project.

Having one binary per test suite seems better to parralelize (some of) 
them. It may also reduce flakiness due the reduced dependencies.


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

Re: [webkit-dev] Adding generated files to the Mac build

[Benjamin Poulain]

On 7/30/15 2:31 PM, Benjamin Poulain wrote:

On 7/30/15 10:56 AM, Xabier Rodríguez Calvar wrote:

Maybe it is something very stupid that I am missing, but I added a new
IDL file, I added the object cpp and h files to the WebCore target, the
idl file to the corresponding list, etc, but when I build I get linking
errors caused by the non compilation of the generated JSxxxfile.cpp.
How do I add that? Do I have to really do it by hand?

Thanks for the help advance!


You need to add the cpp file in Xcode (WebCore-Derived Sources).

If you don't have Xcode, email me the bug number and I'll update your
patch.


PS: Please, please, please, Alex, finish the migration to CMake :)


+1!


Just saw your messages on IRC. Any luck?

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

Re: [webkit-dev] Adding generated files to the Mac build

[Benjamin Poulain]

On 7/30/15 10:56 AM, Xabier Rodríguez Calvar wrote:

Maybe it is something very stupid that I am missing, but I added a new
IDL file, I added the object cpp and h files to the WebCore target, the
idl file to the corresponding list, etc, but when I build I get linking
errors caused by the non compilation of the generated JSxxxfile.cpp.
How do I add that? Do I have to really do it by hand?

Thanks for the help advance!


You need to add the cpp file in Xcode (WebCore-Derived Sources).

If you don't have Xcode, email me the bug number and I'll update your patch.


PS: Please, please, please, Alex, finish the migration to CMake :)


+1!

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

Re: [webkit-dev] Does anybody need LayoutTests/fast/css/style-scoped?

[Benjamin Poulain]

On 6/24/16 8:49 AM, Konstantin Tokarev wrote:

Hello,

If I understand correctly, support for 'scoped' attribute of 

Re: [webkit-dev] Some text about the B3 compiler

[Benjamin Poulain]

On 1/30/16 3:36 PM, Michael Catanzaro wrote:

On Sun, 2016-01-31 at 06:00 +0900, Yusuke SUZUKI wrote:

Now, https://bugs.webkit.org/show_bug.cgi?id=153647 and
https://bugs.webkit.org/show_bug.cgi?id=153711 are landed.

So, now, in GTK Linux x64 port, all the JSC tests pass! I think it's
time
to enable B3 in Linux x64 :D

Regards,
Yusuke Suzuki


Let's turn this on. :)

I thought we could remove all the LLVM goo from the CMake build system,
but I see there is some code to support LLVM for the EFL port on
AArch64. (For the GTK port, FTL is only supported on x86_64).

Do we want to continue to support FTL on AArch64 using LLVM, or do we
want to just turn off FTL on that platform until B3 is ready? It's
currently disabled by default, so I don't see much value in keeping it
around.


B3 on AArch64 is passing the tests since last Friday but it does not yet 
generate great assembly.


It is likely there are still bugs, just not covered by the tests. Please 
tell me if you find anything suspicious on ARM.


Benjamin

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

Re: [webkit-dev] High web process CPU usage

[Benjamin Poulain]

I tried locally with ToT but I cannot reproduce.
I load huffingtonpost.com in a tab->it takes an (in)decent amount of 
CPU. Then I switch to an about:blank tab->the CPU time goes back to zero.


The Idle Wake Ups you are getting are pretty crazy too.

Can you please file a bug for this?
Next time you see the issue, Sample the faulty process. We may find 
something interesting in there.


Cheers,
Benjamin

On 7/20/16 7:30 PM, Chris Aljoudi wrote:

Hi all,

In the Safari shipped with the latest macOS Sierra beta, as well as
Safari Tech Preview 9, there's an odd CPU usage issue with individual
tab's web processes.

For example, if one navigates to huffingtonpost.com
, Activity Monitor will show the tab web
process continually using 5-10% of CPU, along with hundreds of idle
wake-ups. Even more concerning, this continues to happen with
the huffingtonpost.com  web process even if
one picks another tab in the window.

Here's a screenshot from Activity Monitor; one Safari window is open. It
has two tabs: polymail.io ,
and about:blank. about:blank is the one currently in focus.


To investigate, I opened Web Inspector and recorded the JS/event
timeline. I found that there were timers firing quite frequently.

Now, I know Safari/WebKit /should/ be throttling timers of background
tabs *anyway*, but I figured I'd `clearInterval` all the timers to see
if that reduces the CPU usage. Nope (even though I verified no timers
are firing any longer after clearing all the intervals — no activity on
the timeline whatsoever; CPU usage and idle wake ups still way too high).

This doesn't happen with *every* page, but it happens with most that are
reasonably complex (can't tell what the trigger is yet; perhaps the use
of JavaScript timers?)

The previous Sierra beta's Safari and Tech Preview 8 both showed this
problem. I don't know whether it goes further back.

Any ideas what's going on? Is this 'expected behavior' and I'm missing
something obvious?

Thanks,
Chris


___
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