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

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] 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] 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,


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




Web Protocol Handler Sample - Test


Send an email : mailto://";>this !



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

[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] 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  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

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  wrote:


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


On 4/7/15, 21:09, "Benjamin Poulain"  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

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 
wrote:

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


On 4/7/15, 21:09, "Benjamin Poulain" 
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 12:01 PM, Bem Jones-Bey wrote:


On 4/7/15, 21:09, "Benjamin Poulain"  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 mailto:koivi...@iki.fi>> wrote:

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

Hi WebKit,

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


Could you also explain what these files are used for?


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

[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] 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 
+1-240-745-5287
www.futureclaw.com 
twitter.com/futureclaw 
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

[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] 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  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 
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

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] 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] 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] 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=245350&action=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 :

 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] Abandoned Tests

[Benjamin Poulain]

On 1/21/15 8:48 PM, Brent Fulgham wrote:

I’ve been reviewing the various Windows layout tests, and have run across a few 
tests that seem to be leftovers from the Chromium project. I think all ports 
currently skip these tests:

1. fast/dom/title-directionality-removeChild.html
2. fast/dom/title-directionality.html


They come from http://trac.webkit.org/changeset/84199
That's very much useless. The test was for chromium public API.

Let's remove!


3. fast/events/drag-image-filename.html


Looks useful. Probably worth fixing if possible.


4. fast/autoresize


That's from https://bugs.webkit.org/show_bug.cgi?id=73631
Let's remove.


5. fast/overflow/scrollbar-restored-and-then-locked.html


Useless too.



If no one is using these tests, or plans to, I would like to remove them and 
the disconnected bits of code in DRT/WKTR that were originally meant to drive 
this code.

If I don’t hear anything by this time next week, I’ll remove the code.

Thanks,

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



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

Re: [webkit-dev] 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] 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] 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 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
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] 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 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] 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 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
features and impro

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] 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 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 Vector.  Usually we have Vectors of
pointer-width things, which means 32GB on 64-bit systems (UINT_MAX *
sizeof(void*)).  Even in a world where we had more than 32GB of memory
to use within a single web process, I would hope that we wouldn't use
it all on a single Vector and that if we did, we would treat that one
specially for a bunch of other sensible reasons (among them being that
allocating a contiguous slab of virtual memory of that size is rather
taxing).  So, size_t would buy us almost nothing since if we had a
vector grow large enough to need it, we would be having a bad time
already.

I wonder: are there cases that anyone remembers where we have tried to
use Vector to store more than UINT_MAX things?  Another interesting
question is: What's the largest number of things that we store into
any Vector?  We could use such a metric to project how big Vectors
might get in the future.

-Filip



On Nov 19, 2014, at 12:20 PM, Chris Dumez 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 
https://lists.webkit.org/mailman/listinfo/webkit-dev


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





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



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

Re: [webkit-dev] Announcing the TyGL-WebKit port to accelerate 2D web rendering with GPU

[Benjamin Poulain]

How does TyGL perform compared to the other rasterizers?

What benchmarks do you use to guide the performance work?

On 11/12/14, 11:12 PM, Zoltan Herczeg wrote:

Hi All,

We are proud to announce the TyGL port (link:
http://github.com/szeged/TyGL) on the top of EFL-WebKit. TyGL (pronounced
as tigel) is part of WebKit and provides 2D-accelerated GPU rendering on
embedded systems. The engine is purely GPU based. It has been developed on
and tested against ARM-Mali GPU, but it is designed to work on any GPU
conforming to OpenGL ES 2.0 or higher.

The GPU involvement on future graphics is inevitable considering the pixel
growth rate of displays, but harnessing the GPU power requires a different
approach than CPU-based optimizations. 2D graphics is traditionally
software-based however, and 2D APIs are interfaces to these CPU-based
algorithms. WebKit GraphicsContext API is no different, so the key
challenge of our project was and is producing the expected output in a GPU
friendly way.

Key features:

Batching pipeline:

GPU provides the highest performance when a large number of triangles are
drawn with a single draw command without any OpenGL state changes. The
GraphicsContext API in WebKit provides draw operations for single shapes
however, which can result frequent state changes if implemented naively.
TyGL was designed to group these commands to reduce the number of draw
calls.

Automatic shader generator:

TyGL can generate complex shaders from multiple shader fragments, which
allows efficient batching but it also takes care to make them fit into the
shader cache of the GPU.

Trapezoid based path rendering:

TyGL uses trapezoid-based tesselation of shapes and the GPU renders them
with high anti-aliasing quality. We are continuously improving this part
of the engine and look forward to make use of new GPU capabilities (like
Pixel Local Storage) to squeeze more performance out of it.

No software fallback:

The whole engine is optimized for GPU without legacy software fallback.
Hence we don't need to sacrifice optimizations for compatibility. There
are enough software based 2D libraries which can be used when GPU is not
available.

TyGL is already capable of rendering many web-sites correctly, but some
features have not been implemented yet. We continue this work and we are
open to contributions from the community. Contact to us if you want more
information about the project.

Regards,
U-Szeged's web browser team.


___
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] 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
 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] 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
 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] 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] Streams API

[Benjamin Poulain]

On 10/31/14, 12:48 AM, Anne van Kesteren wrote:

On Fri, Oct 31, 2014 at 12:02 AM, youenn fablet  wrote:

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

There's no planned integration with XMLHttpRequest.

Nice to see you participate here Anne!

Any opinion for or against Streams? Do you know if Mozilla intends to 
implement it?


Benjamin
___
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  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] 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] 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 mailto:ddkil...@webkit.org>> wrote:


On Oct 16, 2014, at 2:38 PM, David Kilzer 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



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


Investigating this now.


Tentative fix (for the first issue found) checked in:
  

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 mailto:ddkil...@webkit.org>> wrote:


Update complete.

Please file bugs on 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 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
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
 ?


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
 ) from 3.2.3
to 4.2.11 on Thursday, October 16 from 8-10 AM PDT
.
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 
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 

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] 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
 
0x7f1ffd385710
in JSC::JSCell::toBoolean(JSC::ExecState*) const () from
libjavascriptcoregtk-1.0.so.0
#1
 
0x7f1ffd3ac7f0
in ?? () from libjavascriptcoregtk-1.0.so.0
#2
 
0x7f1ffd3b6de3
in ?? () from libjavascriptcoregtk-1.0.so.0
#3
 
0x7f1ff7a5d018
in ?? ()
#4
 
0x7f1ff7a5d000
in ?? ()
#5
 
0x7f1fb40af970
in ?? ()
#6
 
0x7f1f7dec6a28
in ?? ()
#7
 
0x7f1fac4b0ff8
in ?? ()
#8
 
0x7fffe0e09000
in ?? ()
#9
 
0x7fffe0e08da0
in ?? ()
#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::validateCell
(cell=0x3569a30) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:53
#2  0x7f434eefe39d in
JSC::WriteBarrierBase::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] Upstreaming the Haiku port again

[Benjamin Poulain]

I believe it is better for Haiku to remain out of the main tree until 
the project gains at least 2 reviewers.


Without dedicated reviewers, you will struggle to integrate any patch 
because nobody in the WebKit project is familiar with the Haiku 
platform. To give you an idea of how huge the backlog is, look at the 
list of patches currently waiting for review: 
https://webkit.org/pending-review


The best way forward is to start making patches for the fixes you have 
made that are independent of any platform. An other kind of patches is 
any refactoring that improve platform abstractions. Cleaning up the code 
this way should make it easier for you to work on a branch.


