Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Konstantin Tokarev]

03.08.2017, 01:07, "Michael Catanzaro" :
> On Wed, Aug 2, 2017 at 11:14 AM, Konstantin Tokarev  wrote:
>> FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt port 
>> and don't have any "terrible" development experience. Even when I need to 
>> make a change in file that is not port-specific, usually just one of 
>> AllInOne files needs to be recompiled
>
> What... what does that mean? How is it all in one if there are multiple files?

There are large groups of files from WebCore which are compiled as one file for 
each group. Look for *AllInOne.cpp files in WebCore

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

Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Michael Catanzaro]

On Wed, Aug 2, 2017 at 11:14 AM, Konstantin Tokarev  
wrote:
FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt 
port and don't have any "terrible" development experience. Even when 
I need to make a change in file that is not port-specific, usually 
just one of AllInOne files needs to be recompiled


What... what does that mean? How is it all in one if there are multiple 
files?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] WEB_SOCKETS enabled on all ports - let's remove the flag

[Brian Burg]

Hi WebKittens,

In WebKit, the Web Sockets API is guarded by the ENABLE_WEB_SOCKETS feature 
flag.

It seems that ENABLE_WEB_SOCKETS is turned on for Xcode and CMake build systems 
by default for several years on all ports. I think it’s time to remove the 
feature flag. Are there any objections?

If I don’t hear anything, the flag’s removal will be tracked in 
 and happen shortly.

Happy hacking,
-Brian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Maciej Stachowiak]

> On Aug 2, 2017, at 2:18 AM, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>> Some others I see:
>>> 
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>> 
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>> 
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>> 
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
> 
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

I'm not sure ENABLE_INDEXED_DATABASE quite fits with these other things. It 
doesn't require platform-specific support, the existing back end can use a 
portable storage library. It seems more like the kind of thing that new ports 
should stub out during bring-up than a thing that we might expect to be omitted 
entirely on some ports.

> 
> Perhaps we could merge some build flags though. e.g. we could merge
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
> can only enable both or neither.
> 
> - R. Niwa
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] WebVR on WebKit

[Maciej Stachowiak]

Though WebVR is not the most elegant API for VR, it's a least common 
denominator, and it seems like other browsers are on board. So I think it's 
worth at least experimenting with. (Other opinions may vary; this is just my 
personal view not an Official Apple Position or anything).

I'm guessing the hard work here is in implementing the back ends for specific 
platforms and achieving good quality.


Please consider reworking your patch to use a runtime flag instead of a 
compile-time flag. It doesn't seem to meet any of the reasons for using 
compile-time flags that are mentioned in our Feature Policy 
>. Even 
with just the stubs, I think it would fit the guidelines for a default-disabled 
runtime flag. New features should use runtime flags whenever possible IMO.

As an added benefit, if the feature started out runtime switched, it could be 
tested immediately. I bet there's tests that would be relevant even with just 
stubs (at least a simple one of checking what classes and methods are present). 
With runtime flags, you'd be able to have tests in the initial patch.

Regards,
Maciej


> On Aug 2, 2017, at 1:55 PM, Sergio Villar Senin  wrote:
> 
> Hi,
> 
> some weeks ago I uploaded [1] a patch (based on previous work by my
> colleague at Igalia Zan) which basically adds the IDLs for WebVR 1.1
> spec along with the required stubs and the cmake build configuration.
> As Sam Weining perfectly pointed out, this needs some previous
> discussion in the list in order to go ahead.
> 
> WebVR is an API which provides support for exposing virtual reality
> devices (like HMDs) to web apps so that the info coming from those
> devices could be converted into position, orientation and interactions
> with virtual worlds. Note that for a complete VR experience some other
> APIs would be needed as for example de Gamepad API for controller
> support (some extensions were proposed).
> 
> Although the spec[2] mentions that 1.1 is deprecated it is what
> browsers are shipping initially as 2.0 is still in a "do not implement"
> state.
> 
> Regarding interest from other vendors, WebVR is already supported in
> Edge, Firefox nightly and experimental builds of Chromium. Other
> browsers supporting it are Samsung Internet and Oculus Carmel.
> 
> Our main interest is to eventually have some implementation working on
> WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
> platform work that needs to be done as well. Our initial idea would be
> to use the OpenVR API as Valve released a Linux version of their SDK
> some months ago. Looks like a safe bet as other vendors like Firefox or
> Chromium already include it in their trees as third party.
> 
> WDYT?
> 
> BR
> 
> [1] https://bugs.webkit.org/show_bug.cgi?id=174202
> [2] https://w3c.github.io/webvr/spec/1.1/
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Maciej Stachowiak]