Those fixes would go toward a nommation as committer, then reviewer. 
Without multiple reviewers, it is just impossible for a port to thrive 
on the main branch.


Note that having reviewers is not a enough to upstream a port, you would 
be expected to contribute to the core. But I believe it is a necessary 
condition for success.


What are the major pain points today of developing Haiku WebKit in a 
branch? The first step is addressing those in the main branch.


Benjamin

On 10/7/14, 6:22 AM, pulkomandy wrote:

Hello WebKit,

For about one year now I've been working on updating and improving the
Haiku port of WebKit. This was upstreamed once in 2010, but then went
unmaintained for a long time and was dropped from WebKit SVN.

We have learnt from this failure (I hope) and we are ready to do another
upstreaming attempt:
  * We are now using git instead of SVN, making it much easier to track
changes in WebKit and keep our port up to date (I'm merging changes
more or less every week)
  * I'm working full-time on this, as long as our users continue donating
enough money to the Haiku project to fund my work. So I can spend the
needed time keeping things working
  * We have switched from Jam to CMake, and we share most of the build
files with the other ports using CMake
  * We have allocated a machine to run a buildbot slave for WebKit

The current sources can be viewed at https://github.com/haiku/webkit (in
branch "rebased").

I would like to use the upstreaming as an opportunity to get the code
reviewed by other WebKit developers, and for this I plan to extract
patches from this source tree, and cut them in chunks of reasonable size
for review.

Do you see any problem with this? Should I start with setting up the
buildbot, or should I first start submitting patches? In the latter
case, is starting with Tools/Scripts the right thing to do?

https://trac.webkit.org/wiki/SuccessfulPortHowTo suggests patches should
be smaller than "20k". Is that bytes, lines of code, or some other unit?

Thanks,



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

Re: [webkit-dev] Type checking / casting helpers

[Benjamin Poulain]

downcast<> fails if you do a useless cast/upcast.

Benjamin

On 10/2/14, 4:47 PM, Sam Weinig wrote:

This all looks wonderful!

One question though, why downcast<>(…)? Will we be adding an upcast<>()
function? Since the answer is probably no, could we just call this
cast<>(…)?

- Sam


On Sep 25, 2014, at 11:11 AM, Chris Dumez mailto:cdu...@apple.com>> wrote:

Hi all,

I started working on automatically generating the type *casting*
helpers for HTML/SVG/MathML Elements (e.g. toHTMLDivElement()). Until
now, we were generating only the type *checking* helpers using
make_names.pl (e.g. isHTMLDivElement()). The type *casting* helpers
had to be manually defined using NODE_TYPE_CASTS() macro.

The type casting helpers are now automatically generated for most
types. Part of the solution involved using a templated function for
type casting because the types are forward-declared and we needed to
do a static_cast<>() (a reinterpret_cast<>() could be used with
forward declarations but wouldn’t be safe due to multiple inheritance).

I initially had macros in place so that toHTMLDivElement() would still
work and would be equivalent to downcast(). The
feedback I received is that we should get rid of these macros and just
use is() / downcast() everywhere.
The new style is very close to C++’s is_class() and Boost’s
polymorphic_downcast().

I actually started updating the code to do this but I should have
emailed webkit-dev about this beforehand. I apologize for sending this
message a bit late.

Please let me know if you have feedback / concerns / questions about
this change. I hope that this email gives you a better understanding
of why I am making this change.

As I said before, the code base is not fully ported yet so the current
situation is not necessarily pretty. I will try and go through the
transition as fast as I can, provided that people don’t raise any
concerns about this.

Please also note that these new helpers still catch unnecessary type
checks / casts. As a matter of fact, those are now caught at build
time instead of linking time and should give you a nice “Unnecessary
type check” / “Unnecessary type cast” static assertion.

Also note that the plan is to get rid of TYPE_CAST_BASE() macro
entirely and extend is<>() / downcast<>() to all types, not just Nodes.

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] 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] 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 adding 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)
 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
 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
, I
developed the LLVM vectorizer
 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
. 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
 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
 to 
vectorize
C code and to emit JavaScript SIMD intrinsic

[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

[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

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] 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] 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 
)
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 ) 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 
). 
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

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

[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

[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

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

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

[Benjamin Poulain]

en I build with the script and then with Xcode, Xcode starts 
from the beginning, generates new binaries 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
R&D Engineer at Temasys Communications Pte Ltd
Fr : 06 45 85 48 80
Sg : 9086 3673

On 23 Jul 2014, at 16:49, Alexandre GOUAILLARD <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 
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 
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
    R&D Engineer at Temasys Communications Pte Ltd
Fr : 06 45 85 48 80
Sg : 9086 3673

On 22 Jul 2014, at 15:16, Benjamin Poulain 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
 

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"  wrote:


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


On Jul 29, 2014, at 7:42 PM, Bear Travis  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] 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  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] 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 , a 
document about how to add a new feature 
 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:
__ZN7WebCore17RTCPeerConnection11createOfferEN3WTF10PassRefPtrINS_29RTCSessionDescriptionCallbackEEENS2_INS_30RTCPeerConnectionErrorCallbackEEERKNS_10Di

[webkit-dev] Alex Christensen is now a reviewer

[Benjamin Poulain]

Hi WebKittens,

After much deliberation around Alex's inability to eat his own head, 
Alex is now becoming a WebKit reviewer.


Alex is experienced in many core areas of WebKit. He has been hacking on 
the CSS JIT, WebGL, Web Timing, and Pointer Lock. He is also one of the 
courageous souls who fix Windows issues.


Congratulations Alex!

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

Re: [webkit-dev] Picture element implementation

[Benjamin Poulain]

The barrier on entry is rather low to enable something in the nightly. 
It is your responsibility to make sure we don't get tons of bug reports, 
crashes, or security issues.


You need to have okay test coverage and make sure the tests work on all 
the ports (if relevant for the given platforms obviously).


Then you just make a patch and post the link to the bug on the mailing 
list. :)


Benjamin

On 7/1/14, 1:58 AM, Yoav Weiss wrote:

I've landed support for the sizes part of the syntax, currently on
HTMLImageElement only, behind an off-by-default compile time flag.
What is the proper procedure to request permission to turn on the flag
by default?


On Sun, Jun 15, 2014 at 11:31 PM, Yoav Weiss mailto:y...@yoav.ws>> wrote:


On Mon, Mar 31, 2014 at 10:59 PM, Benjamin Poulain
mailto:benja...@webkit.org>> wrote:

On 3/31/14, 9:32 AM, Yoav Weiss wrote:

I'm currently implementing the picture element
<http://picture.__responsiveimages.org/
<http://picture.responsiveimages.org/>> in Blink, to extend
the srcset

implementation and handle more responsive images use-cases

<https://groups.google.com/a/__chromium.org/d/msg/blink-dev/__vuLeAM9fJww/UHnMz7QLRWgJ

<https://groups.google.com/a/chromium.org/d/msg/blink-dev/vuLeAM9fJww/UHnMz7QLRWgJ>>.


I'd be interested in working with the WebKit project in
order to port
that work into WebKit, once it's done. Is the project
interested in the
feature?


I think it is worth experimenting with those. Please use a
compile time flag for the picture element, it still is unclear
how popular/useful this feature is going to be.


A patch for the 'sizes' part of the picture specification is waiting
for review at https://bugs.webkit.org/show_bug.cgi?id=133620
Feedback will be highly appreciated :)




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

Re: [webkit-dev] pointer lock

[Benjamin Poulain]

On 6/26/14, 10:47 AM, Alex Christensen wrote:

I’m looking into implementing pointer lock, and I’d like to remove the webkit 
prefixes now that there is a spec.  Has anyone except chromium shipped with 
pointer lock enabled or oppose me removing the prefixes before possibly 
enabling it?

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


I have nothing against unprefixing. IMHO, we should limit the API to 
fullscreen at first.


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

Re: [webkit-dev] Drop EFL WK1 port

[Benjamin Poulain]

On 6/19/14, 3:51 AM, Gyuyoung Kim wrote:

As discussed on webkit-efl mailing list, we decided to stop EFL WK1 port
since we don't use EFL WK1 port anywhere now and future. We will focus
on EFL WK2 port. We're going to remove EFL WK1 source code as well as
EWS and buildbot for EFL WK1.

EFL mailing thread regarding EFL WK1 removal -
https://lists.webkit.org/pipermail/webkit-efl/2014-June/000608.html


That is a very good news!

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

Re: [webkit-dev] Implement Geometry Interfaces

[Benjamin Poulain]

On 6/13/14, 12:53 AM, Ryosuke Niwa wrote:
On Thu, Jun 12, 2014 at 11:42 PM, Dirk Schulze > wrote:



On Jun 13, 2014, at 8:36 AM, Filip Pizlo mailto:fpi...@apple.com>> wrote:

> Why can't these data structures be implemented as JavaScript
built-ins that behave "as if" they were DOM objects?

I am not sure. What do you have in mind? How could it look like?


I think Phil and Ben are suggesting to implement these types in JSC 
like we did for typed arrays.
Yeah, sorry, I kind of jumped to the conclusion than the DOM prefix 
implied WebCore objects with wrappers, etc.


If they are built-ins, that would be a nice tool for 2D/3D work. It 
would suck a bit to have the DOM prefix on basic types but I can live 
with that.


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

Re: [webkit-dev] Implement Geometry Interfaces

[Benjamin Poulain]

On 6/12/14, 11:24 AM, Dirk Schulze wrote:

I would like to implement the Geometry Interfaces spec in WebKit[1]. The spec 
defines a couple of interfaces like DOMPoint, DOMRect, DOMQuad and DOMMatrix. 
These interfaces are more or less specified versions of proprietary interfaces 
like WebKitPoint or WebKitCSSMatrix as well as old APIs like SVGPoint, SVGRect 
or SVGMatrix that get unified between HTML/CSS and SVG. The specification 
progressed fast and is going to LC within the next weeks. I am going to start 
with DOMPoint/DOMPointReadOnly and DOMRect/DOMRectReadOnly and get to the other 
interfaces one by one. With the exception of DOMMatrix, all interfaces are 
implemented behind a runtime flag in Mozilla Gecko. DOMMatrix will be 
implemented in Gecko soon.

These interfaces will be used by other specifications like CSS OM View or SVG. 
I am going to implement these APIs behind a compiler flag called GEOMETRY. I 
would like to enable the compiler flag by default for better testing. 
Production builds should disable the compiler flag. I will pull out stable APIs 
from the flag when appropriate.


This is such a weird idea.

Ideally, the JavaScript compiler should optimize the handling of all 
those types. By having them in the DOM, you will make those 
optimizations a lot harder to make.


Wouldn't those type suffer the same fate as WebKitCSSMatrix: being 
inefficient on a large scale?


What is the rationale for not having JavaScript primitive types?

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

Re: [webkit-dev] Expose scroll elasticity/rubber band scrolling in the Desktop as a CSS property?

[Benjamin Poulain]

Hi Marco,

On 6/6/14, 10:52 AM, Marco Aurelio wrote:

I just noticed that WebKit now apparently supports "rubber band"
scrolling of Web pages beyond their physical boundaries, including
negative `scrollTop` values, that effectively render content above the
top edge of a page.

This is a welcome change, since it gives the pages a much more native
feel overall on OS X. (Instead of the previous gray background on rubber
band scroll) I would like to ask if it's possible to expose control over
this feature as a proprietary CSS property, so that Web developers may
apply this behavior to arbitrary elements in a page.

An analogous property already exists on the iOS port of WebKit, the
`-webkit-overflow-scrolling: touch` property, but perhaps something
matching the semantics of the `NSScrollElasticity` enum in Cocoa — with
values like `auto`, `none` and `allowed` — could be added?


This mailing list is the wrong place for feature requests. The list 
webkit-dev is about the development of WebKit.


I suggest you to open a bug report on https://bugs.webkit.org and/or on 
https://bugreport.apple.com.


In the bug report, you should explain your use cases. Bugs with 
interesting use cases get a lot more attention than ordinary feature 
request.


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

Re: [webkit-dev] EFL bots for ARM architecture - update

[Benjamin Poulain]

That's awesome!

Thanks a lot for adding public ARM bots. I hope that will reduce the 
time it takes to notice the build breakages on ARM.


Benjamin

On 5/22/14, 4:50 AM, Osztrogonác Csaba wrote:

Hi All,

WebKit hackers from University of Szeged are still on the board,
and we are committed to having better WebKit on ARM Linux.

We migrated the two builder bots to http://build.webkit.org/waterfall :
- EFL Linux ARMv7 Thumb2 Release (Build)
- EFL Linux ARMv7 Traditional Release (Build)

Additionally we managed to setup JSC tester bots for ARM and Thumb2,
temporarily on http://build.webkit.sed.hu/waterfall , because they
need some special config which doesn't work with the official master.cfg
(cross compiling on x86, wrap the jsc by a script which run tests via
ssh connection on an ARM development board, ...)

One more thing: Gábor managed to setup an ARM64 build only bot,
which can be found here: http://build.webkit.sed.hu/waterfall
We are planning to run JSC tests on this bot too, once there
is ARM64 Linux development board available.

Ossy

Gabor Rapcsanyi írta:

Hello WebKittens,

I would like to annonunce our fresh new EFL Linux bots for ARM 
architecture. If you are interested, you can find them at: 
http://build.webkit.sed.hu/waterfall


The bots:
 - EFL ARMv7 Linux Release (Build)
 - EFL ARMv7 Traditional Linux Release (Build)

These bots are just builders but we are also planning to support 
jscore and layout testing as well later.


Regards,
Gabor Rapcsanyi

___
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] Remove FILTERS and CSS_FILTERS flag

[Benjamin Poulain]

On 09/05/2014 01:18, Dirk Schulze wrote:
> Do we still need the FILTERS and CSS_FILTERS compile time flag? Does any port 
> still build without filters enabled? It is an integral part of the web 
> platform now.
>
It looks like both are OFF in WebKitFeatures.cmake ...but are defined in
cmakeconfig.h.cmake I don't know which one wins :)

Unless it is a major problem for GTK or EFL, I think it would be great
to remove those #ifdefs.

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

Re: [webkit-dev] support for navigator.cores or navigator.hardwareConcurrency

[Benjamin Poulain]

On 5/7/14, 4:13 PM, Benjamin Poulain wrote:

On 5/7/14, 3:52 PM, Filip Pizlo wrote:

Exactly. Ben, Oliver, and others have made arguments against web
workers. Rik is not proposing web workers.  We already support them. The
point is to give API to let developers opt into behaving nicely if they
are already using web workers.


I have nothing against Web Workers. They are useful to dispatch
background tasks.

They are basically the Web equivalent dispatch_async() of GCD, which is
already a very useful tool.