> On Aug 2, 2017, at 2:40 AM, Andreas Kling  wrote:
> 
>> 
>> On 2 Aug 2017, at 01:03, Ryosuke Niwa  wrote:
>> 
>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling  wrote:
>>> Some time has passed, and it seems that adoption of CSS regions on the web 
>>> is not gonna happen.
>>> 
>>> Blink has long since removed their support.
>>> Firefox never supported it AFAIK.
>>> (The new) IE has some amount of support behind a prefix, but no plans to 
>>> unprefix AFAIK.
>>> 
>>> I think it’s time we remove the code from WebKit, and relieve ourselves of 
>>> the maintenance burden.
>>> This should also open up numerous opportunities for clean-up and 
>>> optimization.
>>> 
>>> If you know of any reason to keep the feature, such as a major website or 
>>> WebKit client depending on it, do speak up now!
>> 
>> Since we've been shipping CSS regions for a while, I think the first
>> step we should take would be disabling the feature on trunk, and put
>> that into STP and other ports' releases so that we can easily revert
>> the change if we find out any Web content to be broken when the
>> feature is disabled.
> 
> Hi Ryosuke!
> 
> Unless there is evidence of at least one major site or client depending on 
> CSS regions, I don’t agree that such a slow removal process is necessary.
> 
> IMO doing that would only further increase the maintenance burden incurred by 
> the feature, since we’d have to add tons of runtime checks throughout the 
> codebase.
> 
> I would feel differently if we were pioneering this removal, but since we’ve 
> already seen it succeed in Blink I’m far less concerned.

If we wanted to use extra caution, I think the more useful thing to do would be 
to add telemetry to an STP build instead of doing a test disable and waiting 
for bugs. That's likely to get as an answer much sooner. (It won't tell us 
about content for non-browser apps, but disabling in STP can't tell us that 
either.)

 - Maciej


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

Re: [webkit-dev] Looking to remove cygwin dependency for javascript tests for Windows ports

[Szabo, Stephan (San Francisco)]

Hi again,

Also, internally for testing, we were having run-jsc-stress-tests write perl in 
the test scripts, but is there a preference for which language (perl, python, 
ruby, ...) to use?

Thanks,
Steph

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Szabo, Stephan (San Francisco)
Sent: Wednesday, August 02, 2017 9:53 AM
To: webkit-dev@lists.webkit.org
Subject: [webkit-dev] Looking to remove cygwin dependency for javascript tests 
for Windows ports

Hi,

As part of Sony's work on getting the jsconly build for Windows, we're also 
looking at the possibility of trying to remove/reduce the dependency on Cygwin 
for the javascript tests from run-javascript-tests since the build itself runs 
from a normal windows shell. Internally we did a very preliminary POC of a 
version of run-jsc-stress-tests for windows which built perl scripts for the 
test scripts rather than shell scripts and were able to get a bunch of the 
tests running. We attached that to 
https://bugs.webkit.org/show_bug.cgi?id=174985 . Obviously, that's not a 
reasonable version for inclusion, but we wanted to discuss whether there was 
support for removing the dependency before doing too much more down this path.

Our current thinking is that if we go forward with this, we'd probably step it 
as:
1. Move the test script and test runner code from run-jsc-stress-tests into a 
ruby file that is included from the main script 2. Make an option to allow 
using an alternate version of the above 3. Make an alternate version that 
didn't rely on shell

Thanks,
Stephan
___
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] Buildbot 0.9

[Aakash Jain]

Looking at the configuration, I believe you are running few build-slaves 
connecting to build.webkit.org

Please feel free to upgrade the slaves after buildbot master is upgraded to 0.9 
in https://bugs.webkit.org/show_bug.cgi?id=175056. It wouldn't be mandatory for 
you to upgrade, but would be good to do it for consistency.

Thanks
Aakash