What you are suggesting is useful for making Web Workers the tool to do
high performance multi-thread computation.
I don't think Web Workers are a great tool for that job at the moment. I
would prefer something along TBB, GCD or something like that.


For high performance computation, I think a more useful API would be
something like TBB parallel_for with automatic chunking.
It is actually had to do faster than that with the number of cores
unless you know your task very very well.

It would be a little more work for us, but a huge convenience for the
users of Web Workers.


After chatting with Filip, it seems such a model is unlikely to happen 
anytime soon for JavaScript.


In the absence of any tasks/kernels model, I am in favor of exposing a 
"good number of thread" API. It is definitely better than nothing.


Benjamin


They can already write code that overloads the system but they currently
have *no* way of writing code that even tries to be well-behaved except
maybe to avoid workers entirely.

I'm also a little disturbed by arguments against the general usefulness
of ncpu. We use it for the parallel JIT and parallel GC because
regardless of system load those are *the best* guesses of how many cpus
to use.

-Fil

On May 7, 2014, at 3:24 PM, Rik Cabanier mailto:caban...@gmail.com>> wrote:





On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt mailto:oli...@apple.com>> wrote:


On May 7, 2014, at 3:15 PM, Rik Cabanier mailto:caban...@gmail.com>> wrote:





On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt mailto:oli...@apple.com>> wrote:


On May 7, 2014, at 2:41 PM, Rik Cabanier mailto:caban...@gmail.com>> wrote:
>
> When would I as a user, not want a page or web application
to be as fast as possible? Has a user ever complained about a
desktop app that uses too many of his CPU's? I think Oliver's
point was that other processes might fight for the same CPU
resources but that is not unexpected for users.

What happen if i go to your website while i'm doing something
else in the background?  What if i'm playing a game while
waiting for my machine to do something else? What if your
page is in the background? Or my battery is running low.


Sure. However, a page can already do this today.
This will just give the author a way to make a semi-informed
decision. Without this, he might just spin up too many threads
and starve the rest of the system.

You need to stop thinking in terms of a user wanting only one
thing to happen at a time.


I'm not sure if I follow. How would this be any different from a
regular desktop application?


The argument is that this is not behaviour that users want - the
fact that desktop applications do this is a bug in the programming
model.

APIs like GCD were specifically created to allow a developer to
make an application than can automatically scale (or descale) to
match the behaviour that is best for the user. That’s the model we
want to encourage on the web.


Filip already covered this much better than I could in the webkit bug:
https://bugs.webkit.org/show_bug.cgi?id=132588

This proposal is not about inventing a thread/task scheduling
mechanism; this is just a way to make an informed guess without having
to use a polyfill,
___
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] support for navigator.cores or navigator.hardwareConcurrency

[Benjamin Poulain]

On 5/7/14, 3:52 PM, Filip Pizlo wrote:

Exactly. Ben, Oliver, and others have made arguments against web
workers. Rik is not proposing web workers.  We already support them. The
point is to give API to let developers opt into behaving nicely if they
are already using web workers.


I have nothing against Web Workers. They are useful to dispatch 
background tasks.


They are basically the Web equivalent dispatch_async() of GCD, which is 
already a very useful tool.


What you are suggesting is useful for making Web Workers the tool to do 
high performance multi-thread computation.
I don't think Web Workers are a great tool for that job at the moment. I 
would prefer something along TBB, GCD or something like that.



For high performance computation, I think a more useful API would be 
something like TBB parallel_for with automatic chunking.
It is actually had to do faster than that with the number of cores 
unless you know your task very very well.


It would be a little more work for us, but a huge convenience for the 
users of Web Workers.


Benjamin


They can already write code that overloads the system but they currently
have *no* way of writing code that even tries to be well-behaved except
maybe to avoid workers entirely.

I'm also a little disturbed by arguments against the general usefulness
of ncpu. We use it for the parallel JIT and parallel GC because
regardless of system load those are *the best* guesses of how many cpus
to use.

-Fil

On May 7, 2014, at 3:24 PM, Rik Cabanier mailto:caban...@gmail.com>> wrote:





On Wed, May 7, 2014 at 3:19 PM, Oliver Hunt mailto:oli...@apple.com>> wrote:


On May 7, 2014, at 3:15 PM, Rik Cabanier mailto:caban...@gmail.com>> wrote:





On Wed, May 7, 2014 at 2:47 PM, Oliver Hunt mailto:oli...@apple.com>> wrote:


On May 7, 2014, at 2:41 PM, Rik Cabanier mailto:caban...@gmail.com>> wrote:
>
> When would I as a user, not want a page or web application
to be as fast as possible? Has a user ever complained about a
desktop app that uses too many of his CPU's? I think Oliver's
point was that other processes might fight for the same CPU
resources but that is not unexpected for users.

What happen if i go to your website while i'm doing something
else in the background?  What if i'm playing a game while
waiting for my machine to do something else? What if your
page is in the background? Or my battery is running low.


Sure. However, a page can already do this today.
This will just give the author a way to make a semi-informed
decision. Without this, he might just spin up too many threads
and starve the rest of the system.

You need to stop thinking in terms of a user wanting only one
thing to happen at a time.


I'm not sure if I follow. How would this be any different from a
regular desktop application?


The argument is that this is not behaviour that users want - the
fact that desktop applications do this is a bug in the programming
model.

APIs like GCD were specifically created to allow a developer to
make an application than can automatically scale (or descale) to
match the behaviour that is best for the user. That’s the model we
want to encourage on the web.


Filip already covered this much better than I could in the webkit bug:
https://bugs.webkit.org/show_bug.cgi?id=132588

This proposal is not about inventing a thread/task scheduling
mechanism; this is just a way to make an informed guess without having
to use a polyfill,
___
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] support for navigator.cores or navigator.hardwareConcurrency

[Benjamin Poulain]

On 5/7/14, 2:47 PM, Oliver Hunt wrote:


On May 7, 2014, at 2:41 PM, Rik Cabanier  wrote:


When would I as a user, not want a page or web application to be as fast as 
possible? Has a user ever complained about a desktop app that uses too many of 
his CPU's? I think Oliver's point was that other processes might fight for the 
same CPU resources but that is not unexpected for users.


What happen if i go to your website while i'm doing something else in the 
background?  What if i'm playing a game while waiting for my machine to do 
something else? What if your page is in the background? Or my battery is 
running low.

You need to stop thinking in terms of a user wanting only one thing to happen 
at a time.


+1

And there are actually many bug reports about native apps using too much 
CPU when the user is not expecting it (simple tasks and/or the process 
is not frontmost).


Benjamin

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

Re: [webkit-dev] Blog post on the contributor's meeting?

[Benjamin Poulain]

On 4/24/14, 11:00 AM, Bem Jones-Bey wrote:

At the meeting last week, we talked about having more blog posts on the
WebKit blog. Perhaps we could start with one on the contributors'
meeting itself?

The easiest thing to do would be to do a roundup of posts written by
attendees on their own blogs, assuming anyone has done that. I've
written a post for the Adobe Web Platform Blog[1]; has anyone else
written up their experiences? If so, I could draft such a roundup post.

If not, I could write something up for the WebKit blog, but would like
to have an idea of what we as a project would think as important to
highlight.

In addition, there are many sessions from the contributor meeting that
don't have notes or anything on them on the meeting page[2]. If you have
anything you could add for any of the sessions, that would be very useful.


It would be redundant to post the same information on the WebKit blog. 
In my opinion, your blog post is already a good summary.


I think we should make several small blog post about specific subjects. 
I have seen really nice stuffs in the session I attended. From what I 
have seen, we should have posts introducing:

-CSS Regions + inspector integration
-New awesomeness in the Inspector
-CSS Grid Layout

Email me if you need access to the blog.

By the way, anyone knows what is up with Planet WebKit?

Benjamin



Thanks,
Bem

[1]:
http://blogs.adobe.com/webplatform/2014/04/24/adobe-web-platform-goes-to-the-2014-webkit-contributors-meeting/
[2]: https://trac.webkit.org/wiki/April%202014%20Meeting




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

Re: [webkit-dev] What's up with the CHECK_CONSISTENCY macro?

[Benjamin Poulain]

Hi Andrei,

On 4/24/14, 11:18 PM, Andrei Bucur wrote:

I’m trying to add some line boxes sanity checks and I’ve noticed there’s
a CHECK_CONSISTENCY macro guarding some consistency validation code (go
figure!) but that’s never defined in WebKit/Source. Anybody has an idea
how that macro is used?


The consistency checks in WebCore and WTF are for Debug code that is 
useful for debugging, but too slow to be enabled by default in debug builds.


You just add #define FOOBAR_CONSISTENCY 1 when needed.

From a quick check at CHECK_CONSISTENCY, it looks like they were 
disabled a long time ago 
(https://bugs.webkit.org/show_bug.cgi?id=14981). Maybe it is dead code 
now...?


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

Re: [webkit-dev] Enabling CSS Grid Layout runtime flag by default

[Benjamin Poulain]

Hi Javier,

On 4/25/14, 5:21 AM, Javier Fernandez wrote:

As we discussed in the last WebKit Contributors Meeting, I think it
would be useful to have the runtime feature enabled by default.

We already have a compilation flag since r164659 [1], so enabling the
runtime flag by default would make easier for developers to try out and
test the new feature. Of course, in release builds the compilation flag
is kept to false as expected.

If everybody agrees, we have a patch ready to do this change:
http://webkit.org/b/132189

FWIW, in WebKit nightly builds the runtime feature is set to true or
false depending on the compilation flag since r166614 [2]. However, this
is only affects the Mac port.


Personally, I think you should remove the runtime flag, and be very 
aggressive on the #ifdefs to make sure everything can be disabled when 
shipping.


It would be nice if you could email webkit-dev from time to time about 
your progress on completeness, testing, performance, etc.
I like Zoltan's emails about CSS Shapes status, it is something we 
should do more in the project.


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

Re: [webkit-dev] Style proposal for branch style for macros

[Benjamin Poulain]

On 4/19/14, 1:09 PM, Filip Pizlo wrote:
> When guarding code with macros that are always defined, such as
> ASSERT_DISABLED (it's always either 0 or 1), we have a choice between:
> 
> if (!ASSERT_DISABLED) {
> // do things
> }
> 
> and:
> 
> #if !ASSERT_DISABLED
> // do things
> #endif
> 
> I'd like to propose that /anytime the normal if would be semantically
> equivalent to the preprocessor #if, the normal if should be used/.
> 
> We don't lose any compiler optimization, since even at -O0, the compiler
> will constant fold the normal if.  We do gain a lot of clarity, since
> the control flow of normal if statements is subject to proper indentation.
> 
> The "semantically equivalent" requirement still allows for #if to be
> used for thinngs like:
> 
> - Guarding the placement of fields in a class.
> - Guarding the definitions of other macros (in the case of
> ASSERT_DISABLED, we define ASSERT in different ways guarded by #if's)
> - Guarding the definition/declaration/inclusion of entire functions,
> classes, and other top-level constructs.

This is adding complexity for little gain.

I would not mind replacing all the macros by real if() branches, but
that is not possible in plenty of cases. Using both the branches and the
macro seems like a bad idea.

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

Re: [webkit-dev] Remove CANVAS_PATH compiler flag where possible

[Benjamin Poulain]

On 4/16/14, 10:40 PM, Dirk Schulze wrote:


On Apr 17, 2014, at 5:45 AM, Benjamin Poulain 
wrote:


Hi Dirk,

On 4/16/14, 1:18 PM, Dirk Schulze wrote:

I would like to ask to remove the CANVAS_PATH compiler flag from
WebCore where possible. At the moment it guards the Path2D object
and all related methods in Canvas like:

void fill(Path2D path, optional CanvasWindingRule winding); void
stroke(Path2D path); void clip(Path2D path, optional
CanvasWindingRule winding);

Firefox and Chrome will ship with Path2D enabled in the next
release versions. WebKits implementation is interoperable with
Firefox and Chrome.

The only method on Path2D that just reached consensus but does
not ship in other browsers is addPath(Path2D, optional
SVGMatrix?). The risk that it will change in an not interoperable
way is minimal. However, at the moment I would like to guard it
behind a compiler flag and implementations shouldn’t ship with it
within the next couple of weeks. Alternatively, I can remove the
IDL method in favor for removing the CANVAS_PATH compiler flag
completely.


I am in favor of keeping the flag around until the spec is stable
(or Safari ships the feature). The flag is used only in 4 files,
its cost seems minimal.


No objection for addPath. Path2D in general is stable enough and is
shipping in Firefox and Chrome with the next releases. I would like
to remove the flag around Path2D. Safari 7 ships with CANVAS_PATH
enabled when the flag is removed around Path2D, it should not enable
the flag for addPath() yet. Would you be ok with this suggestion?


That sounds like a good plan.

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

Re: [webkit-dev] Remove CANVAS_PATH compiler flag where possible

[Benjamin Poulain]

Hi Dirk,

On 4/16/14, 1:18 PM, Dirk Schulze wrote:

I would like to ask to remove the CANVAS_PATH compiler flag from WebCore where 
possible. At the moment it guards the Path2D object and all related methods in 
Canvas like:

 void fill(Path2D path, optional CanvasWindingRule winding);
 void stroke(Path2D path);
 void clip(Path2D path, optional CanvasWindingRule winding);

Firefox and Chrome will ship with Path2D enabled in the next release versions. 
WebKits implementation is interoperable with Firefox and Chrome.

The only method on Path2D that just reached consensus but does not ship in 
other browsers is addPath(Path2D, optional SVGMatrix?). The risk that it will 
change in an not interoperable way is minimal.
However, at the moment I would like to guard it behind a compiler flag and 
implementations shouldn’t ship with it within the next couple of weeks.
Alternatively, I can remove the IDL method in favor for removing the 
CANVAS_PATH compiler flag completely.


I am in favor of keeping the flag around until the spec is stable (or 
Safari ships the feature). The flag is used only in 4 files, its cost 
seems minimal.


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

[webkit-dev] Enabling CSS JIT on Linux x86_64 for EFL and GTK?

[Benjamin Poulain]

Hi,

Now that EFL and GTK use CMake, can someone look at what is missing to 
enable the CSS JIT on Linux x86_64?


Last time I tried, there were some issues with the headers. It is likely 
trivial to fix with a local build.


I would be happy to fix any problem with the compiler if it does not 
work on Linux.


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

Re: [webkit-dev] Picture element implementation

[Benjamin Poulain]

On 3/31/14, 9:32 AM, Yoav Weiss wrote:

I'm currently implementing the picture element
 in Blink, to extend the srcset
implementation and handle more responsive images use-cases
.

I'd be interested in working with the WebKit project in order to port
that work into WebKit, once it's done. Is the project interested in the
feature?


I think it is worth experimenting with those. Please use a compile time 
flag for the picture element, it still is unclear how popular/useful 
this feature is going to be.


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

Re: [webkit-dev] CMake for WebKitGTK+

[Benjamin Poulain]

On 3/25/14, 10:52 AM, Martin Robinson wrote:

On Wed, Mar 5, 2014 at 7:30 PM, Martin Robinson  wrote:

For a time, I kindly request that authors writing GTK+-specific
patches consider both the autotools and CMake GTK+ builds in their
patches. Hopefully within the next couple months, we can announce the
complete removal of the autotools build. I'd like to apologize ahead
of time for the inconvenience, as we iron out the final bugs. With
luck, the future will be much simpler and smoother for everyone.


After internal discussions, we decided to accelerate the removal of
the autotools build. I have just removed it [1]. WebKit now has three
build systems, which means we have shed five build systems in a little
over a year.

1. http://trac.webkit.org/changeset/166239


That is awesome!

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

Re: [webkit-dev] Anyone else having these problems with run-webkit-tests?

[Benjamin Poulain]

Same here :(

On 3/23/14, 12:15 PM, Darin Adler wrote:

When I use run-webkit-tests to run the entire test suite, on a debug build of 
TOT WebKit, on Mavericks, I’m having the following problems:

- Towards the end of the run, the tests run slowly, over a second per test on 
my 3.5GHz i7 iMac with tons of memory, which is about 10X too slow I think. The 
sample shows the vast majority of the time is spent in JavaScript garbage 
collection. This is running mostly the svg/custom tests.

Yep. The time from 31k to 33k is a long as from 0 to 31k :(

- Towards the end of the run, instead of the 8 parallel copies of 
DumpRenderTree, only 1 copy of DumpRenderTree seems to run. This is running 
mostly the svg/custom tests.
I think the problem is we can only run DumpRenderTree in parallel on 
different folders. Toward the end, everything left is one or two slow 
folders.

- Six audio tests always fail, and as a side effect of their failure, they dump 
expected.png files into my LayoutTests/platform/mac/webaudio directory.

I often have flaky tests in webaudio but not systematic failures.

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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Benjamin Poulain]

On 2/11/14, 9:26 AM, Maciej Stachowiak wrote:
> On Feb 10, 2014, at 1:38 PM, Benjamin Poulain 
> wrote:
>> 
>> Can't we add a compile time flag instead? The chromium patch you
>> linked is inelegant and it touches some hot paths.
>> 
>> Another advantage of compile time flag is Andreas eventually notice
>> when they become useless and remove all the unnecessary cruft ;)
> 
> I think on the whole, runtime flags are a better way to do things.
> They allow features to get much better testing before they are turned
> on by default, among other things by enabling regression tests to
> run. They also make it more likely that both configurations keep
> compiling, regardless of which is default.

Why not enabling the feature entirely on trunk? (and disable it when
shipping product by disabling the compile time flag?).
I think feature doing that tends to become stable a lot quicker.

We remove experimental features frequently. The compile time flags make
it a lot easier to clean up.

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

Re: [webkit-dev] On web-exposing features disabled at runtime

[Benjamin Poulain]

On 2/10/14, 10:40 AM, Sergio Villar Senin wrote:

I'm sending this to the list because it might affect different
components inside the project.

So as smfr correctly reported here[1] for all those features that don't
have a feature flag (like grid layout) we're web-exposing the CSS
properties of the feature even if it's disabled at runtime (we're
exposing them as well for features enabled at build time but disabled at
runtime).

If I am not wrong, we just disable the parsing of those properties that
are not runtime enabled, but the properties are exposed anyway,
something easy to check doing for example:
Object.getOwnPropertyDescriptor(document.body.style, property-name).


Yep that is bad.


The question is whether this is an acceptable behavior or not, and how
to fix it in case we don't like it. I guess it's safe to conclude that
it isn't something that we want in general, as it might confuse web
authors (they see the how properties are available but do nothing).
Regarding how to fix it, I guess the idea is to do something similar to
what Eric did in Blink last year[2], i.e., filtering out the list of
properties that are runtime disabled.

Opinions?


Can't we add a compile time flag instead?
The chromium patch you linked is inelegant and it touches some hot paths.

Another advantage of compile time flag is Andreas eventually notice when 
they become useless and remove all the unnecessary cruft ;)


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

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

[Benjamin Poulain]

On 2/4/14, 7:08 AM, Steven Coul (scoul) wrote:
> My big worry about that, is that somewhere somebody is thinking about
> using that argument to add Flash and/or Moonlight to Webkit - and
> down that path madness lies ;-)
> 
> There really aren’t any “size-hogs” in WK other than SVG itself - but
> it’s been a while since I looked I admit.
> 
> I tend to think of “fork it” as a last desperate measure rather than
> first plan - but whatever - I was just interested in others opinions
> since I don’t have a horse in this race anyhow.