> On Aug 2, 2017, at 12:37 PM, Olmstead, Don  wrote:
> 
> We’re running https://build.webkit.org/buildslaves/wincairo-2 
>  . Its all in a docker 
> container so its pretty painless to upgrade to 0.9 I’m just not sure when we 
> should plan to do the work. So we could update our build slave to 0.9 right 
> now?
>  
> From: aakash_j...@apple.com  
> [mailto:aakash_j...@apple.com ] 
> Sent: Wednesday, August 2, 2017 12:26 PM
> To: Olmstead, Don >
> Cc: WebKit-Dev Development (webkit-dev@lists.webkit.org 
> )  >
> Subject: Re: [webkit-dev] Buildbot 0.9
>  
> Hi Olmstead,
>  
> The commit adding buildbot 0.9 support is 
> https://trac.webkit.org/changeset/220120 
> . This is for bot watcher's 
> dashboard http://build.webkit.org/dashboard/ 
> . The code now have support for both 
> buildbot 0.8 and 0.9. However, we might drop the support for buildbot 0.8 in 
> near future (after we fix https://bugs.webkit.org/show_bug.cgi?id=175056 
> ).
>  
> I would be able to answer your question better if I know what kind of 
> buildbot setup you are using. Is your setup using code from 
> https://svn.webkit.org/repository/webkit/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/
>  
> 
>  ?
>  
> Thanks
> Aakash
>  
>  
> On Aug 2, 2017, at 11:27 AM, Olmstead, Don  > wrote:
>  
> There was a commit, https://trac.webkit.org/changeset/220139/webkit 
>  , referencing a Buildbot 
> 0.9 dashboard. I’m wondering if we need to upgrade our setup to 0.9 and if so 
> what the timeframe is for the upgrade.
> ___
> 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] Buildbot 0.9

[Olmstead, Don]

We’re running https://build.webkit.org/buildslaves/wincairo-2 . Its all in a 
docker container so its pretty painless to upgrade to 0.9 I’m just not sure 
when we should plan to do the work. So we could update our build slave to 0.9 
right now?

From: aakash_j...@apple.com [mailto:aakash_j...@apple.com]
Sent: Wednesday, August 2, 2017 12:26 PM
To: Olmstead, Don 
Cc: WebKit-Dev Development (webkit-dev@lists.webkit.org) 

Subject: Re: [webkit-dev] Buildbot 0.9

Hi Olmstead,

The commit adding buildbot 0.9 support is 
https://trac.webkit.org/changeset/220120. This is for bot watcher's dashboard 
http://build.webkit.org/dashboard/. The code now have support for both buildbot 
0.8 and 0.9. However, we might drop the support for buildbot 0.8 in near future 
(after we fix https://bugs.webkit.org/show_bug.cgi?id=175056).

I would be able to answer your question better if I know what kind of buildbot 
setup you are using. Is your setup using code from 
https://svn.webkit.org/repository/webkit/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/
 ?

Thanks
Aakash


On Aug 2, 2017, at 11:27 AM, Olmstead, Don 
> wrote:

There was a commit, https://trac.webkit.org/changeset/220139/webkit , 
referencing a Buildbot 0.9 dashboard. I’m wondering if we need to upgrade our 
setup to 0.9 and if so what the timeframe is for the upgrade.
___
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] Buildbot 0.9

[Aakash Jain]

Hi Olmstead,

The commit adding buildbot 0.9 support is 
https://trac.webkit.org/changeset/220120. This is for bot watcher's dashboard 
http://build.webkit.org/dashboard/. The code now have support for both buildbot 
0.8 and 0.9. However, we might drop the support for buildbot 0.8 in near future 
(after we fix https://bugs.webkit.org/show_bug.cgi?id=175056).

I would be able to answer your question better if I know what kind of buildbot 
setup you are using. Is your setup using code from 
https://svn.webkit.org/repository/webkit/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/
 ?

Thanks
Aakash


> On Aug 2, 2017, at 11:27 AM, Olmstead, Don  wrote:
> 
> There was a commit, https://trac.webkit.org/changeset/220139/webkit 
>  , referencing a Buildbot 
> 0.9 dashboard. I’m wondering if we need to upgrade our setup to 0.9 and if so 
> what the timeframe is for the upgrade.
> ___
> 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] Looking to remove cygwin dependency for javascript tests for Windows ports

[Alex Christensen]

I think eventually running all tests on Windows without Cygwin would be a step 
in the right direction.

> On Aug 2, 2017, at 9:53 AM, Szabo, Stephan (San Francisco) 
>  wrote:
> 
> Hi,
> 
> As part of Sony's work on getting the jsconly build for Windows, we're also 
> looking at the possibility of trying to remove/reduce the dependency on 
> Cygwin for the javascript tests from run-javascript-tests since the build 
> itself runs from a normal windows shell. Internally we did a very preliminary 
> POC of a version of run-jsc-stress-tests for windows which built perl scripts 
> for the test scripts rather than shell scripts and were able to get a bunch 
> of the tests running. We attached that to 
> https://bugs.webkit.org/show_bug.cgi?id=174985 . Obviously, that's not a 
> reasonable version for inclusion, but we wanted to discuss whether there was 
> support for removing the dependency before doing too much more down this path.
> 
> Our current thinking is that if we go forward with this, we'd probably step 
> it as:
> 1. Move the test script and test runner code from run-jsc-stress-tests into a 
> ruby file that is included from the main script
> 2. Make an option to allow using an alternate version of the above
> 3. Make an alternate version that didn't rely on shell
> 
> Thanks,
> Stephan
> ___
> 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] Buildbot 0.9