We do worry about binary size, but removing a core feature is not a
solution.

There are plenty of other opportunities to improve the WebKit binary.
Patches for that are welcome too ;)

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

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

[Benjamin Poulain]

On 1/28/14, 4:20 PM, Thomas Fletcher wrote:

Not a true statement if you consider out of tree ports.

None of the ports we have done at Crank have used or needed svg support
and as embedded systems, they all benefit from the smaller footprint.


Out of tree ports that do not contribute back upstream are not relevant 
for deciding the direction of WebKit.


Do you guys help on WebKit.org?

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

Re: [webkit-dev] Nix future

[Benjamin Poulain]

Hi,

That is sad, it was great working with Nix.
Having a low maintenance port was a fantastic experience.

Good luck with your next adventures.

Benjamin

On 16/01/2014 11:20, Luciano Wolf wrote:
> Hi Webkittens,
>
> During the last weeks, people interested in using or experimenting
> with Nix have been asking us about the upstreaming process, how long
> Nix will be supported, etc. The answer has always been in the lines of
> “we're working hard to make it last for a long time” -- and that was
> true.
>
> However, now we have a definitive answer, as this week we were
> notified that the resources of the Nix project will be redirected to
> other areas/projects. In practice, it means we won't be able to keep
> our efforts with its development and the upstreaming process and all
> activities related to Nix are going to stop by the end of this
> month[1].
>
> We are going to remove Nix from trunk in the next days but the code
> will remain on our usual github[2] page, for the interested parties.
> If you have any question or specific interest on Nix, please don't
> hesitate to contact us.
>
> We would like to thank especially the Szeged team for developing new
> features, tests, bugfixes, Benjamin Poulain and others from the Apple
> team and WebKit community as a whole for reviewing and supporting the
> upstreaming process.
>
>
> Regards,
> Nix Team
>
> [1] https://www.youtube.com/watch?v=JSUIQgEVDM4
> [2] https://github.com/WebKitNix/webkitnix
> ___
> 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] Announcement: web replay support

[Benjamin Poulain]

On 1/13/14, 4:03 PM, Brian Burg wrote:

I’m excited to announce that I’ve begun work on upstreaming web replay
support into WebKit. Web replay functionality allows developers to debug
their web applications by exactly recording interactions with a web
program, and then replaying the resulting execution at will. A prototype
implementation has integration with the Web Inspector, and supports many
important web features.

Most replay-related code will be behind the ENABLE(WEB_REPLAY) flag. It
will be off by default until folks feel that the feature is ready for
feedback through nightly builds.


That is great!

Where will the tool be integrated in the Inspector? Will it be an 
extension of the timeline or a new tab?


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

Re: [webkit-dev] Rename PLATFORM(MAC) to PLATFORM(COCOA)?

[Benjamin Poulain]

On 1/11/14, 8:49 PM, Eric Wing wrote:
> On 1/11/14, Maciej Stachowiak  wrote:
>>
>> On Jan 11, 2014, at 3:50 PM, Darin Adler  wrote:
>>
>>>
>>> On Jan 11, 2014, at 3:36 PM, Maciej Stachowiak  wrote:
>>>

 Ideally it should be USE(THE_SPECIFIC_FRAMEWORK_IN_QUESTION). I would
 guess that much of PLATFORM(MAC) that is valid for both Mac and iOS
 should actually be USE(FOUNDATION). PLATFORM really shouldn't be used for
 things other than terminal platform names. USE(COCOA) would be an ok
 stopgap if sorting down to more specific conditionals delays this cleanup
 too much.
>>>
>>> Sorting down to specific conditionals will definitely delay the cleanup
>>> too much!
>>>
>>> Thinking about USE(FOUNDATION) and looking at code it’s clear that the Mac
>>> and iOS ports have a lot more in common than Foundation. I saw that
>>> looking at PLATFORM(MAC) code snippets.
>>
>> I saw that too after looking at more.
>>
>>> But as long as we’re going to have something incorrect as a first
>>> approximation, I don’t think that incorrect uses of USE(FOUNDATION) are
>>> significantly worse than incorrect uses of USE(COCOA). If long term there
>>> is not supposed to be such a thing as USE(COCOA), then I would hate to add
>>> it and then have to remove it later.
>>>
>>> It remains clear to me that a valuable and quick first step is to
>>> mechanically change PLATFORM(MAC) to BAR, and I am OK with BAR being
>>> USE(FOUNDATION), USE(COCOA), or PLATFORM(COCOA).
>>>
>>> I am sure there is a lot of easy refinement we can do immediately after.
>>> For example, we can change BAR && !PLATFORM(IOS) back to PLATFORM(MAC), if
>>> we can’t find an even better conditional. Maybe our first step can even be
>>> clever and not ever change such things to BAR, as suggested by Dan.
>>>
>>> I’d like to play the numbers game, so if our best guess is that most
>>> PLATFORM(MAC) should be USE(FOUNDATION), I would choose that for BAR.
>>
>> After thinking about it a bit - USE(COCOA) (or for that matter even
>> PLATFORM(COCOA)) might be better as a first cut. Since it's not supposed to
>> exist at all long term, it makes for an easy number to drive to zero.
>> USE(FOUNDATION) will mix both correct and incorrect uses so it will be
>> harder to drive the mistaken applications to zero.
>>
>> Regards,
>> Maciej
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
> 
> I'm new here, so sorry if I’m intruding since I don’t have much of a
> stake in this outcome, but USE(COCOA) then seems to imply to me that
> you need to also have a USE(COCOATOUCH). It so, then maybe it should
> be AppKit vs. UIKit instead for more clarity.

Here Cocoa implies both Cocoa and Cocoa Touch.

> There is another potential case where you have an Obj-C framework
> environment that is not Apple’s. I’ll cite GNUStep and Apportable as
> two cases. The former provides a Cocoa (AppKit) compatible
> implementation but tends to run on Linux or Windows. The latter
> provides a UIKit compatible implementation and tends to run on
> Android.

There is not port of WebKit for GNUStep. Consequently, it does not
impact design decisions.

> This asks the question, do you really mean Mac vs. iOS, or AppKit vs.
> UIKit, or something else?

Something else :)

The name suggested here is for all the code that is common between OS X
and iOS, but not related to the Darwin Kernel.

IMHO, COCOA is an improvement over PLATFORM(MAC).

Benjamin



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit, C++11, and Visual Studio 2013

[Benjamin Poulain]

That is awesome. Great work!

Benjamin

On 12/6/13, 2:53 PM, Brent Fulgham wrote:

Hi Everyone,

We are working hard to move WebKit toward stronger adoption of C++11
features, such as variadic templates, ranged for-loops, and initializer
lists. Unfortunately, this effort has been hampered by the small subset
of C++11 features available in Visual Studio 2010.

You can get a feel for the level of C++11 support in the last few
versions of Visual Studio here:
http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

With Visual Studio 2013, we finally have access to a compiler that
supports the major C++11 features we need. Consequently, we intend to
switch to VS2013 and begin taking advantage of these new language
constructs.

Over the next week we will be landed a series of source changes that
allow WebKit to be built with VS2013, but will continue to build with
VS2010 on our build machines.  Next Friday, we plan to land project file
changes to switch to the new compiler, and will simultaneously convert
our build system to use VS2013 as well.

Once the revised project files are landed, we will no longer be
officially supporting Visual Studio 2010 as a compiler target.

For those playing at home, you can track progress by following
https://bugs.webkit.org/show_bug.cgi?id=125192.

WebKit continues to build with the free “Visual Studio 2013 Express”
software, so I do not anticipate that this change will block any
external developers from running Windows builds.

Thanks,

-Brent





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



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

Re: [webkit-dev] Webkit seizes sound device

[Benjamin Poulain]

On 11/29/13, 4:32 PM, Jeffrey Barish wrote:
> When I visit a web page that wants to play a sound, webkit opens the sound 
> device and never lets go of it until the application exits.  I would like for 
> webkit not to open the sound device (and ignore the play request, obviously). 
>  
> Is there a way to tell webkit globally that it should ignore all sounds and 
> never, ever open the sound device?

Each platform handle multimedia differently.

I guess this is for GTK?
The right mailing list would be WebKit-gtk.

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

Re: [webkit-dev] finding images on visible viewport

[Benjamin Poulain]

On 11/19/13, 8:58 PM, maheshgaw...@outlook.com wrote:
> I am trying to find the media stuff like images which are present on
> current visible viewport in Webkit. What is the best way to do it.
> 
> I had thought of looking for image elements and checking if they are
> in visible viewport or not, but images can also be set as backgrounds
> which complicates the things further.

For which bug?
What are you trying to do?

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

Re: [webkit-dev] Proposoal: Remove ENABLE(WORKERS) guards

[Benjamin Poulain]

On 11/19/13, 8:00 AM, Peter Molnar wrote:
> I'm planning to remove this flag, as all ports seem to have it on by
> default:
> https://bugs.webkit.org/show_bug.cgi?id=105784

Sounds like a good idea. :)

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

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

[Benjamin Poulain]

On 11/7/13, 4:27 PM, Tab Atkins Jr. wrote:

On Thu, Nov 7, 2013 at 3:39 PM, Timothy Hatcher  wrote:

On Nov 7, 2013, at 2:22 PM, Tab Atkins Jr.  wrote:

srcset's parsing algorithm *cannot* be extended in the future.  I gave
an example of how it would fail over on blink-dev; I can reproduce it
here if necessary.


I don't subscribe to blink-dev. The WebKit community are the ones you need to 
convince.


A simple "Yes" would have sufficed.  I was just asking if I needed to
demonstrate it.  Take this markup:



You expect this to break into two lists, "foo 1x, bar 2x" and "baz 1x,
qux 2x", which are then each split as currently proposed.

However, by the current parsing algorithm, || is read as an
unsupported descriptor, so it just breaks them into "foo 1x", "bar 2x
|| baz 1x", and "qux 2x".  The middle one is thrown away, because of
the duplicate x descriptor, and so the whole thing is just parsed to
the same value as "foo 1x, qux 2x", which is completely wrong.