[Olmstead, Don]

There was a commit, https://trac.webkit.org/changeset/220139/webkit , 
referencing a Buildbot 0.9 dashboard. I'm wondering if we need to upgrade our 
setup to 0.9 and if so what the timeframe is for the upgrade.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Sergio Villar Senin]

O Mér, 02-08-2017 ás 12:43 +0300, Konstantin Tokarev escribiu:
> Also, AFAICS WebAudio is not widely used across the Web. Can anyone
> point me to real
> website which is not WebAudio demo but makes use of this API somehow?

Check www.webaudioweekly.com for several examples.

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

[webkit-dev] WebVR on WebKit

[Sergio Villar Senin]

Hi,

some weeks ago I uploaded [1] a patch (based on previous work by my
colleague at Igalia Zan) which basically adds the IDLs for WebVR 1.1
spec along with the required stubs and the cmake build configuration.
As Sam Weining perfectly pointed out, this needs some previous
discussion in the list in order to go ahead.

WebVR is an API which provides support for exposing virtual reality
devices (like HMDs) to web apps so that the info coming from those
devices could be converted into position, orientation and interactions
with virtual worlds. Note that for a complete VR experience some other
APIs would be needed as for example de Gamepad API for controller
support (some extensions were proposed).

Although the spec[2] mentions that 1.1 is deprecated it is what
browsers are shipping initially as 2.0 is still in a "do not implement"
state.

Regarding interest from other vendors, WebVR is already supported in
Edge, Firefox nightly and experimental builds of Chromium. Other
browsers supporting it are Samsung Internet and Oculus Carmel.

Our main interest is to eventually have some implementation working on
WebKitGtk and/or WPE on Linux but obviously there is a lot of cross-
platform work that needs to be done as well. Our initial idea would be
to use the OpenVR API as Valve released a Linux version of their SDK
some months ago. Looks like a safe bet as other vendors like Firefox or
Chromium already include it in their trees as third party.

WDYT?

BR

[1] https://bugs.webkit.org/show_bug.cgi?id=174202
[2] https://w3c.github.io/webvr/spec/1.1/
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Olmstead, Don]

Web Audio is on the radar for WinCairo. I wasn't going to start working on it 
until after platform/audio ended up in PAL.

-Original Message-
From: webkit-dev [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of 
Konstantin Tokarev
Sent: Wednesday, August 2, 2017 2:44 AM
To: Ryosuke Niwa ; Adrien Destugues 
Cc: WebKit-Dev 
Subject: Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the 
flag?



02.08.2017, 09:19, "Ryosuke Niwa" :
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>>  Some others I see:
>>>
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>
>>  At least these are still not implemented in the Haiku port. I know 
>> we
>>  are not an upstream port anymore and have little chance of being 
>> again
>>  as I'm slowly trying to catch up with the lates 1.5 years of
>>  development in WebKit. But having to implement all of these would
>>  delay my work even more.
>>
>>  As usual, I don't want the Haiku port to pull WebKit backwards, and 
>> I
>>  do plan to implement some of these at some point. However, being 
>> able
>>  to disable them at least for some time lets me work on other, more
>>  important aspects of the port first.
>>
>>  If the compile time flags are too annoying for that, maybe an
>>  alternative would be to provide stub implementations, but then 
>> support
>>  for these features should still not be advertised to webpages if the
>>  port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION, 
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they 
> all more or less require some external dependency (e.g. sqlite) and 
> platform features (e.g. audio).
>
> Perhaps we could merge some build flags though. e.g. we could merge 
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you 
> can only enable both or neither.

I disagree, implementing ENABLE_VIDEO is possible with generic "multimedia 
player" library, while ENABLE_WEB_AUDIO requires more advanced audio processing 
features.
And note that WebAudio is not supported in WinCairo port.

Also, AFAICS WebAudio is not widely used across the Web. Can anyone point me to 
real website which is not WebAudio demo but makes use of this API somehow?

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

--
Regards,
Konstantin
___
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] Looking to remove cygwin dependency for javascript tests for Windows ports

[Szabo, Stephan (San Francisco)]

Hi,