This just sounds like a bad excuse. As far as I know, no browser has 
shipped srcset.


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

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

[Benjamin Poulain]

On 11/6/13, 3:24 PM, Yoav Weiss wrote:


On Wed, Nov 6, 2013 at 11:33 PM, Benjamin Poulain mailto:benja...@webkit.org>> wrote:

On 11/6/13, 10:53 AM, John Mellor wrote:

On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak
mailto:m...@apple.com>
<mailto:m...@apple.com <mailto:m...@apple.com>>> wrote:
  >
  > My initial impression is that it seems a bit overengineered.

I sympathize. The issue of srcN appearing to be a complex
solution to a
seemingly simple problem came up again on IRC chatting to rniwa,
so I
thought I'd try to explain this briefly.

Unfortunately, responsive images is a deceptively complex
problem. There
are 3 main use cases:
1. dpr-switching: fixed-width image resolution based on
devicePixelRatio.
2. viewport-switching: flexible-width image resolution based on
viewport
width and devicePixelRatio.
3. art direction: same as #1 or #2, except additionally, must serve
completely different images based on viewport width.


How important and common are each of those use cases?
Handling every imaginable use case by the Engine is a non-goal.


There has been a lot of demand for dpr-switching since the first
iPad Retina. This has caused some very ugly hacks on the Web. It is
very important to address that issue.

Viewport switching is usually done to adapt images for mobile device
VS large/huge display devices. It is a valid concern but it is not
easily addressed. Srcset can/should likely be improved regarding this.

I believe (feel free to prove me wrong) dynamic viewport adaptation
and what you call "art direction" is not as common.

On a survey ran at the last Mobilism conference (and on Twitter) 41% of
respondents said they're already using some hack to get their responsive
image "art-directed".
A manual responsive site survey
<http://japborst.net/blog/the-current-state-of-art-direction.html> showed that
23% of the sites "art-direct" their images, and 58% do that when
(subjectively) the design requires it.
So it might not be as common as viewport switching (which is practically
everywhere), but it is pretty common.


The survey you linked 
(http://japborst.net/blog/the-current-state-of-art-direction.html) was 
targeting specifically responsive websites. Those websites represents 
only an unquantified subset of the web.


Even with that very targeted subset, only a small percentage was 
actually implementing art-direction.


It looks to me like art-direction should not be imposing all the design 
constraints over the more important use cases.



Something that is still unclear to me is why srcN would be doing a 
better job than JavaScript for art-direction?
There are many complex cases that are handled dynamically (changing 
images on zoom; tiling large images on zoom; changing layout on 
rotation; creating popover style layout when switching 
portrait/landscape, etc).


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

Re: [webkit-dev] Using protect(this) versus ref()ing in its caller

[Benjamin Poulain]

On 11/6/13, 2:01 PM, Ryosuke Niwa wrote:

This discusion came up multiple times on Bugzilla so I'm posting it here.

When a member function f() of a RefCounted object can end up removing
the last ref to the object itself, should we do:

void Foo::f() {
 RefPtr protect(this);
}

or

RefPtr foo = rawPointerToFoo;
foo->f()

in its call site.

The first approach guarantees that any call to f() is safe while the
second approach is future proof if we add more code to use foo after
calling f().

I think it's good to agree on one convention here since managing
lifetime of objects is tricky, and having one convention will make it
easier to reason about things.


To preserve the encapsulation, it seems to me
RefPtr protect(this);
makes more sense. If a method calls something that would cause the 
object to be removed, the method itself should ensure the validity of 
the following instructions.


The user of the interface should not have to know such implementation 
detail of the object.



The second one is useful for other use cases:
RefPtr foo = rawPointerToFoo;
doSomething(foo); // This could potentially destroy foo.
foo->f();

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

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

[Benjamin Poulain]

On 11/6/13, 10:53 AM, John Mellor wrote:

On Sun, Oct 20, 2013 at 2:00 AM, Maciej Stachowiak mailto:m...@apple.com>> wrote:
 >
 > My initial impression is that it seems a bit overengineered.

I sympathize. The issue of srcN appearing to be a complex solution to a
seemingly simple problem came up again on IRC chatting to rniwa, so I
thought I'd try to explain this briefly.

Unfortunately, responsive images is a deceptively complex problem. There
are 3 main use cases:
1. dpr-switching: fixed-width image resolution based on devicePixelRatio.
2. viewport-switching: flexible-width image resolution based on viewport
width and devicePixelRatio.
3. art direction: same as #1 or #2, except additionally, must serve
completely different images based on viewport width.


How important and common are each of those use cases?
Handling every imaginable use case by the Engine is a non-goal.

There has been a lot of demand for dpr-switching since the first iPad 
Retina. This has caused some very ugly hacks on the Web. It is very 
important to address that issue.


Viewport switching is usually done to adapt images for mobile device VS 
large/huge display devices. It is a valid concern but it is not easily 
addressed. Srcset can/should likely be improved regarding this.


I believe (feel free to prove me wrong) dynamic viewport adaptation and 
what you call "art direction" is not as common.
I have the feeling those corner cases may be better addressed with 
JavaScript.



In my opinion WebKit should not support srcN in its current form. We are 
here to make the web a better/friendlier platform. The srcN proposal 
does not do that, it is a catch all that makes the important use cases 
more difficult.


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

Re: [webkit-dev] Code cleaning: LEGACY_VIEWPORT_ADAPTION

[Benjamin Poulain]

On 10/30/13, 7:44 AM, Hugo Lima wrote:
> On Tue, Oct 29, 2013 at 9:00 PM, Benjamin Poulain  wrote:
>> I plan to remove the code guarded by LEGACY_VIEWPORT_ADAPTION and the flag
>> itself.
> 
> I was reading the original bug report[1] to find a list of websites
> targeting mobile devices that don't render well if this feature is
> disabled, the original list includes:
> 
> m.yahoo.com
> m.google.com
> m.facebook.com
> 
> All this if you do not use some apple-like user agent, I did test them
> again today to check the current status and just m.google.com is still
> using those legacy DTD causing WebKit to render the page into a 980px
> canvas where it was designed to be rendered into a 320px canvas. There
> may be other (old) sites not rendering well but at least at the time
> of the bug report this small list with very popular websites was
> enough to add this feature to a product (N9 phone) then to WebCore.
> 
> I also found that besides Blackberry, Chromium turned on this flag[2]
> last year, but I didn't check if it still enabled on blink.

It is okay to adapt the viewport for the mobile doctypes. WebKit on iOS
also does that for the reasons you mentioned.

The problem here is the code is not correct.

> Support legacy stuff is a pain and just inject undesirable code in the
> codebase, but I would like to know if there are other options rather
> than just removing the feature and let few, but some important,
> website not working?

If Nix really relies on that code, I will leave it in for now.

When the relevant iOS bits and pieces will be upstream, it will be
easier to implement viewport adaptation and I'll remove
LEGACY_VIEWPORT_ADAPTION then.

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

[webkit-dev] Code cleaning: LEGACY_VIEWPORT_ADAPTION

[Benjamin Poulain]

Hi WebKit,

I plan to remove the code guarded by LEGACY_VIEWPORT_ADAPTION and the 
flag itself.


The reason is: this code is mostly incorrect and leads to valid viewport 
configurations only with the most trival cases.


It seems to be only enabled by Nix and Blackberry but I can't tell if it 
is intentional.


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