As part of Sony's work on getting the jsconly build for Windows, we're also 
looking at the possibility of trying to remove/reduce the dependency on Cygwin 
for the javascript tests from run-javascript-tests since the build itself runs 
from a normal windows shell. Internally we did a very preliminary POC of a 
version of run-jsc-stress-tests for windows which built perl scripts for the 
test scripts rather than shell scripts and were able to get a bunch of the 
tests running. We attached that to 
https://bugs.webkit.org/show_bug.cgi?id=174985 . Obviously, that's not a 
reasonable version for inclusion, but we wanted to discuss whether there was 
support for removing the dependency before doing too much more down this path.

Our current thinking is that if we go forward with this, we'd probably step it 
as:
1. Move the test script and test runner code from run-jsc-stress-tests into a 
ruby file that is included from the main script
2. Make an option to allow using an alternate version of the above
3. Make an alternate version that didn't rely on shell

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

Re: [webkit-dev] WebKit opengl

[Adrien Destugues]

2017-08-02 14:43 GMT+02:00 Gustavo Sverzut Barbieri :

>> You are not going to get WebKit working with OpenGLES 1.1 unless you have an 
>> experienced engineer making large modifications to the source code. Instead, 
>> you should just turn off OpenGL/OpenGLES support. Just build with 
>> -DENABLE_OPENGL=OFF. It is optional, you just lose hardware acceleration. 
>> You should hopefully have no trouble with this.
>>
>> If you have a requirement to use OpenGLES regardless, then you may need to 
>> reevaluate the feasibility of your project.
>
> Indeed... we did such port for a customer based on WebKit-EFL (now
> out-of-tree) and it worked, but was a major pain to get there due
> CoordinatedGraphics and TextureMapper being heavy on GL calls...
> however in our case it was software rendering only, no GL at all.

The Haiku port also uses no OpenGL. I have versions of
CoordinatedGraphics and TextureMapper extracted from old verisons of
WebKit which I maintain with the port (TextureMapperImageBuffer is the
entry point for that):
https://github.com/haiku/webkit/blob/rebased/Source/WebCore/platform/graphics/texmap/TextureMapperImageBuffer.cpp

The commit which restores this may serve as a reference (but may not
apply directly to current sources):
https://github.com/haiku/webkit/commit/966df671f60cc716233952c5e80c5fd52d6ce785

-- 
Adrien Destugues / PulkoMandy
http://pulkomandy.tk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Gustavo Sverzut Barbieri]

On Tue, Aug 1, 2017 at 7:54 PM, Maciej Stachowiak  wrote:
> Chromium Embedded Framework is an obvious comparison project for use cases
> like that. CEF is arguably more popular as a bundled engine than WebKit, so
> we probably don't need more flexibility than they provide. Does CEF let you
> compile out video support?

not sure, but they do offer the video pipeline internally via
ffmpeg... thus it's not spread across ports as we do. Similar cases
come from rendering system, they force one and thus remove some
options because all ports will implement a feature, unlike here where
most features are port-dependent.

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN, GTalk, FaceTime: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (16) 99354-9890
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WebKit opengl

[Gustavo Sverzut Barbieri]

On Tue, Aug 1, 2017 at 6:44 PM, Michael Catanzaro  wrote:
>
> On Tue, Aug 1, 2017 at 9:13 PM, Nagendra K  wrote:
>
> Hi Dean,
>
> Thanks for the reply.
> I actually have a embedded device with opengl es 1.1 and WebKit which is 7 
> years old, now requirement is to update the WebKit using the same opengles1.1 
> i.e. no option to update opengles1.1.
> So as you said we need opengles2 or opengl4 to upgrade WebKit as WebKit has 
> dependencies with opengl for some features. Is this correct?
> Do I any other option to do this.
>
> Thanks and Regards,
> Nagendra
>
>
> Hi Nagendra,
>
> You are not going to get WebKit working with OpenGLES 1.1 unless you have an 
> experienced engineer making large modifications to the source code. Instead, 
> you should just turn off OpenGL/OpenGLES support. Just build with 
> -DENABLE_OPENGL=OFF. It is optional, you just lose hardware acceleration. You 
> should hopefully have no trouble with this.
>
> If you have a requirement to use OpenGLES regardless, then you may need to 
> reevaluate the feasibility of your project.

Indeed... we did such port for a customer based on WebKit-EFL (now
out-of-tree) and it worked, but was a major pain to get there due
CoordinatedGraphics and TextureMapper being heavy on GL calls...
however in our case it was software rendering only, no GL at all.



-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN, GTalk, FaceTime: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (16) 99354-9890
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] What's the rationale for not including config.h in any header files?

[Konstantin Tokarev]

02.08.2017, 01:49, "Michael Catanzaro" :
> On Tue, Aug 1, 2017 at 11:33 PM, Keith Miller  wrote:
>> P.S. There is also a reasonable chance that we will do some form of unified 
>> sources (compiling multiple cpp files at the same time). In that case we 
>> don’t need to change our config.h rules.
>
> Do you have experience with unified source builds on macOS? We basically 
> never do these on Linux, but it's of course possible. These builds are 
> typically great for production but terrible for development, since everything 
> needs to be recompiled when any file is changed. Also, using static to mark 
> functions as file-private no longer works. This is sure to cause headache. 
> But the benefits may be worthwhile.

FWIW, I use ENABLE_ALLINONE_BUILD=ON as a default build option in Qt port and 
don't have any "terrible" development experience. Even when I need to make a 
change in file that is not port-specific, usually just one of AllInOne files 
needs to be recompiled

Of course this may not be good for people actively developing Web-facing code

>
> Some good description:
>
> http://mesonbuild.com/Unity-builds.html
>
> Michael
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Konstantin Tokarev]

02.08.2017, 09:19, "Ryosuke Niwa" :
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>>  Some others I see:
>>>
>>>  ENABLE_GEOLOCATION
>>>  ENABLE_INDEXED_DATABASE
>>>  ENABLE_CSS_SCROLL_SNAP
>>>  ENABLE_WEBGL
>>>  ENABLE_WEB_AUDIO
>>
>>  At least these are still not implemented in the Haiku port. I know we
>>  are not an upstream port anymore and have little chance of being again
>>  as I'm slowly trying to catch up with the lates 1.5 years of
>>  development in WebKit. But having to implement all of these would
>>  delay my work even more.
>>
>>  As usual, I don't want the Haiku port to pull WebKit backwards, and I
>>  do plan to implement some of these at some point. However, being able
>>  to disable them at least for some time lets me work on other, more
>>  important aspects of the port first.
>>
>>  If the compile time flags are too annoying for that, maybe an
>>  alternative would be to provide stub implementations, but then support
>>  for these features should still not be advertised to webpages if the
>>  port really doesn't support them.
>
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).
>
> Perhaps we could merge some build flags though. e.g. we could merge
> ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
> can only enable both or neither.

I disagree, implementing ENABLE_VIDEO is possible with generic "multimedia 
player" library,
while ENABLE_WEB_AUDIO requires more advanced audio processing features.
And note that WebAudio is not supported in WinCairo port.

Also, AFAICS WebAudio is not widely used across the Web. Can anyone point me to 
real
website which is not WebAudio demo but makes use of this API somehow?

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

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

Re: [webkit-dev] OpenGl version to be used

[Konstantin Tokarev]

02.08.2017, 10:36, "gaurav.arad...@wipro.com" :
> Hi,
>
> We are trying to port Webkit on an embedded platform from version 74xxx to 
> 184849 (from Webkit turnk version in 2010 to  version in 2015). Currently we 
> have custom implementation of OpenGl 1.x running on the hardware. I have few 
> questions regarding the OpenGl version to use for our platform:
>
> * We want to continue using our custom OpenGl implementation 1.x for the 
> targeted WebKit revision 184849 (approximate). In the code I see conditional 
> compilation flag OPENGL_ES_2 (uses gl2.h) and in the else part we are using 
> gl.h (which seems to be OpenGl 1.x header). So can we continue using our 
> custom OpenGl 1.x implementation (fixed function pipeline)? Ofcourse there 
> could be few additional tweaks/functions / extensions to be supported by the 
> custom OpenGl implementation.

I think this question was answered multiple times on the list already.

> * What versions of OpenGl can HTML5 Canvas Implementation use? I suppose one 
> option is OpengGl 2.0 ES, what are the others? Also please specify if its ES 
> or desktop version.

Canvas (2D) is *raster* graphics API. It works as long as GraphicsContext 
methods are implemented, no matter how.

There is ENABLE(ACCELERATED_2D_CANVAS) flag, but AFAIU it's port-independent 
part still doesn't depend on how you implement it for your platform.

However, 3D canvas (WebGL) requires OpenGL ES 2

>
> Thanks a lot in advance!
>
> Best Regards
> Gaurav
>
> The information contained in this electronic message and any attachments to 
> this message are intended for the exclusive use of the addressee(s) and may 
> contain proprietary, confidential or privileged information. If you are not 
> the intended recipient, you should not disseminate, distribute or copy this 
> e-mail. Please notify the sender immediately and destroy all copies of this 
> message and any attachments. WARNING: Computer viruses can be transmitted via 
> email. The recipient should check this email and any attachments for the 
> presence of viruses. The company accepts no liability for any damage caused 
> by any virus transmitted by this email. www.wipro.com
> ,
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev


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

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

[Andreas Kling]

> On 2 Aug 2017, at 09:00, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling  > wrote:
>> 
>>> On 2 Aug 2017, at 01:03, Ryosuke Niwa  wrote:
>>> 
>>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling  wrote:
 Some time has passed, and it seems that adoption of CSS regions on the web 
 is not gonna happen.
 
 Blink has long since removed their support.
 Firefox never supported it AFAIK.
 (The new) IE has some amount of support behind a prefix, but no plans to 
 unprefix AFAIK.
 
 I think it’s time we remove the code from WebKit, and relieve ourselves of 
 the maintenance burden.
 This should also open up numerous opportunities for clean-up and 
 optimization.
 
 If you know of any reason to keep the feature, such as a major website or 
 WebKit client depending on it, do speak up now!
>>> 
>>> Since we've been shipping CSS regions for a while, I think the first
>>> step we should take would be disabling the feature on trunk, and put
>>> that into STP and other ports' releases so that we can easily revert
>>> the change if we find out any Web content to be broken when the
>>> feature is disabled.
>> 
>>> Unless there is evidence of at least one major site or client depending on 
>>> CSS regions, I don’t agree that such a slow removal process is necessary.
>> 
>> IMO doing that would only further increase the maintenance burden incurred 
>> by the feature, since we’d have to add tons of runtime checks throughout the 
>> codebase.
> 
> Given my concern is the compatibility, not the maintenance cost, what
> is the evidence that nobody is relying on this feature?

While I am not the all-seeing oracle of unused features, I can tell you a few 
things right now:

- There are no Mac or iOS clients of CSS regions among Apple’s own apps.
- There are no iBooks using CSS regions.
- I could only find one radar about CSS regions from anyone who’s not an 
engineer working on implementing CSS regions in WebKit.
- That radar was deemed a real bug, but got punted in 2014 because “we don’t 
know of any high priority regions client.” :|

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

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

[Antti Koivisto]

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


  antti

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

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

[webkit-dev] OpenGl version to be used

[gaurav.arad...@wipro.com]

Hi,


We are trying to port Webkit on an embedded platform from version 74xxx to 
184849 (from Webkit turnk version in 2010 to  version in 2015). Currently we 
have custom implementation of OpenGl 1.x running on the hardware. I have few 
questions regarding the OpenGl version to use for our platform:


  1.  We want to continue using our custom OpenGl implementation 1.x for the 
targeted WebKit revision 184849 (approximate). In the code I see conditional 
compilation flag OPENGL_ES_2 (uses gl2.h) and in the else part we are using 
gl.h (which seems to be OpenGl 1.x header). So can we continue using our custom 
OpenGl 1.x implementation (fixed function pipeline)? Ofcourse there could be 
few additional tweaks/functions / extensions to be supported by the custom 
OpenGl implementation.
  2.  What versions of OpenGl can HTML5 Canvas Implementation use? I suppose 
one option is OpengGl 2.0 ES, what are the others? Also please specify if its 
ES or desktop version.

Thanks a lot in advance!

Best Regards
Gaurav


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Brady Eidson]

> On Aug 1, 2017, at 11:18 PM, Ryosuke Niwa  wrote:
> 
> On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  
> wrote:
>>> Some others I see:
>>> 
>>> ENABLE_GEOLOCATION
>>> ENABLE_INDEXED_DATABASE
>>> ENABLE_CSS_SCROLL_SNAP
>>> ENABLE_WEBGL
>>> ENABLE_WEB_AUDIO
>> 
>> At least these are still not implemented in the Haiku port. I know we
>> are not an upstream port anymore and have little chance of being again
>> as I'm slowly trying to catch up with the lates 1.5 years of
>> development in WebKit. But having to implement all of these would
>> delay my work even more.
>> 
>> As usual, I don't want the Haiku port to pull WebKit backwards, and I
>> do plan to implement some of these at some point. However, being able
>> to disable them at least for some time lets me work on other, more
>> important aspects of the port first.
>> 
>> If the compile time flags are too annoying for that, maybe an
>> alternative would be to provide stub implementations, but then support
>> for these features should still not be advertised to webpages if the
>> port really doesn't support them.
> 
> I can see an argument for having build flags for ENABLE_GEOLOCATION,
> ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
> all more or less require some external dependency (e.g. sqlite) and
> platform features (e.g. audio).

INDEXED_DATABASE can be built and used without the SQLite dependency; We have 
our own fully supported in-memory backing store for private browsing that could 
be used by any port for mainline browsing as well.
In fact, the in-memory store would be a fine default store for a port that 
doesn't even specify an IDB database directly.

At this point in the web platform and the lifecycle of IndexedDB I think it's 
problematic for any port to pretend it doesn't exist.

I support removing this one, as well.

Thanks,
 Brady

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

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

[Ryosuke Niwa]

On Tue, Aug 1, 2017 at 11:40 PM, Andreas Kling  wrote:
>
>> On 2 Aug 2017, at 01:03, Ryosuke Niwa  wrote:
>>
>> On Mon, Jul 31, 2017 at 1:49 AM, Andreas Kling  wrote:
>>> Some time has passed, and it seems that adoption of CSS regions on the web 
>>> is not gonna happen.
>>>
>>> Blink has long since removed their support.
>>> Firefox never supported it AFAIK.
>>> (The new) IE has some amount of support behind a prefix, but no plans to 
>>> unprefix AFAIK.
>>>
>>> I think it’s time we remove the code from WebKit, and relieve ourselves of 
>>> the maintenance burden.
>>> This should also open up numerous opportunities for clean-up and 
>>> optimization.
>>>
>>> If you know of any reason to keep the feature, such as a major website or 
>>> WebKit client depending on it, do speak up now!
>>
>> Since we've been shipping CSS regions for a while, I think the first
>> step we should take would be disabling the feature on trunk, and put
>> that into STP and other ports' releases so that we can easily revert
>> the change if we find out any Web content to be broken when the
>> feature is disabled.
>
>> Unless there is evidence of at least one major site or client depending on 
>> CSS regions, I don’t agree that such a slow removal process is necessary.
>
> IMO doing that would only further increase the maintenance burden incurred by 
> the feature, since we’d have to add tons of runtime checks throughout the 
> codebase.

Given my concern is the compatibility, not the maintenance cost, what
is the evidence that nobody is relying on this feature?

It seems a little crazy to remove a feature that has been available
(prefixed) since Safari 6.2 without any prior warning or gathering any
usage metrics at all.

Also see: https://trac.webkit.org/wiki/DeprecatingFeatures

> I would feel differently if we were pioneering this removal, but since we’ve 
> already seen it succeed in Blink I’m far less concerned.

I'm more concerned about iOS and macOS apps that use WebKit than the
Web content in the wild.

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

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

[Andreas Kling]

> On 1 Aug 2017, at 15:38, Dean Jackson  wrote:
> 
> I've been told that Amazon's Kindle Cloud Reader uses CSS Regions if 
> available, and gets a significant performance boost. It has a fallback though.

Hi Dean! I’ve WebInspected around in a few books using Kindle Cloud Reader and 
can’t find any evidence that it uses CSS regions. Could this be outdated 
information?

> Also, it would be worth checking at least Apple's iBooks store for any 
> content that might have used regions. It would be a shame if purchased books 
> stopped working :)

A search (done around Christmas 2016) found no instances of iBooks using CSS 
regions.

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

Re: [webkit-dev] WEB_TIMING enabled on all ports - let's remove the flag?

[Ryosuke Niwa]

On Tue, Aug 1, 2017 at 10:41 PM, Adrien Destugues  wrote:
>> Some others I see:
>>
>> ENABLE_GEOLOCATION
>> ENABLE_INDEXED_DATABASE
>> ENABLE_CSS_SCROLL_SNAP
>> ENABLE_WEBGL
>> ENABLE_WEB_AUDIO
>
> At least these are still not implemented in the Haiku port. I know we
> are not an upstream port anymore and have little chance of being again
> as I'm slowly trying to catch up with the lates 1.5 years of
> development in WebKit. But having to implement all of these would
> delay my work even more.
>
> As usual, I don't want the Haiku port to pull WebKit backwards, and I
> do plan to implement some of these at some point. However, being able
> to disable them at least for some time lets me work on other, more
> important aspects of the port first.
>
> If the compile time flags are too annoying for that, maybe an
> alternative would be to provide stub implementations, but then support
> for these features should still not be advertised to webpages if the
> port really doesn't support them.

I can see an argument for having build flags for ENABLE_GEOLOCATION,
ENABLE_INDEXED_DATABASE, ENABLE_WEBGL and ENABLE_WEB_AUDIO since they
all more or less require some external dependency (e.g. sqlite) and
platform features (e.g. audio).

Perhaps we could merge some build flags though. e.g. we could merge
ENABLE_VIDEO and ENABLE_WEB_AUDIO into ENABLE_MULTIMEDIA so that you
can only enable both or neither.

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